It’s pretty much an open secret that in software development, asinine (and sometimes completely outrageous) deadlines, like estimates, are a way of life. The comic below shows what is–sadly–a typical representation of your average private sector software engineer.
That being said, it should come as no surprise that everybody has advice on how to try and combat the problem. From TechRepublic‘s 10 tips for meeting IT project deadlines to the utilization of agile software methodologies (see Deadlines in Agile by Stephan Kristiansen). Besides the usual suspects of scope creep, inept employees and managers, and micromanagement from both up top and from the customer. But for the most part, it’s typically managers that cause the most issues, sometimes through no fault of their own (for instance, if the company is riding on the release of a product, it’s either get it done or everyone is out of a job, and us developers don’t get golden parachutes).
A typical communication flow, ideally, would look like below. The bold red arrows represent directives, requirements, and specifications for the project (e.g., deadlines). The thinner black lines represent feedback. This is then processed and sent back down through the bold red arrows.
This is what it looks like in real life, at least from my perspective based on my experiences.
The thickest red lines are the same before. The thinner (but still thick, cause I like ’em thicc) red lines represent pressure, chastising, or other negative reactions. Notice that there is no feedback loop, only a one way path. This phenomenon is called shit rolls downhill. It is a common trope among any team that develops a product.
Some may argue that the idea is to get a product out the door before a competitor eats your lunch. While I agree with that, it can also be argued that getting a quality product out the door that stands apart from your competitors is just as important. To achieve this balance between speed of delivery and quality. Always refer back to the Good/Cheap/Fast paradigm:
I can appreciate that people up top have a vision. I, and many other developers like me, want that vision to become a reality because we share it, too (in most cases; I’m not naive to the fact that some of us just want a paycheck). But reality can be disappointing, and because we live in that reality management has to be open to the fact that some things just cannot be helped. It’s fine you want a deadline, but you have to be realistic about it.
But they try to get around this.
Next time, we’ll examine the Good/Cheap/Fast paradigm and the Mythical Man Month and how wily managers try to cheat the system.
Love ’em or hate ’em, estimates are a manager’s best friend and an engineer’s (developer/producer/whipping post) nightmare.
And they’re not going anywhere.
Reading the comment section on Hacker News today on the article Dear Agile, I’m Tired of Pretending by Charles Lambdin when the subject on estimations came up. Specifically, this comment by bougiefever:
There are two distinct statuses that a software developer will be looked upon by those outside of their respective realm within an organization: as wizards that can turn out miraculous, spectacular(?) software, or as insufferable buffoons who seem to forget that in some cases people’s lives are in their hands and yet they still manage to drop the ball.
This is why I hate it when the upper echelon of my current employer call me “the man”–this placing of me on a pedestal is dangerous and sets a very bad precedent of me being a 24×7 miracle worker. I’m not the Jesus of software engineering, folks.
With estimates, in response to xwdv, while you, the programmer, may reach a mutual agreement with the individual or group requesting the estimate that it is in no way, shape, or form, a concrete definite obligation that it’s going to fall within that time frame, that agreement is moot when they go and construct it as a promise to the next party, whether it be upper management, the customer, or your own mother. And this has led to some small uprisings in the software development community, such as the #NoEstimates movement. From the article Estimates? We Don’t Need No Stinking Estimates! by Scott Rosenberg:
Non-engineers need to understand that software development is not an exact science; a lot of it involves trial-and-error. When the stakes are high, we need time to ensure that everything is copacetic. I know this advice is going to fall on deaf ears no matter how many times I try to teach management and others about how this industry works, but I know you, dear reader, will agree. In any case, perhaps this is a case for business coaches to start teaching their clients about software estimation and project management.
Whatever the case, estimations are not going anywhere, period. Otherwise, you’ll get pie-in-the-sky vaporware that, if it ever does come out, fails to live up to its expectations (“You spent X [months/years] on it! Why does it suck!”) and becomes yet another argument for either waterfall estimation or agile burndown charts (Duke Nukem Forever anyone?). The lack of estimations is merely cannon fodder for management to rubber stamp you as incompetent and find some other schmuck to make that promise. Worse yet, when that check bounces, you’ll still bear the majority brunt of the blow back.
If that’s the case, you might as well project something insane and walk it back. Hey, under-promise and over-deliver, right?
Was the YouTube Partner Program a viable way to make a career? When a machine is in the wheelhouse, probably not.
With the latest ad apocalypse (dubbed the “Voxpocalypse“), another large swath of YouTube content creators are finding themselves in the demonetization (and channel purge) list as YouTube cranks up their aggressive crackdown on content not deemed suitable for advertisers. Worse yet for some, the targeted deplatforming campaigns brought on by individuals caught in their crosshairs is a “taking a bull by the horns” approach to ensuring that major content sponsors are pulling out, decreasing their monthly income (we are ignoring whether or not this is warranted because I really don’t feel like going down that rabbit hole).
I’ve been on the Internet since 1996, starting with a 56K baud modem in the absolute remote wilderness of North Carolina and Internet Explorer on Windows 95. Back then, what content (whether it be videos, blog posts, images) people created were typically self-hosted on shared hosting services, such as GeoCities or Angelfire, or, if you were serious about your work, your paid hosting provider with a custom domain name. People made money off advertising networks that displayed banner ads on their sites. In some cases, they could do very well if the traffic was good (this was in the age before ad blockers became a thing); most of the time, webmasters made money by selling merchandise or asking for donations.
The YouTube Partner Program launched in December 2007. Since then, many have tried (and ultimately failed) to make a career out of YouTube. In the article 96.5% of YouTubers Don’t Earn Enough to Cross the Poverty Line, Study Finds by Daniel Sanchez:
It goes without saying that the lion’s share of revenue generated by advertisement revenue goes to the platform itself. Profitability, however, still remains a mystery. From the article Believe It or Not, YouTube May Spend More on Content than Netflix Does by Adam Levy:
That said, YouTube is going to put their own preservation interests first and foremost. What’s even more problematic for content creators is that YouTube’s biggest competitors–the traditional media–are keenly aware of the delicate relationship that YouTube has with its advertisers. Thus, when a hit piece comes out that could potentially paint the companies in a bad light, the algorithm is changed, videos and channels are tossed, behaviors are modified through demonetization, and YouTube tries to make nice with the old hat media by placing them front and center. Then you have people with an agenda who make waves, triggering another wave of demonitizations and channel/video removals. Then there are disputes between online personalities and journalists. Soon it will come to a point where so much as passing gas accidentally on camera will erupt in a mass exodus of advertisers.
To me, this just screams that people need to go back to what we started with: self-hosting, self-maintaining, and self-reliance. With the advent of cloud computing and scalability, it’s (theoretically) easier now to establish your own corner on the ‘net without the need to rely on a platform.
Of course, this doesn’t mean that large providers–Microsoft, Google, Amazon–aren’t immune to social pressure. But in this case, the content producer is also a paying customer, not a means to an end to generate advertising revenue.
In a sense, it really spoke to me. I have spent countless hours in situations where the current environment were “handcuffed” as it were to tech that had, at the surface, seemed like it had lived past its prime.
Or had it?
Many instances–public sector especially–are not by any means cutting edge. The utility sector, for instance, in many instances utilizes a de facto serial standard since 1979 that is (by itself) highly succeptible to man-in-the-middle attacks and is very limited in what data it can hold. Other cases it’s a matter of needing to get something out the door as fast as possible. One of my contracts involved an organization that needed an in-house web-based ERP yesterday. (They already utilized an ERP system from Infor that ran on an AS/400 but it was unable to effectively meet the requirements of the vendors for product listing and RPG IV programmers cost a buttload).
If you are a web developer or programmer, you can already feel the nausea. If you’re not, then understand that this was the equivalent of building Frankenstein’s monster from IKEA using parts you ordered off eBay.
But: it worked. To the best of its ability, it managed to get the job done. Yes, there were a lot of innefficiency in some of the operations that took place, but it got the job done, which to the company was “Good enough.” The skeleton team grew by six people and, from what I hear, is still chugging along with backlog of features that may never be toppled, but that’s a story for another day.
In his article IT’s Famous Last Words: If It Ain’t Broke, Don’t Fix It, Peter Waterhouse states:
Maybe chasing after the “latest in greatest” isn’t the answer to remaining ahead of the curve in information technology, at least all the time. One should always evaluate their toolset and make adaptations as necessary in order to fulfill the needs of their customers. Last I checked there is still a need for C programmers.
In the public sector where availability of service, not competition, is the biggest worry, it is prudent to not disrupt the flow of what is provided to the citizens. We still see a lot of “obsolete” tech that still functions being utilized, especially in terms of the hardware that supports the legacy applications. An example is from the article DoD is migrating to Windows 10 and it will probably stick around forever by Kelsey D. Atherton:
Ensuring compatibility of these legacy apps is critical, so specialy care must be taken to ensure that they can be brought gently into the twenty first century.
So in answer to the question on whether “obsolete” tech is “broken”, the answer is: it depends.