Three Management Pressures That Drive Poor Development Decisions
If you’ve never managed a software project before, it’s very likely you’ll make these mistakes.
Successfully managing a software team relies on your ability to deliver on expectations while providing the team enough time to properly build your application. And while you do this, you’ll face at least these three pressures that will make your job even harder.
“I don’t know if this is going to be worth it (so let’s skip the tests)”
If your application doesn’t solve a new problem it is best copied from existing libraries and tools. This means that most of your team’s work will be research and development, in other words, it will be exploratory work to build something that’s never been built before. How will you know it’s worth your time to build?
As your team explores, you’ll be tempted to cut corners and explore new development techniques and ideas without quality control. If you continue on this path you’ll end up building software without quality control in an effort to explore more areas quickly. Press on and you’ll find yourself building large portions of your application this way out of habit.
This all works fine for a while, but it catches up in the form of seemingly unsurmountable technical debt. When the useful parts start needing their own changes, you’ll find yourself with a difficult mess to clean up before you can begin to make forward progress again.
Exploratory programming is useful, but should be used sparingly and marked as a “prototype” so it’s not confused with production quality work.
“We’ll come back and fix it later”
When things break, you’ll feel immense pressure for the quick fix. A few minutes from your team and you can put that bug away forever. But does this actually work? If you don’t have the time to do it right, when will you find the time to do it over?
With a long enough lifetime, all projects will succumb to this pressure at some point. When that happens, new code is added that’s essentially undocumented and will need to be maintained. And there it will sit as a future risk to your project, undetected until it yet again needs a fix.
This is going to happen to your project. It is unavoidable, and that’s okay as long as you have a strategy to handle it. You can document the quick fix after the fact by adding test coverage but you have to schedule this work at the time of implementation, and then make sure you find time to actually complete the work.
This pressure can be put off for some time, but sooner or later, you’re going to face it. Have a plan for when that day comes.
“We don’t need to upgrade”
Any software project under active development that still uses older versions of libraries and tooling gives up speed and security advantages to its competitors. This pressure occurs when the demand for features appears to outweigh the benefits of staying current.
You can lag shortly behind the current versions of tools (for example, a Ruby on Rails framework, which you can upgrade here), but doing this means you give up access to all new features provided by newer versions. Continue down this path long enough and you’ll find your application is no longer supported.
When support runs out, you’ll face security vulnerabilities and a shrinking (read: more expensive) pool of talent that will never, ever grow in size.
This pressure is one you’ll face when the requirements on your application are greater than the resources you have to complete them. Basic software maintenance should not be ignored as you’ll find it’s only more expensive with time and slowly the advantages you give up will add up to something that places you at a real vulnerability for disruption.
The list above is just a few of the lessons I’ve learned through developing software projects with Reenhanced since 2005. If you find this helpful, I invite you to connect with me at Agile As A Service where we can discuss how to improve the quality of your software project. Our most popular tool is a set of automated tests we’ll build into your application that will improve the quality of all code developed by your team.