Jobs aimed for the simplicity that comes from conquering, rather than merely ignoring, complexity. Achieving this depth of simplicity, he realized, would produce a machine that felt as if it deferred to users in a friendly way, rather than challenging them. “It takes a lot of hard work,” he said, “to make something simple, to truly understand the underlying challenges and come up with elegant solutions.
Stephen Covey, in his uber-important “The Seven Habits of Highly Effective People” lays out a general principle that is as true in Software Development as it is in any other craft. The principle I’m referring to is that of the “First Creation”. You always create a thing twice. The first time, you create it in your mind, the second time you create it out in the world.
This principle is one that is very poorly understood by software developers. The reason that it is poorly understood is likely due to the lack of friction that exists between our ideas and and getting a representation (however crude) out into the real world. That is – with minimal explicit thought we can start typing into our ide – and get the Hello World version of whatever we have in mind to create in very short order.
And really – isn’t that how we love to start working on a project – we take pride in being able to sit down at a computer and start typing – and magically things begin to work. Not only do we love the praise and the instant gratification that comes from this – even on our favorite movies and TV Shows, this is how computer work happens. And of course – it’s really the obvious way to begin when we first learn to code.
So what we end up doing is a very quick, very intuitive “First Creation” – and then riding off like Code Cowboys into the sunset, sure that we’ll save the world.
There’s a problem that comes from this though. A quick, intuitive first creation gives us only an intuitive, vague understanding of the problem space. If we haven’t explicitly thought through all the road bumps we are likely to run into – we will only have a gut feel for them.
Intuition is a powerful thing – and our ability to solve problems without a complete understanding of them is one of the things that is really cool about being a Human. However – though you CAN solve a problem without understanding it entirely does not mean that you will solve it in a particularly good way.
Practically speaking – if you don’t spend some time *explicitly* thinking through a “First Creation” – you will invariable start coding like crazy only to run into many, many decisions to make that catch you by surprise. You will be able to solve them – but because you didn’t think clearly through things to begin with – the decisions will undoubtedly compromise your structural vision (which again, you’ve made implicitly).
The end result is – you end up with code rot long before you even get anything into production.
The State of Things…
Is the world going to end if you don’t put in the effort to perform a “First Creation”. No.
Will you limit your craft and fall short of your potential. Yes.
The systems you write DESERVE to be elegant, well-crafted works of art that not only perform the function for which they were created but also clearly communicate your intent to the developer that comes after you. Even if that developer is you – don’t you want to inherit elegant, well-structured code that takes minimal effort to understand?
Or if you like thinking in terms of negatives – the warning I’ve always heard is – Code like the developer that is going to follow you is a murderous madman that knows your address.
So how do we do this first creation? Am I suggesting months of documents and powerpoints to ensure we have exactly the right thing before we begin to code – NO!!! IN NO WAY AM I SUGGESTING B.U.F.D. (Big Up Front Design).
What I am suggesting is explicit forethought – I usually do this with some scratch paper and a pen – or with the ubiquitous white-board. Write out an object model – ensure that your objects are abiding by SOLID principles – and think through all the interactions until you feel you are comfortable and have a handle on everything within the scope of what you are building. Then start to decompose … then, and ONLY THEN – Code.
This could take minutes – or it could take a couple of days – but every developer involved in actually writing code should be comfortable with things prior to coding. Will it change along the way – certainly. Should you be explicit in your “First Creation” with regards to solutions to any changes – yes.
The first section here discussed having a First Creation for the whole feature you are creating – another aspect of the First Creation in software development is at the granularity of the actual code. When you create a class or a method or even a for loop – you should explicitly think it through before writing code. This would be obnoxiously difficult if we didn’t have a technological tool to make this possible.
That technical tool is called the Unit Test. When we write a unit test – we are creating client code for our actual production code. This forces us to switch perspectives to think about what it is we are creating and how it completes its mission. This change of perspectives allows us to quickly and with minimal context shift do a First Creation for every bit of code we write.
Creating elegant, simple (but not simplistic) solutions to the problems we face is hard work. It’s ultimately far more satisfying (and profitable) than hacking code together quickly and throwing it out the door. If you are up for it – if you are up for doing the work to intimately understand your problem space and deliver amazing solutions – well you are well along on the way to creating more incredible software!!
And the world is a better place when we create more incredible software!!