Keep Your Eye on the Ball

 It’s so easy to be confused while developing software. 

Each little piece is tiny and not particularly hard to understand, but the real complexity comes from the fact that they are often millions of them.

The end goal of writing software is to get code out there that does a good job of solving one or more user’s problems. If you figure out what they need, build it, and then get it into a stable operating environment, they can use the software successfully.

Time is a funny issue in software development. These days, there is always an intense impatience with getting the work done. It’s commonly believed that issuing low-quality work now, is better than waiting for a higher quality version. 

That might be true if each piece was really small and independent, you could get an initial version out there and then build on it as necessary, but code actually ‘stacks’. Newer code builds on the older stuff. If the older stuff is flaky, then no matter how nice the newer stuff is, it is also flaky. If you try to avoid stacking the code, you either make it massively siloed or totally redundant. The siloing hurts usability, while the redundancies waste huge amounts of time. There is no easy, side-effect-free, short-cut that will decrease the time and effort needed. We’ve known this for at least 50 years.

But it’s not just the code itself that can be the victim of impatience, or even the other side of the coin: bureaucracy. It’s the whole end-to-end process, which starts with the user talking about some way the computer could help them, and ends with their frequent interactions with the code as they apply it to their tasks. This is a very long series of little steps, where coding is just one small part of what needs to happen. If this ‘process’ is disorganized, or awkward, or deliberately slowed down, it applies a great deal of pressure onto the code itself forcing it to be of lower quality. 

Low-quality code is a multiplier. A little bit of it is okay and manageable, but as you get more and more of it, the negative effects are magnified. If you get a large enough pile of low-quality workmanship, it forms an operational black hole that sucks in all other efforts and is nearly impossible to escape from. A really bad system doesn’t have any viable short-term options left to fix it. 

It’s super important to be able to ‘assess’ the quality of organization and workmanship for any ongoing software development project, and it is equally important to be able to ‘correct’ any issues that are hurting the quality. However, it is extremely easy for people to miss the importance of this. In the rush, the negative quality issues are only getting a tiny bit worse, and they believe success will come from just getting something crude out there today. But success today comes at the expense of more pain tomorrow. If you keep that up for long enough, eventually the costs are inescapable.