We’re all very good at pointing out whats wrong with code. There are even websites dedicated to exposing and ridiculing bad code and bad design, such as the daily wtf. We all encounter code that isn’t “right” on a daily basis, but how often do we do something about it and let our actions speak louder than our words?
It’s very easy to point out whats wrong with code. Pointing out how the design and implementation of the code we’re working with is making our lives hard. Talking with fellow programmers about how our hands are tied and how we “did what we could” given that it “wasn’t our code”.
This all too familiar discussion demonstrates what I call the maintenance programmer mindset.
Are you too stuck in this mindset? Its very easy to fall into.
I have to remind myself regularly to break out of this mindset; to be bolder, to have the confidence to change the direction the code is heading. To make a clear statement about the problem domain by introducing a new class. To factor out that bit of repeated code into its own method. To break that monolithic module into two more focused modules to regain control over dependencies. To grab the wheel and make the kind of changes that steer the design down the correct path. The requirements on an active software project change constantly, so the design must also.
It’s quite easy to see if someone is stuck in this mindset. The following are a list of the actions that make a statement about the direction a code base is heading, in order of impact and are unlikely to be performed by sometime stuck in this mindset.
- Adding new new module/package
- Adding a new class
- Adding a new source file
- Adding a new function
If your not doing most of the above on a regular basis, irrespective of if your maintaining software or doing green field development – your programming with the maintainance programmers mindset.