Self-brewed complexity is evil – fight it!

It’s amazing to see again and again how teams complicate their lives without any necessity. They dream up features “urgently” required by their imaginary customers and then start a death march to launch them at an arbitrary, self-invented date. Why is it so hard to simplify things and get going? Let’s have a look at possible reasons and ways to fight them.

Excitement

If you start something new, everything seems possible and you nearly burst by all the energy which that excitement gives you. You start collecting your great new ideas like gems and you’re convinced that every single one is a “killer feature”. Soon your feature list has 50 prio one entries, which you need to do all at once! Otherwise, your product can’t be launched – you think. Of course, nothing could be further from the truth. As long as you’re not designing a space rocket, you can always add something later. And, if you use an agile development approach, it will even be fast and continuous.

Fear

Even worse than excitement (which is not a bad thing in itself, of course) is fear. If you fear failure or you fear that you cannot change something later, you’re really doomed. Fear switches off a big part of your brain capturing your thoughts in a small, dark corner where no other ideas are allowed to reach in. If someone suggests a simpler way of doing things, you panic and fight that idea with all your might. Obviously, fear is not the best guiding principle when building something.

Establish a rhythm

The best way I found to fight fear in a project is to get going. Sort your priorities into a backlog, take the top most stuff and just do it! After a week or two you’ll see the first results. This is good in two ways: It will remedy your fear that you’ll not be able to get something done and it will give you a way of actually putting facts on the table. Instead of guessing for months you can start using what you build. That will give you confidence and new ideas. Use Scrum or Kanban or whatever agile practices you see fit to get there.

If in doubt, leave it out

If you build less, you have two big advantages: You get it done faster and you have less to maintain later. These two advantages cannot be overrated. As you know, most of the efforts spent in software development go into maintenance. The time spent fixing what you’ve made is lost for doing new stuff. So if you don’t build something in the first place, you don’t have to spend tons of effort to maintain it later. And, your users will love you because they too have less to learn and less bugs to live with.