The Lost Art of Simplicity – My Take on Josh Holmes’ Brain

Any time someone stands up and says "y'all are doing it wrong" I take notice.  Then I usually lose interest.  But if that person starts to resonate with my own experiences, particularly my own frustrations, then I start to take it seriously.

I have been following Josh Holmes for a little while and he has a talk he started last year called the Lost Art of Simplicity.  I took notice. But I never lost interest. His basic spiel is that we developers make complex solutions for simple problems. Nothing surprising right? Except that he attributed it to ego.  Ouch.  But is that true? Have you ever met a software architect?

That might be a bit of an unfair statement to make but I think there's some truth to it.  And if it's not ego, then it WILL be pride. How do I know?  Because I'm just as guilty. There's nothing more satisfying to a software architect than people looking at your solution and not understanding it, then you explaining how it is a work of art, slowing showing them the beauty of your solution and them finally going "Man, that is COOL!" while secretly they fear actually having to implement it.

But as bad as I have been in my own designs I can say for certain that I have seen this problem many, many times when I worked in Zend Services.  Sometimes people would build these massive applications, find out that the performance sucked, call us up to tune PHP, or hopefully Zend Server (for various reasons I won't go into here) and then be frustrated when I would tell them that their problem is not PHP, their configuration or their tuning.  Their architecture was sucking the life out of the CPU.  And why? For no apparent reason beyond someone who decided upon building a structure that would make their CS professor proud.  I have a news flash for those people. Computers are best used when they are used to solve a problem, not to get you a good grade. Why is this?  Because the problem that's being solved is probably costing money. Do people really spend millions upon millions of dollars on "Enterprise" software because they have money to burn, or to stoke the ego of a software architect? No!

As you might be able to see, this is an issue I have an opinion on. And it is also why Josh's talk resonated with me.

Another part of his talk that resonated with me is when he said that the code you write will still be used in 30 years.  I heard that and I laughed to myself because I was thinking that nobody in the audience believed him.  However, having written a book on the subject, kindof, The IBM i Programmer's Guide to PHP, I have seen this first hand. The people that the book is targeted at are people who have been working with RPG for 20 and 30 years and are now wanting to move onto the web. We in the web world have been a bit spoiled.  We LOVE to rewrite software.  But at some point we need to move on and work on the next problem.  Once that happens, your code may not be changed for a very long time.

Don't believe me? PHP has been around for about 15 years or so.  I have, in my travels, run into code that was originally written for PHP 3 in 1998. This was last year, which makes that code base 12 years old.  I have also run into code written in 2000. That makes that code base 10 years old. With these two examples we're halfway to the 20 years that Josh mentioned. And let me tell you as well, the people who wrote that code wished that they had adopted the art of simplicity much earlier on.

So what's to be learned then? Follow Henry Ford's advise maybe: "Nothing is particularly hard if you divide it into small jobs". Small jobs are simple jobs.  They are manageable, easily repeatable and, by definition, cannot be complex.  Because if they are, they are no longer small.