Development is hard, it’s what makes it fun
Photo by Wendy van Zyl from Pexels
Every software project I work on, I’m convinced that creating software is a job for crazy people, and I must be one of them
I read this Ten Commandments For Living From Philosopher Bertrand Russell, it made me wonder what would be the 10 commandments for surviving software projects. If you want 10 commandments on how to be a software developer — ten commandments of egoless programming
Software projects rush to action, try to create software as quickly (and cheaply) as possible. This leads to software development teams agreeing to impossible plans and missing fundamental steps.
The initially priority should be to avoid disaster before thinking about how to create an environment for success.
Many projects I have seen started badly (no licences, workstations or internet connection) and go downhill from there. Software projects are a 12 round fight. Avoid getting knocked out in the first round. Give yourself a chance and stay in the fight.
- Creating software is harder and takes longer than estimated
- Let the business lead
- Ignore the noise — Think long term
- Never develop without signed off requirements
- Quality is the fastest way to create software
- Be prepared for anything that can go wrong, will go wrong
- Keep in sync — Only make changes in the development environment
- Keep knowledge in document, not in people or local machines
- Avoid disaster — Without trust, it’s over
- If it can be automated, it should be automated
The common approach is to oversimplify the software needed and underestimate the time it will take. This makes the team over confident and equipped with a plan that could be up to half the time it will actually take.
This is the worst way to start a project, but it’s probably what’s going to happen. Creating software is meant to be hard.
All plans are wrong, some are useful, they help to start, but they are not a great guide to how long creating the software will take.
The underestimated plan will encourage leadership to make stupid decisions to deliver the project to the original plan.
Creating software is hard, this is why developers are expensive. If it was easy, everyone would do it and there would never be a late a project.
Software projects aren’t late, they are underestimated. In software development, the obstacle is the way. Discovering requirements, changing designs, changing software is the path to creating the right software.
Nothing in Software Development Is as Simple as It Seems.
Users don’t know how the software should work and they often decide how it shouldn’t work when you show them what they asked for.
The purpose of a software project is to create software that helps the business. It’s not to build software to fit the plan, it’s not to create software that fits the technology chosen.
The software created should help users and the business work. Business users are the experts in how their business works. The development team needs the business experts to say how the software should work and the technical experts (development team) need to work with the business experts to design the software.
Solutions driven by technology can often end up hard to use because developers are guessing how it should work.
When developers decide how software should work and don’t clarify requirements they make assumptions. Assumption are bugs created by developers, they are discovered when users test the software.
Clarify all assumptions because assumption can be a bug and everything built on top of it being changed,.
Start with the business requirements first, not the technical solution
Everyone on the project will want to jump into action and start creating software. They will want to develop software as fast as possible and take every short cut available.
The project will try to add more developers to make the software go faster and faster.
These treat the symptoms, not the root cause. The symptom is the project is running late, but what is the cause. Todays short-term solutions are tomorrow’s long-term problems.
Creating software fast is a recipe for creating low quality code, bugs and technical debt. It will seem fast for a couple of months and then the technical debt will slow everything down and problems will spring up.
The faster you go, the more chaos you create. It’s not an environment for creating quality software.
Software developer is a losers game, the development team that creates the fewest problems will succeed. If you avoid making mistakes, then you will make steady progress.
Good software development teams resist the shortcuts, don’t panic and think long term and aim for quality.
The Best Decisions in Software Development Have Long-Term Benefits Not Immediate Benefits
It’s vital to control requirements and come to an agreement on how requirements will work.
Only must have requirements should be developed. The project needs the discipline to focus only what is needed.
This needs direction from business leadership for users to only include must have requirements. The more requirements, the longer the project will take and the more complex the software will be.
If users are not told to have this approach, they will act like children in a sweet shop and start asking for functionality that makes their life easier (but takes longer to create).
If the requirements change, the plan must change.
Additional requirements are more work and the project plan will need to accommodate this extra work. The development team needs to avoid requirements being added, but the project plan not changing.
This is a no-win situation for the development team, they will miss the deadlines and blamed for late delivery. The project isn’t late, there are more requirements.
Software Development Is Misunderstood, Quality is fastest way to get code into production. Non developers think creating software as fast as possible, taking shortcuts and throwing as many developers as possible is the fastest way to create software.
Quality is the shortcut in development. Quality reduces complexity, technical debt, bugs and helps you manage change.
Software development is a marathon, it’s about making smooth progress towards the goal.
Quality is important because the plans will be wrong, designs will be changes, bugs are found, problems will occur, mistakes are made and things will go wrong.
Quality needs standards, and code reviews and automated rules to enforce those standards. The best time to fix technical debt is before you put it in.
Keep your environments synchronised and find as many problems in the non production environment as you can.
Problems found in non production environments are annoying problems where you lose a few hours or days but resolve them calmly.
Problems found in production are panic stations, emergency meetings, people panicking and working in the night or weekends. The amount of people involved in production issues makes them harder to fix.
Find problems in development environments, it means the process is working.
If you the environments get out of sync, you test on environments that are not production like. Production will be the first time you test your code on the production setup and the first time you can find the bug is production.
Standards, processes and documentation brings order to the complexity of creating software.
If you don’t create order then you will get chaos and the development team will have lost control of the project.
Processes and documentation bring order and everyone on the project knows what they should and when they should do it.
Good developer documentation means that developers can leave the project, but still everyone will know what to do it.
Avoiding stupidity and disaster is easier than trying to create great software. Make sure you avoid disaster and stay in the game.
If you can avoid problems, disasters and other terrible things, then the development team should make steady progress. As long as you keep moving forward, you are getting nearer the goal of creating the software needed.
Things that can go wrong on a software project will usually go wrong at some point. No matter what steps you put in place you cannot avoid all the problems.
You cannot avoid technical disasters but they should not catch you unprepared — WHAT!
You read that right, I’m telling you to avoid disaster and then saying it’s impossible. You need to make sure you put in best practices so that when something goes wrong, you can recover quickly.
The same way an Azure servers work, they know it’s impossible to stop servers crashing, so they recover so quickly no one notices.
In software projects, you should have everything in source control and DeVops setup so you can restore an environment in hours. You should be able to fix and deploy that code to production in hours.
If a development teams has an increasing amount of problems, particularly production problems then confidence will drain away and trust is lost.
If the confidence in the development team is lost, it seems they aren’t in control then the business will stop listening to them and the project will eventually grind to a halt.
Any software project longer than 3 months should use DevOps and automated deployments. Manual deployments are boring, error prone and take the fun out of creating software.
Skilled software developments should not be doing something that you can write code or setup DeVops to do for you.
Automation increases deployments and creates faster feedback. If deployments are hard, then they won’t be done often.
