Boring is Beautiful in Software Development
Excitement is a warning
Software developers uniform should be cardigans and slippers with some relaxing music of birds noises
No matter how good the developers are or how hard they work, creating software takes time. You cannot produce unique, complex software quickly. No substantial software is creating quickly, no matter what the plan on a page says or how many developers you throw at it.
Software development should be a boring, follow the process, do all the steps and aim to create quality software.
The faster development teams try to create software, the more mistakes they make and the slower it goes.
Software development is technically exciting, using new technology, creating new processes, automating steps, saving time and turning requirements into software.
The execution of the software development plans should be boring. Steady smooth progress where you follow the process and progress towards your goal.
Creating software should be as sexy and exciting as watching a marathon. It’s not full of runners sprinting, unexpected tactics or sneaky moves. The runners keep progressing towards the finish line, mile by mile over many hours.
Excitement is warning
When you hear of hero developers who had to work throughout the night to deliver software, this is a warning.
If developers are working throughout the night, then the estimating is wrong, planning is wrong, or something else is wrong.
Bugs and big problems get everyone excited and emergency meetings are called. This is bad, developers don’t like all this stress and disruption.
You cannot sprint a marathon. If there is constant excitement, it burns everyone out. If there is too much excitement, it's an indicator that expectations are too high and not being managed.
Rushed decisions are often bad decisions, forced to decide quickly, focuses on the details and lose sight of the bigger picture. Rushed decisions create projects which do lots of re-planning and can end up going round in circles.
Meetings and plans
contrary to popular belief, meetings and plans do not make development teams create software faster.
Most of the noise, fuss and tears on software development projects are a distraction to the development team and slow down it down.
Constantly measuring story points and the creation of features isn’t measuring the progress of software created. Creating the wrong software looks like good progress, but it isn’t.
Software that is 70 percent complete means nothing because the last 30 percent could take longer than the first 30 percent.
Plans are always wrong, reality of creating software is it can take twice as long as planned because the requirements change and problems happen.
Constantly monitoring software development teams and getting misleading progress reports doesn’t make creating software any faster.
What creates software is developers creating software, testers testing it and users trying it. This circle of development goes round and round until the right software is created.
Shortcuts and rushing
The faster software projects try to go, the more mistakes they make
Most of the exciting events on projects are
- Production issues
- Missing deadlines
- Bugs
The issues are symptoms of a system that's not working correctly. Missed deadline is because of something else going wrong (incorrect requirements, optimistic plans).
The more issues created, the more quick fixes are reached for. Missed deadlines result in adding more developers, but if the cause of the missed deadline isn’t fixed, then this adds to the problems instead of fixing them.
You cannot get time back on software projects. I have never seen a development team catch up on time, unless requirements are removed.
Follow the process
Like running a marathon, creating software is steady progress towards the goal
The steps in software development are good practices to help teams find problems as early as possible, where they are easier and quicker to fix.
Software development is the opposite of Trainspotting :-)
Instead choose
- Choose quality
- Choose to do every step in the process
- Choose to not go faster but to go at the speed it takes
- Choose quality
- Choose testing
- Choose documentation
- Choose DevOps
- Choose Code Reviews
Software development is like a big tanker. You can’t change quickly or change direction often. It chugs towards its destination.
Good software development follows the process, reduces the mistakes and aims for quality. Quality code is the shortcut. It’s the fastest way to develop software is by aiming to create quality software.
When you miss steps, time saved today is lost to problems later. Today's solutions (bad code) will be tomorrow's problems (technical debt).
Conclusion
Development teams should embrace being boring and go steadily about the work of creating software.
Rushing or missing steps should be a last resort and will create problems later. You never have more time in the future, you have less because the code base grows in complexity (and problems).
The only people who urge development teams to go faster are non technical people who don’t know the consequences of going faster. Ignore them, be boring and follow the process.
