Self-brewed complexity is evil – fight it!

Creative Commons License gurdonark

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.

2 thoughts on “Self-brewed complexity is evil – fight it!

  1. Word.

    I blogged something similar a few months ago. I know a guy whose vertical-market applications have been in development for five years but they will never get done. He’s more interested in maintaining the illusion of working on something awesome than in, you know, having a viable product.

    If you’re doing a project for a specific client, always take that minimum path to quality. The software that doesn’t work or never gets done is useless no matter how many cool features it “will” have.

    If the software is totally speculative, perhaps something for repeated sale to an unknown market, you are still better off delivering something simple that works in a month, rather than waiting a couple of years for something magnificent to be finished. If you insist on magnificence anyway, know that it starts with something simple that works.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.