Broken Windows: Natural Decline of a Software Developer

In 1982, James Q. Wilson and George L. Kelling introduced a criminology theory called the Broken Windows Theory. The theory states that, by maintaining and monitoring urban environments that you could prevent small crimes - which eventually will lead to more serious crimes - from occurring. In the article titled Broken Windows, released in the March 1982 edition of The Atlantic Monthly, they explained the following:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside.

and;

Or consider a pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there or even break into cars.

This theory forms the basis of my post, and it speaks to decay that occurs in software projects, as well as becoming stagnant in your career growth aspects as a Software Developer, and how your environment could potentially contribute to that.

For more information regarding the Broken Windows Theory you can go look at the Wikipedia article here.

AW&FUL Inc.

Most companies these days have a Software Development Department, and this department is often set up as a service department. That means that the Software Development Department is a valuable department within the organization, but it isn't a trusted advisor or a strategic partner to the business as a whole. The Software Development Department isn't as important as say, Marketing and Sales, and for a lot of companies it is only there to serve as a means to an end for the needs of the business.

Although this isn't necessarily the worst position you can find yourself in, there is something inherently wrong with this picture. The Software Development Department should be a strategic partner for the business. If you think of your Software Development Department as a service department, instead of a strategic business partner, you have a problem. In all likelihood your company will still make a profit, but you'll never be considered a good company to work for, you will not attract good talent for your Software Development team, you will always be under pressure when deployments are done, your business will not perform as stream lined as it could be and your companies profits might not grow as much year on year as before. We are moving into an age where you simply cannot be as relevant as you used to be, without making your Software Development Department a strategic partner.

For the sake of the article we'll refer to these companies that set up the Software Development Department in this way, as a single entity called: AW&FUL Inc.

Projects at AW&FUL Inc.

Often at AW&FUL Inc., you'll find that software projects are run poorly. The software might have a few broken windows, maybe even a bit of graffiti, but sometimes it is a full-blown invasion of meth/heroin addicted vagrants, and nobody knows when the building will collapse, or a fire will break out, and cause complete chaos. The real problem here is that the "chaos" I speak of, is anything from issues in production, to project being over time and over budget, and employee morale being low. Projects being over time and over budget is bad for the company financially, and normally the solution is to do a project death march when this inevitably happens, which is bad for morale to say the least, but the issues in production, for example the wrong account being debited/credited etc, can cause irreparable reputational damage.

Now this doesn't necessarily mean that you'll find these sorts of problems exclusively at AW&FUL Inc., but it seems to happen there more often. It also doesn't have to be a long running software project, it can be a brand spanking new project. It all boils down to software development processes and practices.

Companies love to assign strict budgets and fixed time-frames to projects, and who wouldn't? All of us like to know exactly how long something will take, and what it will cost. Be if for a home renovation project or fixing your car at your local service centre. However, these projects have a clearly defined scope and have historical data to support how long the renovation project should take, or how long it will take to fix your car, with software development projects this data is not readily available, or reliable.

The typical software development projects you encounter at AW&FUL Inc., are probably for a new product (or the revamp of an old project) that needs to integrate with a legacy system or ten. You have no idea how long it will take, where all the systems are that you need to integrate with, and not only that, you were most likely not involved in the planning phase of the project. Before you know it, you now have a project end date, and you don't even know what the project is. Obviously, this is not the ideal situation, but sometimes you suck it up, and do it anyway.

Our default fight-or-flight response in these situations is to take shortcuts, and hack the hell out of the software to get to that end date, but often we hurt ourselves in doing so, and we hurt the project we're working on. We are in fact starting to break windows.

More experienced developers do know how to fix broken windows, but they sometimes break them too. The problem is that the intent is always to go back and clean up, but time is not your friend. You often get assigned to a new project after the initial release, and all new features and maintenance gets assigned to someone else. Now the broken windows are part of the project, and you don't have any means to fix them. You can only hope that the person on the other end will find and fix the problems that you left, but this is often not the case. It does not really matter if the person is a junior, or a senior, they may simply not find it, or will simply not care.

As it is often the case, the developers assigned to these projects will settle for not caring. Before you know it, that 5 item switch case statement in the project is now 30 items long. Not a single variable name makes any sense. You have so many nested conditional statements that it would make inbreeding-hillbillies feel ashamed. You have classes that have a suffix of Helper or Utility or both, and there is always a file that is called Common; that is 3000 to 6000 lines long and will likely be the dumping ground of all the new features that are yet to be built. Now you have more than just a couple of broken windows...

I often think of the developers at AW&FUL Inc. as victims of their circumstances. When you first start working there, you are full of ambition, you want to build castles in the sky, you often fight to ensure things are being done "the right way", but as time progresses, you start to sympathize with your captors (see Stockholm syndrome) and you feel like you have no more energy left to fight the good fight.

Natural decline / devolution of a software developer

(Image sourced from https://www.flickr.com/photos/bjornmeansbear/5149202849)

As time passes, the system becomes less and less well-ordered. Sooner or later the fixing cease to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress. ...A brand-new, from-the-ground-up redesign is necessary.

― Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering

Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.

― Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering

After being a software developer at AW&FUL Inc. for a while, you've tried your best to do what you can to make things clean and maintainable, and everything seems to be a constant battle. At some point you stop caring. You don't stop caring about everything all at once. You stop caring about the little things, the tiny broken window in the corner.

At first, you stop caring about variable names, and namespaces and where things go. Then you stop caring about bigger things, such as keeping your methods and classes small and meaningful. You don't mind adding more and more if-statements and other conditional statements to that already 200-line method, because the building (software project) is already a bit dilapidated, and no-one will notice one more bad thing. You start copying and pasting things all over the place, instead of promoting re-use. You then start to copy things verbatim from the internet without knowing what the code does, or what the context of the code snippet was, it might just work out okay, but you're not sure, and you don't have time to look at it right now, the building is on fire...

It is up to you to realize that you have a problem. You only have two choices really. Are you going to start caring again about the work that you do, and rally the troops to drive change within your organization? Or will you decide that you have had enough of it, and you're tired, and that you should probably vote with your feet?

While you are still undecided on what to do next, it is your professional duty to keep your integrity intact and to grow your skills. You must still try to improve your environment and project, but you must begin with one broken window at a time, not the entire building all at once. Trying to make massive sweeping changes at this stage will only frustrate and demotivate you further. If you haven't been learning and keeping your skill set relevant, you need to ensure that you start immediately. You will need to get up to date with what has been happening in the industry and figure out what trends have been emerging, even if your knowledge is superficial, it can still be beneficial to just be aware of what problems certain technologies aim to solve, and why it has gained traction in the first place. The same advice applies when it comes to learning, start with one window, and fix your technology gaps gradually.

Conclusion

All software projects experience some entropy, and that is okay, but it's up to you to keep rot from setting it. Strive to build technology partnerships within your organization, and not master-slave relationships. Always keep improving yourself and your environment, one broken window at a time. If you find that you are feeling helpless and frustrated, you need to make time to do some introspection and evaluate yourself, and your environment critically and honestly.

I'll leave you to think about this quote from Frederick P. Brooks Jr.:

Years later, when I got to college, I learned about an important theory of psychology called Learned Helplessness, developed by Dr. Martin E. P. Seligman. This theory, backed up by years of research, is that a great deal of depression grows out of a feeling of helplessness: the feeling that you cannot control your environment.

― Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering

For more information on Learned Helplessness.