_edited.png){kind=logo}
Recently, a software developer I was interviewing asked why my business partner, Travis, and I decided to start a company of our own instead of continuing to be software developers at other companies.
Honestly, the main reason is that we had worked at so many companies that we had seen how dysfunctional software development often was. We knew it didn’t have to be that way, so we built a company that represented the company we always wanted to work at.
But it can be hard to see dysfunction when it’s your status quo, so I thought I’d present a short (but not complete) list of common, dysfunctional trends in how software is typically done. Hopefully, your company doesn’t exhibit any of these, but if it does, the good news is that things can be different!
Baseless Deadlines and Project Estimates
In any line of work, there are deadlines that have business value. Cost of delay is a real thing. Sometimes, the length of time may even make the value drop to zero. There’s no reason to keep trying to get your Christmas Sale together if you can’t get it done by Christmas (although you could transform it into your After-Christmas Sale).
Software development, however, is often littered with deadlines that have no direct business value attached to them. They are simply dates used as a productivity driver. “We’ve gotta have that feature done by April 17th or… you know… uh… we… uh… will miss the deadline. And… um… that’s bad. So.”
What’s more is that these deadlines are often made for random reasons such as a promise that a salesperson made or a manager who used to be a developer making an estimate based on their own perception of how long something should take.
Seeing these dysfunctions, some organizations decide to mitigate them by asking the developers themselves what the deadlines should be for their own work. This is definitely a step in the right direction, but it turns out that developers are not much better at this than anyone else.
Expectation of Overtime
Software developers are often amazed when I tell them that it’s been years since I had to work a 50-hour workweek. Even a 45-hour workweek virtually never happens.
Overtime is so common in software development efforts that many assume it’s simply a necessary part of the profession. Well, it isn’t.
The vast majority of overtime comes as a result of other dysfunctions, often dysfunctions that are completely outside the hands of developers. Poor planning, misinformed deadlines, decisions made in the name of expedience that came home to roost—these and many other dysfunctions (including the others in this article) often result in overtime, and almost always it results in overtime for the people who did not create the conditions that made the overtime necessary.
I always thought it was a little unjust when I had to work 70 hours a week because a salesperson or my manager promised an unrealistic timeline, but that person didn’t have to stay up all night with me.
In any case, overtime is such a common “remedy” to other problems (and often obscures the true impact of other problems) that it is a genuine expectation. Developers who do not stay late are often viewed as lazy or not as invested as the ones who are up until 3 a.m. to make sure the team hits the arbitrary deadline.
Big Batches and Big Risks
With the rising popularity of more agile approaches to software development, this factor is changing somewhat, but many organizations still struggle with it in some areas of software development.
It typically starts with a traditional project mindset. The software is conceived of as a fully fleshed-out product and staffed and budgeted on that basis. With this paradigm working right out of the gates, much of the mindset and practices around delivering this product also takes on a big batch tone.
The whole project timeline needs to be estimated. All the risks for the project need to be identified upfront. Every milestone needs to be planned out. Everything needs to be coded before QA can start their testing. Releases are infrequent and have to contain so many features that a special document has to be generated to keep track of them all. Those releases are big, testing them is big, and rolling them back is big. Users have to wait months to get their hands on the software because we don’t want to put anything into their hands that isn’t virtually the entire product.
The bigger the batch, the more investment is required, the more risk it involves, and the cost of recovery is higher.
Hero Culture
I once heard a developer complain-bragging about how they stayed up until 4 a.m. doing a release rollback.
Apparently, staying up very late hours to shepherd releases was a common cycle with this person. Each time it happened, people chimed in about how admirable this was, how dedicated and hardworking this person was, kudos for going the extra mile, etc.
In a healthy environment, someone staying up until 4 a.m. to roll back a release would be a sign of dysfunction. The very next team meeting would have the theme “Why Did Someone Have to Stay Up Until 4 a.m. Rolling Back a Release and How Can We Keep This From Ever Happening Again?”
But in many software development companies, this kind of thing is rewarded. People develop a sense of identity around it. They are the ones who put out the fires. They are the ones who know the arcane twists and turns of some ancient codebase. They are the ones who drop whatever they’re doing whenever someone says they need something.
While their willingness to do what needs to be done could be applauded, many of these things should be cause for alarm and not reinforced or rewarded.
Heavily Siloed Value Stream
Stop me if this sounds familiar.
The business analysts speak directly to “the business,” gather all the requirements and then hand that off as an artifact to the developers. Oh, if you’re “agile,” the business analysts also write the user stories themselves and give that to developers. Developers have not been part of any of the meetings that have generated these artifacts, but they now have to work off of them.
The developers write code according to their understanding of the requirements they’ve been given, and when code is complete and the happy path seems to be basically working, the features are sent to QA—because it is their job to test.
QA, who has never been part of the requirements meetings or privy to any of the issues coders have run into, then receives a batch of features of some significant size and is given thirty seconds to test them in order to get them through “before the deadline.” Defects are reported back to developers who stop whatever new feature they’ve moved along to in order to fix them.
What makes the silo situation even worse is that they drive people into thinking of improvements that actually increase the isolation of the silos. How can BA’s produce more detailed requirements so developers don’t have to ask them questions? What kinds of notifications can QA put on a ticket so developers know right away that a defect was found? How can QA get their test scripts to developers so they’ll know what to code for? These suggestions are moving in entirely the wrong direction.
You’re On Your Own
Have you ever done one of those daily standups where you go around the room and each person says what they did yesterday and what they plan to do today? Was anyone else in the room affected by anyone else’s update?
Do you have work in some kind of repository—maybe items on a board or in a manager’s head—and you go to the repository, get something to work on, finish it, and then go back to the well for more work?
At a lot of organizations, “team” often means people who share a skillset who sit together or people working on the same product. But that doesn’t make you a team. In the scenarios I just described, nobody is actually working together in any meaningful way.
Sure, you might ask each other questions from time to time or have good discussions, but the fact remains that you have your individual work that you are individually responsible for and so does everyone else.
If you help someone, you are taking time away from “your work” to help someone with “their work.” If you run into trouble doing “your work,” it’s up to you to figure it out. If you do code reviews, you are reviewing someone else’s work that you haven’t seen before or have context for. If you’re falling behind, then you need to catch up. You have “your work” and “your job” and other work is “not your work” and “not your job.”
This is perhaps the riskiest way to go about software development, and it is easily the most common setup. Add ten bonus risk points if you’re developing something an architect designed for you.
This All Just Sounds Normal
If the statement above is true, then I’d offer that you have so commonly experienced dysfunction that it doesn’t seem dysfunctional to you. Likely, you have quit one software development job to get another and found conditions were similar. Maybe all this just seems like “part of the job” to you, or at least necessary frustrations inherent to the activity of software development.
Well, none of them are. None of the things I’ve listed in this article are necessary, and they’re only normal in the sense that so many organizations have institutionalized them. They’re all unhealthy, risky, and lead to stress, unhappiness, and burnout for the people involved.
But they are definitely common, and that’s why we had to start a company of our own.