Some thoughts after five years of software development

It’s now been five years since I switched from IT operations and procurement to being a software developer, so it’s a good time for reflection. The following are some of the thoughts and insights I have gained during this time, in no particular order:

Whenever a single developer has an opinion, it’s usually wrong. When a team reaches a conclusion together, it’s usually right.

Software project estimation is pulling numbers from a model and trying to convince everyone involved that there’s some magic connection between the model and what the developers are building.

Software developers tend to be right about the details but wrong about the big picture, because your organization keeps them isolated from it.

Agile development means that organizations constantly and willingly adapt to the needs of people, not the other way around.

Humans can be productive for a few hours and digest a few nuggets of new information per day. This is the basis of agile development, the one thing you must adapt to. Large teams, lots of meetings and lots of different simultaneous contexts will destroy your dreams of financial success and make you a bitter person.

Software development is 80% human interaction and 20% writing code. The pandemic and remote working changed this in the wrong direction and now we talk too little and write too much code.

Do not plan complex things remotely. Plan together in the same room with markers and a whiteboard.

Do everything together, regardless of roles: designer, user, developer, tester.

Do not plan anything in detail until you’re ready to implement it right away. Preplanned tasks will rot on your backlog and make everyone involved depressed and dream of becoming a gardener instead. Why are carrots so hard to grow, by the way?

A good backlog has zero or one items on it.

If an item is on your backlog too long, kill it. It will return if you really need it.

The code doing what it should and the code doing what it should fast enough is not the same code.

Stress makes people dumb. A lot of stress makes people dumber. Avoid it unless you aim for failure.

At least three people are required to solve hard problems. (This is based on research.)

It’s impossible for users to say if a planned feature will work or not by looking at designs or demos with limited data, because it’s very hard to extrapolate from something abstract into doing your actual work with your own data. This means that developers must adapt how they do software development to the cognitive limits of users, who are still people the last time I checked. Give users a nail and a hammer and not a picture of them.

The full-stack developer who does and knows everything is a myth. Dare to specialize.

Pull request reviews are inefficient. Work together and sort everything out during the implementation instead. (Got this eye-opener from Allen Holub.)

Do not put bugs on a backlog. Fix them immediately. If they don’t need to be fixed, they’re not bugs. (Also from Allen Holub.)

Most so-called agile projects are waterfall projects with fancy hats.

Asynchronous communication equals long feedback loops. Avoid it.

A project manager or scrum master not doing software development themselves cannot be good at their job, because they don’t understand what they’re trying to manage.

You can start with Scrum, but you need to move beyond it. Never do SAFe, it’s a zombie dinosaur dressed up as a dog and will crush the soul of every free spirit it touches.

Unless you can get customers involved and get their feedback on development progress daily, you’re not agile.

You can easily ignore everything that’s written and taught about agile software development and focus on Lean development instead, with two exceptions: Mary Poppendieck and Allen Holub.

Strive to release to production daily. Small changes will set you free. Nobody understands what a bigger change will lead to.

In projects, focus on having working software running in production from day one.

Organizations seldom become agile software development organizations, because agile requires changes to the organizations themselves.

Good software development practices have a lot more in common with boy-scout rules and the samurai bushido way of conduct than processes and tools.

Teams should not be larger than five individuals. The need for interpersonal communication kills every ounce of efficiency when teams grow. Split up and keep small.

Manage complexity by only doing things in small pieces.

If you don’t understand something, split it up.

Agile development is splitting big things into smaller things.

If any of your feedback loops feel too long, something is wrong, and your ship is heading towards an iceberg right now while you’re waiting for that mail. Shorten the loops, all the time.

If all stakeholders work physically together as a team of equal members, you solve 95% of your communication problems. (And the last 5% are unsolvable anyway.)

You need short feedback loops because software and information are fresh fruit: they start to decay the minute they are created. A feature tried out a month after it was released is out of date, a mail written last week is today irrelevant and probably stinks, too.

Software quality is so hard because you must think about it all the time.