The Software Evolution Hasn’t Happened Yet

If the hardware has followed the Moore’s law, what happened to software? We have built assembler, and compiler, and high-level language. And now we have powerful machines, and all these shiny new languages and frameworks promising productivity. So why the hell are we still providing lame software?

The software crisis

According to Wikipedia, the term “software crisis” was coined by some attendees at the first NATO Software Engineering Conference in 1968. The crisis manifested itself in several ways:

  • Projects running over-budget
  • Projects running over-time
  • Software was very inefficient
  • Software was of low quality
  • Software often did not meet requirements
  • Projects were unmanageable and code difficult to maintain
  • Software was never delivered

That’s a good sum up of the problems I’ve met in 10 years of recent software development. And apparently, I’m not the only one, some of us talk about a software apocalypse.  It’s both confusing and sad to see that our industry’s perception hasn’t changed. What could be so hard about software? Why do coders write so much bugs?

The software labor

Software has always been, and still is, underestimated. Have you ever think about the names, hardware and software? These names reflect the roots problem of our industry. We believed that the building of physical electronical device will be the hard part. Nobody has anticipated the fact that programming these machines could be complicated. That’s why the first software programmers were women. We cannot be proud of that, it was just because some highly respected (male) scientists of the 50th believed it would be an easy task.

This fundamental misconception is still widely spread today, especially for people who never tried to build a software by themselves. It explains partly why our profession is underestimated and poorly managed. Very few people understand the implication of a “soft” device. Thus, they try to apply what Fordisme and Taylorisme has taught to them: hire some managers to manage an army of low qualified people to work on chain production.

The software engineering

Software is, by definition, not a physical thing. It removes constraints, physical and temporal. You want to change a past event? No worries. We can build rules, and break them as we wish. You want to change a behaviour? Let me add a few conditions. We’re not constrained by time or space. Not even by logic. We are only limited by our imagination. (And a bit by the computer power and the money we’re supposed to earn with the software. But as hardware is really performant, and because IT generates so much money, the main limitation is still our imagination.)

How do you build a bridge? By a series of calculation and drawing, taking in account a huge number of parameters from the physical environment, in order to use the laws of physics to assemble physical components in something that will stand for a while. But mathematical and physical laws do not apply to a soft world. A world where almost any rule can be broken. A world where the number of possible states can be greater than the number of atoms in the whole universe. Standard line of business applications have a complexity that we cannot manage (it is common for us to not accept this fact). And to add more fun, even if we manage to make it works pretty well, we are still not sure that it will solve any actual problem.

A doom’s profession?

Rather a huge opportunity I think, because software root problems are the same since many decades, we can be the actors of its evolution, and learn from our short history. From the easiest to the hardest, here are a few propositions to improve our craft. Sorry if some might seem obvious, but as a software professional, I’m in a good position to know that it is not.

Let’s start with the basics: automating tests. I won’t re-explain here why and how. But we need to acknowledge that it is currently one of the best way to manage this invisible complexity. A series of automated tests to validate the behaviours of the software as it evolves. It’s a way of feeling what we are designing. Like with WYSIWYG, we want to see immediately when an expected behaviour is broken, and what will be the impact of our modifications.

Another point is to use less states and more types, because it is where the complexity hides. Mathematically, specialized types do reduce the number of possible states in functions outputs. Solution like Property Based Testing can help to test the limits of such systems.

A harder way is to understand the problem we are trying to solve. There is no clear separation between the pure technic, and the design of an appropriate solution in software. Which explains why there can’t be a clear separation between the maker (the coder) and the the thinker (the system designer). To be good, we need to understand the business and to be technically efficient. This is where Domain Driven Design and relative stuff like Living Documentation can help.

And finally, we can learn and apply more maths in our code. It fundamentally adds some laws in our chaotic soft world. Some laws that will highly improve the code, like avoiding side effects and mutable states. This is where Functional Programming and TLA+ can help.

Think out of the box

Finally, we need to remember how young is our industry, and the fact that we’re living a crisis since the beginning. It means that we need more imagination to solve our problems. For that, I encourage you to listen to people like Alan Kay or Victor Bret, and to learn about our history. What if written software is just not the good way to make it? What if we are still living the dark age of software development?

We build a lot from (too) small foundations, maybe it’s time to challenge ourselves.

 

Of course the title of this post is a refererence to an amazing OOPSLA conference by Alan Kay: the computer revolution hasn’t happened yet.

 

Diverse IT

Here is another privileged white guy who stand up to talk about diversity. Let me explain why.

Google memo, Uncle Bob and the SoftwareCraftsmanship community

If you didn’t follow this thread, you can have few information here. The thing to understand is that it’s a big matter. There are lots of anger, misconception and bad explanations, between smart people. I would like to testify as the average privileged developer why I ignored this matter for so long, and what I decided to do to care about that. Because as Martin Fowler says, “you can’t choose if you hurt someone, but you can choose if you care”.

A long ignorance

I am a passionate developer, and I do respect competent people. I really don’t care if they are higher in hierarchy, if they are men, women, black, white, gay, if they believe in any god(s), if they have lots of experience or if they are juniors, if they drink alcohol, if they eat meat, if they wear suits or t-shirts… I just do care about how competent and passionate (the two are generally connected) they are.
And because of that, I believed that I had the good behaviour. I deal with everybody in the same way, that’s fair isn’t it?

A spark of light

But then I meet different people and attend to different conferences, especially in the Software Craftsmanship community, where I learn so much about this topic. And thanks to them I realized two important mistakes I’ve done: assuming that equality is enough, and assuming that I’m not legitimate to talk about it.

 

 The equality inequality

Treating everyone equally is great. But it’s unfair at the same time. If you were a woman in the twentieth century and won a Nobel’s prize, are you equal or better than other Nobel’s scientifics? From a pure cognitive perspective, you are probably equally smart. But to achieve the same scientifics result in this male world, you probably must fight much more. You must fight for your rights, to be recognized by your pair, much more than an average white man.
The same thing happens in IT today. We must acknowledge for example that to be equally recognized in our field, women need to work harder than men.

 

The legitimacy paradox

Because I didn’t feel legitimate on this topic, I didn’t talk about it. But because I never spoke about that, people like me might think they should not care about it either. Worse, it’s always the same legitimate people who talk about it. But what if they would like to talk about TDD or CQRS/ES instead?

What to do?

First, we have to be careful in our talks, especially in public presentation. Be careful about genders, when we use guys, he, craftsman and so on for instance… Of course, it is the same thing when we write blog posts and when we use twitter.

Every day at work, we can watch our jokes and behaviour. Watch other jokes and behaviours as well, learn to identify when someone is hurt, and let her (or him) know that you care and you will do your best to avoid that it happens again. And when we hurt someone (because everyone can make mistakes), we should just apologize. No need to look for excuses, just apologize. Uncle Bob unfortunately gives us a good example of what not to do recently.

As I already said, it’s important to speak about this, at work, in conferences and everywhere, especially if we are part of the privileged guyz.

It’s far from enough to fix the problem, but it’s a start, and at least, it shows that we care.

 

 

Thanks to the awesome Franzi who specialy helped me to grow up on this topic.

 
IP Blocking Protection is enabled by IP Address Blocker from LionScripts.com.