Thursday, July 13, 2006

Abstraction

Joel on Software recently published an article about the Development Abstraction Layer.

As a summary, he says that developers should be isolated from the business. They should not have to concern themselves with any of the infrastructure or business processes superfluous to developing the programs that will make the company money.

Not once in his discourse does he use the word “productivity” though. Yet, ultimately this is what it’s really about. Developers cannot produce solid reliable code when they also have to think about changing lightbulbs, filling in timesheets, answering someone else’s phone calls, or if the network is operating optimally. Every interruption from the deep concentration required for creating complex systems knocks the developer back by hours. I used to estimate this setback was about 20 minutes, but from recent experience, it could take me up to an hour a time to get back into the mindset and pick up the train of thought.

A thread is a particular line of work to be done. In the game example, building an army will be one thread. Making sure that there is a balance of archers, swordsmen and musketeers is a sub-thread of that.
When we refer to multi-tasking, we mean juggling the priority of all the threads and acting on them. Usually this will involve switching rapidly between the threads and sub-threads making sure each one gets the appropriate level of attention. In the game example, while being attacked, I have to move up troops to my line of defence, but also keep other essential services progressing.


Have you ever played an involving strategy game like Cossacks: Art of War or, even simpler, C&C Red Alert2? Consider all the threads you have to keep track of at any one time: farming and mining, exploration, defence, expansion, advancement up the progress tree, and the tactical and strategic military proceedings for defeating your enemy. Each of those have as many sub-threads as there are little men on the playing board. Neglect any one, and the chance of victory is significantly diminished. If you’ve never attempted to seriously have a go at one of these games you won’t know what I’m talking about. Let’s just say a large scenario, with a challenging opposition, comes close to the boundaries of the multi-threading and multi-tasking a human brain can perform.

In a similar way, developing software needs considerable concentration on lots of different threads. Database connectivity, the data itself and its structure, all the variables and their current states, interaction with other components, language syntax, framework and design patterns, business logic, future enahancements, usability, accessibility and front-end design, performance issues, and even organisational best practice. All within a deadline.

Without Mr Spolsky’s abstraction layer, those deadlines are doomed. Or more likely, the deadlines are met, but the quality and available functionality is out the window.

I’m quite sure this doesn’t only apply to developers – every fee-earning worker would be more productive if the abstraction layer is working effectively. Trainers, consultants, pilots, welders, nurses, and even the fellow on the factory floor that clicks caps on cans of concentrate.

So in conclusion, a big shout out goes to all those people who work in Business Support type roles. You make sure the toilet flushes and that the coffee is brewed, and for that we sincerely thank you!

0 Comments:

Post a Comment

<< Home