Growing up I was always what you might call an “instinctive techie”. I wanted to take things apart. You’re probably heard the story before: one takes things apart to understand how things work. With some people it’s insects or animals, with some people it’s clocks or cars or mechanisms, and for me while there was a bit of a mechanic in me I also really liked taking apart electronics. So if I’m a techie why am I telling you that it’s time to stop overcomplicating your projects?
In the 80s you could take a good look at a piece of electronics and without any real training or manual work out what pieces did what. If you had enough time and enough patience you could usually understand the major pieces of it. I spent hours and days working on understanding circuitry all without any equipment. When I didn’t understand what was going on I could still observe what changed when I removed things and when I put things back together.
This is a technique that I still use to this day with any systems that I work with. I bought an old car, the trunk release catch didn’t work but I could hear that the relay was working (or it sounded like it was working) so I took a couple of relays out, swapped a few around and now the trunk release works. Probably something else is broken but we’ll come to that later!
The point is there are systems everywhere and sometime in the past someone designed them a certain way for a reason. To be able to think about the system you need to think about the designer and what they were hoping to achieve. The same can be said with software systems that you build or buy.
Why do software systems become so complicated? Why do so many projects fail? Why do I need to spend so much time and effort to understand them? Likewise, to understand how a software system gets so complicated you first need to understand the people who put it together.
A programmer sits in front of the keyboard and turns something in her head into a system that does something to help herself (or somebody else). When she does this she has to make a ton of assumptions all the time about how this system works. While she could spend days, weeks, or even months to come up with a detailed spec on how a system should work – things change.
Specifications change. We have new thoughts, new requirements, we need new stuff doing. Expectations change. Unlike these changes in specification, software systems don’t change – they are designed to do the same thing over and over again.
So how can you make sure that your software system or your software project has a chance of doing what you expect it to do?
There are many ways of managing these processes – be they waterfall or agile or when neither work perhaps you get wagile. These are just attempts to manage something which doesn’t always want to be managed. While you can have very successfully managed projects the most successful ones don’t attempt to do too much at one time and have a very focussed specifications.
So take out all the features you don’t need. Don’t overcomplicate things. Use systems as they are intended. Don’t customize them if you can avoid it.
Spend more time thinking, less time acting.
Your systems will only get more complicated with time. This is the nature of systems. Start simple, keep simple. Avoid big solutions and big-bang implementations.
It’s time to stop overcomplicating your projects and your systems with unnecessary features. If you need a hand understanding what’s complicated and what’s not then you can always check out my free resources.