Tag Archives: Programming

Software Minimalism


Complexity baffles

Well, perhaps minimalism is not the right word for what I mean, but it reflects a very important characteristic: simplicity. As a software consultant I often find myself moving from project to project and tackling different kinds of problems. But among the most common of the problems it’s over-complexity.

Complexity is the worst enemy of a software project. And it’s even worse when complexity is not even required to build the respective solution. The latter I call viral complexity because it spreads like a deadly virus killing team motivation, product quality and adding unexpected costs for future development and support. This is the sad death of many software products.

How it all starts

In most cases it all starts with a blind rush. It’s a simple requirement, a small project and needs to be ready yesterday. So we’re looking for the simplest solution that will work given our situation. We do a quick hack and voilà! The whole thing is up and running, ready to be delivered. We have little time to congratulate each other because the business comes in with more requirements. We’re supposed to be agile and embrace change so we adapt our hack to include the new changes. But again, there are more and more and more. Soon enough our hacky solution becomes a major point of complexity as we’re not merely adding features to a project, but we’re adapting a hideous hack to support more and more features for which it’s not adequate anymore.

Hurry, hurry, hurry!

By now the business is happy with the results and learns that giving just a small set of requirements for implementation upfront works great. Agile really works! They also congratulate themselves for putting pressure on the development team for releasing something quickly. What they don’t know is they’ve built a long queue of technical debt which, like all debts, is expensive. And they don’t even know they need to repay it.

The requirements keep on coming in and the developers struggle to implement them. Some never get done, others take very long. People outside the project will soon start wondering what’s going wrong. But do they really want to know the truth?

The Truth

The truth is the project started with technical debt, that the quick hack was intended to be a short-term solution to a more complex and time-consuming one. This means that as soon as the initially simple product was deployed in production, the project should have started from scratch. That didn’t happen and created a huge pile of issues that no one is willing to take the blame for.
Now it may be too late or too expensive to start again. It may also be the case that the business doesn’t really understand all this and plainly blames the developers. And so they should!

The best cure is prevention

When the business comes in saying they need a product and they need it fast and when they say it’s something simple and should take a very short while and it’s a key thing for the entire company’s business and needs to get done — it’s not the right time to panic, it’s just the right time to say no. It’s just not possible to do it without many side effects and if the business is ready to pay for the technical debt, they’d better be ready and they really need to understand this is not just developer fuss about something that not beautiful code or unprofessional. It’s just expensive.

When you want to buy a car and don’t have all the cash, you take a loan. But you know the loan comes with interest and in the end you’ll be paying more. That’s acceptable if you really need the car now and can’t wait to save the money and then buy it. The same way the business needs to now that soon they’ll need to start paying for the technical debt before adding some more features to the product.
Lack of repaying the due technical debt leads to greater complexity as adding more features to an inappropriate structure is complicated. The more features are added the more complex it becomes and harder to understand.

Start simple, keep it simple and self-explanatory

A good solution explains itself. It doesn’t require documentation, experts, expensive consultants or even code comments. Some will say these are just words and it’s easier said than done. I disagree, it’s all in the attitude.
First everyone needs to understand that we’re better off adding fewer features, but making them part of a simple and self-explanatory system. It’s always better to have a simple and stable product than a clunky one.
As more features are added, keep refactoring the system so it adequately grows to house the new functionality. If you need to build a skyscraper, it needs a solid foundation. If you start with a tent, you can’t evolve it into a skyscraper without refactoring the foundation several times. This is part of the development cost so we all need to live with it. It’s just common sense.

Think before you write code

Ask yourself before committing to a solution: is this simple enough for a newly joined developer to understand? Is this the standard way of doing it so that other developers would easily understand what we need to do? Are we using the right tools and technologies for the job?
Don’t just accept something because it works. If it’s not simple and straightforward, it’ll just bite you back soon enough. And although this is not a functional feature and no one will actually pay for it, you must make sure the system is covered by tests that not only certify its stability, but, most importantly, documents its behaviour.

Will we ever learn?

This words have been said over and over again for the past decade and still I find projects making these mistakes. I can’t stop wondering why are we never learning?

Software and Fashion (really?)

I haven’t met many software people who followed fashion, in fact many of them despise it. So several times I’ve heard why: fashion is so superficial and dealing with such shallow things that is not the thing for a geek spending hours in front of the computer trying to optimize loading data from the database with the new and cool ORM, or trying to figure out how to fix a security vulnerability in an Internet Banking application.

I’m not so sure this is right, not even sure it’s a good idea to think this way. Because building software is much like fashion design.

What? No way!

Adopting a great clothing style creates a wonderful image of yourself in the eyes of the others. No need to tell anyone how important is to dress up for the occasion, but let’s try to figure out what’s really going on.



Dressing up, having a nice style as well as being in fashion has a big impact on the people you interact with. Remember the seeing is believing saying? Seeing has an insurmountable psychological power on an individual because perceptions are built upon data sent by the senses (and sight is quite important among the others). That’s why people easily believe what they see. For example, it’s been quite hard to accept that the Sun is not actually moving around our planet as it looks like, but the other way around. And humanity accepted that, again, after seeing it using telescopes. What we see is utterly important and hard to ignore even if judgement dictates otherwise. So this may be shallow, but that’s the way we function and going against our nature is not feasible in every circumstance.

Geeks can dress up their software instead

Now it’s true that not many programmers go out much in a sense they need to create a good impression by using the latest and trendiest fashion outfits. So I agree fashion may not always serve them unless they take to a more un-geek career that requires relating with people a lot, managing, selling stuff or something similar. Spending most of your time in front of a computer makes fashion pointless.

However I want to point out that the geekiest of geeks that may live in a basement and spend 99% of their time in front on the computer screen still interacts with the world through the product of his/her work — something we normally call software.

The software product is my social outfit

We build software for users. Sometimes they are corporate employees, sometimes they are homeworkers, single moms or rebel teenagers. But they will almost always judge us by the software we’ve built for them. The same as folks on the street may judge us by our clothes.

Being out of fashion in software may be dramatic as users would part their ways. So what I’m trying to say here is that building software may have a lot more in common with being a fashion designer than we may have previously thought.

Software too is a matter of image.