Advertisements
Skip to content

Posts from the ‘Public Sector’ Category

10
Jul

Deadlines: All Taking, No Giving

x5hpcdnjma931

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.

1tng8lpffih21

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.

hierarchy1

This is what it looks like in real life, at least from my perspective based on my experiences.

hierarchy2

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:

0_BXO-Krt9rSiopn6k

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.

 

Advertisements
1
Jul

The Love/Hate Relationship with Estimates

WindowsLiveWriter-ComicReliefDilbert_9F2D-

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:

I’ve been developing software for over 20 years, and I still can’t estimate how long something will take me when I’ve never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don’t get it. I have suffered great anxiety from being forced to give estimates when the truth is I have no clue. It depends on how easy it is and how many unforeseen issues I encounter. It was so bad that once my husband asked me how long it would be before I was done cooking something, and I practically had a meltdown. That’s when I knew it was time to leave that team. Can we stop pretending we can forecast the unknown?

This was countered by xwdv:

No.

Even bad estimates are better than no estimates. If you are having meltdowns your reputation is being tied too closely to your ability to give estimates.

You must never turn estimates into a promise, always remind people they are estimates. (Emphasis mine –ATH)

Want to give fast estimates? Here’s how:

1) first determine the scale of the task? Is it a year, month, week or day kind of task?

2) Then, it’s just 3 of those units. The smallest task takes 3 days. One day to completely fuck up, one day to figure out why, one day to get right. The longest takes 3 years. One year to fuck it all up, one year to learn why, one year to finish it.

I suggest never giving estimates in units smaller than a day. They just become noise. If a task is smaller than dayscale just say the task is too small to provide any meaningful estimate but won’t take more than a day.

And lastly, to help solidify the talking points of this post, this response to the above by bb88:

> Even bad estimates are better than no estimates.

No estimate is clearly better. (Emphasis mine –ATH) Here’s a common story I’ve seen across multiple companies.

1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign.

2. Engineering management then asks potentially good coder how long it will take. Coder replies with a time and “it’s just an estimate.”

3. Engineering management reports to Marketing that coder’s estimate leaving off the most important caveat, and Marketing treats that as the gospel truth.

4. Coder takes longer than expected because of some bad technical cruft that some other engineer put in because he was potentially rushed or just plain inept.

5. Marketing is pissed because they now have to withdraw the ad campaign, and starts blaming engineering.

6. Under increased scrutiny, Engineering gets a bad reputation, who then throws the coder under the bus in front of Marketing and other managers.

7. This shows up on the coder’s annual review who then leaves.

8. Engineering hires replacement which will have a 3-6 month learning cycle, and potentially writes worse code than the person that just left.

EDIT: The point is that if there’s no estimate, management has to deal with the uncertainty that the coder experiences. Hope for the best, plan for the worst.

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:

The annals of software-project history are packed with epic train-wrecks. The best-documented ones are in the public sector, including the FAA and the FBI and Healthcare.gov. Private industry is better at keeping its pain to itself, but when the full tales of slow-motion belly-flops like Microsoft’s Windows Vista get told, it isn’t pretty. The most-cited numbers on software-project failure are those of the Standish Group, a consulting outfit that reported that in 2012 only 39 percent of software projects were considered “successful.”

Late software projects run up costs, incur collateral damage and sometimes take down entire companies. And so the software industry has devoted decades to waging a war on lateness — trying frontal assault, enfilade, sabotage, diplomacy and bribes, and using tactics with names such as object oriented programming, the Rational Unified Process, open-source, agile and extreme programming.

Estimates play a part in nearly all of these approaches. Estimates are the siege-engines of the war on lateness. If we use them carefully and patiently and relentlessly, the hope is, maybe, eventually, we’ll win.

Why is software so late? One venerable intellectual tradition in the field says the answer lies in software’s very nature. Since code costs nothing to copy, programmers are, uniquely, always solving new problems. If the problem already had a solution, you’d just grab a copy from the shelf. On top of that, we have a very hard time saying when any piece of software is “done.”

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?

 

11
May

Is tech that’s deemed “obsolete” by outsiders “broken”?

The other day I was reading the post IT runs on Java 8 by Vicki Boykis. From the post:

 

In today’s online economy where thousands of developers are online, the person whose voice is the loudest gets the most weight. The loudest people aren’t going to be those working with legacy systems. (Unless you’re doing something extremely new).

This piece of the puzzle is the one that worries me the most. What I’m worried about is that places like Hacker News, r/programming, the tech press, and conferences expose us to a number of tech-forward biases about our industry that are overenthusiastic about the promises of new technology without talking about tradeoffs. That the loudest voices get the most credibility, and, that, as a result, we are listening to complicated set-ups and overengineering systems of distributed networking and queues and serverless and microservices and machine learning platforms that our companies don’t need, and that most other developers that pick up our work can’t relate to, or can even work with.

I’ve spoken and written about it at length, but, most times, easier is best.

And, if the tech is, in fact old and outdated, and the tradeoff from replacing it is lower than the tradeoff of keeping it, we shouldn’t be jumping to replace it with the latest and greatest. While we should evaluate new tools evenhandedly, most times, Postgres works just fine.

For better or worse, the world still runs on Excel, Java 8, and Sharepoint, and I think it’s important for us as technology professionals to remember and be empathetic of that.

 

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).

And they tasked two guys to do it. The result was a mishmash of ColdFusion (UX layer) and ASP.NET (service layer). This was 2015.

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:

 

In IT, we’ve become accustomed to managing services the same way. We keep our heads down and our systems running, prevent outages, and implement new applications. In business, our competitors play the same game, so we pay close attention to making sure our services perform at optimal levels.

This is, and always will be, important. But with the digital revolution, just running an IT shop better than anyone else doesn’t guarantee anything. Rather, success will depend on how quickly you market your offerings, how you structure your IT services, and especially how well you understand the pivotal role IT plays when it comes to remodeling your business.

To draw a parallel from the cut-throat world of retail fashion, clothing and accessory store Zara has become a huge success by developing a disruptive new strategy — and not because they have better stores than their competitors. They looked at what many in their industry regarded as the “not broken” element — slow time to market from initial garment design to shop floor (the tangled cables, if you like), and fixed it with a unique approach (unified design and manufacturing). Similarly, Netflix devastated the home video market, not because their employees worked harder than video store employees, but because they challenged traditional thinking — thinking that wasn’t really broken, just out of step with the move to digital content consumption.

[…]

Running an outdated IT strategy and managing the status quo is a recipe for disaster. The alternative is to work with the business to continuously review existing business models, re-examine cost structures and reduce operational debt to the point where IT is able to deliver the types of new applications and services that customers want.

Of course, none of this is easy if the entire organization is entrenched in the “not broken, don’t fix it” mindset. But fortune favors the bold who challenge traditional thinking.

[…]

So the next time you hear the cringe-worthy phrase “If it ain’t broke, don’t fix it,” stop and think. […] Always remember, it’s the “not broken” things in business that provide the best opportunities for innovation.

 

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:

 

 

Even after the (April 8, 2014) deadline, the Department of Defense continued to order support for Windows XP, with the Navy purchasing more XP support well into 2016, a year after the switchover to WIndows 10 was announced.

Invariably, the computers running pre-Windows 10 operating systems will dwindle, and the switchover will proceed to a satisfactory degree of accomplishment, even among the holdovers. But I wouldn’t expect older system to die entirely, and whenever the Pentagon switches to the post-10 operating system, expect to see Windows 10 kicking around on backwater computers. After all, this is the same Pentagon that still operates Windows 3.1.

 

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.