Over the last couple of years I have been working with a number of the industry leading business process management platforms. During that time, I have formed some pretty clear opinions on the decisions we will face when working with them. I thought it might be useful to share.

Things to Fear

Given the inquisitive nature of developers, and the lack of experience held by clients, it's hard to quantify why something should be feared - often we don't find out that something is a bad idea until we have experience - it's the classic "chicken and egg". These are the concepts I see as the most important;

• Long processes
  If you have a really long process drawn out on a piece of paper, don't imagine for a second that it will be implemented as you imagine it. You're going to chop it up - even if you don't think you need to. Deciding where to make the cuts typically comes down to two questions - "where does it loop", and "where might it sit dormant for a long time". Try to think of a process as something happening - not the entire model of the way your organisation works.
• Beware enterprise-wide roles
  While developing a process, you will decide that various subsets of users need to have tasks delivered to them. The thing to remember is that each person in an organisation may have different roles for different aspects of their job - or between projects they work on. Therefore, think very carefully before implementing any kind of role discovery across the enterprise. What we're really thinking about here is Active Directory, versus SharePoint Groups. Every sensible bone in my body tells me that workflow processes should be supported by SharePoint groups - which can be assigned on a site-by-site basis without impacting Active Directory business units.
• Carrying data in the process
  I have touched on this before. Do not carry business data within the process if you can avoid doing so. Ideally, the process should manage routing, destination and delivery only. Storing business data inside the process causes a world of problems around data integrity and synchronicity. The basic rules should always be to look up only that which you need to know, and act on it immediately.
• Implementing complex business rules in the process
  There's a simple answer here. Don't do it. Keep your process simple - and never, ever base the routing logic within the workflow directly on business data - always abstract it. Abstracting both the computation of business rule data, and the interpretation of results protects your process design from future changes.

The Integration Dilemma

Knowing that you can build rich processes that integrate with enterprise content management systems doesn't answer how you should approach doing so - and it's a surpringly difficult question to answer.

The following two considerations are important;

• You need to decide if your content is going to support your process, or if your process is going to support your content. Which will be tailored to fit the other? Given the ease with which infrastructure within platforms such as SharePoint can be provisioned, it makes sense for specific areas to be designed around specific processes. Where process is being applied to pre-existent infrastructure, the process can of course be integrated appropriately. You may have a preferred approach, but I would argue that neither option is more "correct".
• Remember that location in an ECM system can carry meaning. Just as a document may be attached to a process at a certain stage (e.g. "Awaiting Approval"), a document can also be stored in an appropriately named place. It naturally follows that any library or folder may carry a meaning related to "state" through both it's name and it's location. It's a simple, subtle concept, but surprisingly deep when realised.

Typically, your approach to solution design needs to be inventive - leveraging existing ECM assets becomes paramount (why re-invent the wheel?). When working on complex processes, you need to ask yourself serious questions about the point you will stop trying to bend the system to your process, rather than your process to fit the available technology - or perhaps buy the right tools for the job in the first place.

In many ways, working with restrictions can be useful - rather than perverting the various elements of the system to become a jack of all traders (and master of none), you are encouraged to offload specialist tasks to applications more suited to them.

The important thing to realise is your views will change as experience is gained, and you design, develop and implement real world processes.

I've read them all, and would without hesitation recommend them on to anybody else with even a passing interest in the history of the internet, or software development in general...

Where Wizards Stay Up Late by Katie Hafner
In the 1960s, when computers were regarded as giant calculators, J.C.R. Licklider at MIT saw them as the ultimate communication device. With Defence Department funds, he and a band of computer whizzes began work on a nationwide network of computers. This is an account of their daring adventure.

What Just Happened by James Gleick
For the past decade change seemed to happen over night, every night. Fueled by the exponential rise of technology, the digital revolution was difficult for many to make sense of, but James Gleick watched and analyzed, criticized and commended, participated in and prophesized about the instantaneous transformations of the world as we knew it.

Hackers by Steven Levy

This 25th anniversary edition of Steven Levy's classic book traces the exploits of the computer revolution's original hackers -- those brilliant and eccentric nerds from the late 1950s through the early '80s who took risks, bent the rules, and pushed the world in a radical new direction. With updated material from noteworthy hackers such as Bill Gates, Mark Zuckerberg, Richard Stallman, and Steve Wozniak, Hackers is a fascinating story that begins in early computer research labs and leads to the first home computers.

The Mythical Man Month by Frederick P. Brooks Jr.

Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.

Weaving the Web by Tim Berners Lee

Given the way the Web has become the dominant communications technology of our time, one could argue that Berners-Lee is the guy who invented the future. Yet up to now he has remained reticent about how he did it. Weaving the Web is therefore the definitive account of how the World Wide Web came to be. No one else could have written this book--the history of the Web straight from the source.

Accidental Empires by Robert X. Cringely

Robert X. Cringely manages to capture the contradictions and everyday insanity of computer industry empire building, while at the same time chipping away sardonically at the PR campaigns that have built up some very common business people into the household gods of geekdom. Despite some chuckles at the expense of all things nerdy, white and male in the computer industry, Cringely somehow manages to balance the humour with a genuine appreciation of both the technical and strategic accomplishments of these industry luminaries. Whether you're a hard-boiled Silicon Valley marketing exec fishing for an IPO or just a plain old reader with an interest in business history and anecdotal storytelling, there's something to enjoy here.

iWoz by Steve Wozniak and Gina Smith

Wozniak's life - before and after Apple - is a "home-brew" mix of brilliant discovery and adventure, as an engineer, a concert promoter, a fifth-grade teacher, a philanthropist, and an irrepressible prankster. From the invention of the first personal computer to the rise of Apple as an industry giant, iWoz presents a no-holds-barred, rollicking, firsthand account of the humanist inventor who ignited the computer revolution.

The Cathedral and the Bazaar by Eric S. Raymond

The Cathedral and the Bazaar takes its title from an essay of the same name which Raymond read at the 1997 Linux Congress and that was previously available only online. The essay documents Raymond's acquisition, re-creation and numerous revisions of an email utility known as fetchmail. Raymond engagingly narrates the fetchmail development process while at the same time elaborating upon the on- going bazaar development method he employs with the assistance of numerous volunteer programmers who participate in the writing and debugging of the code. The essay smartly spares the reader from the technical morass that could easily detract from the text's goal of demonstrating the efficacy of the Open Source, or bazaar, method in creating robust, usable software.

Burn Rate by Michael Wolff

Michael Wolff was a journalist and writer; in 1998 he is a journalist and writer again. But in the first half of the '90s he was an Internet entrepreneur, Chairman and CEO of Wolff New Media. This is Wolff's story. BURN RATE is hugely informative about the world of the net and the web, search engines, closed systems, online pornography; it is also incredibly funny. As readable as a novel, BURN RATE is an all too human story of one man, at first idealistic and naive, then corrupted and increasingly cynical, and eventually burned out and tired, and of a world that bears as much resemblance to the school playground (not least in the age of it's major players) as it does to the world of conventional businesses. If there is one book which tells us about what is going on in the complex and confusing struggle for the future of the Internet it is this one.

A Brief History of the Future by John Naughton

The Internet is the most remarkable thing human beings have built since the Pyramids. John Naughton's book intersperses wonderful personal stories with an authoritative account of where the Net actually came from, who invented it and why, and where it might be taking us. Most of us have no idea of how the Internet works or who created it. Even fewer have any idea of what it means for society and the future. In a cynical age, John Naughton has not lost his capacity for wonder. He examines the nature of his own enthusiasm for technology and traces its roots in his lonely childhood and in his relationship with his father. A Brief History of the Future is an intensely personal celebration of vision and altruism, ingenuity and determination and above all, of the power of ideas, passionately felt, to change the world.

Deeper by John Seabrook

Although the author of this journey in cyberspace hardly ever goes anywhere - he just sits in front of his computer - his story is full of travel and incident. Readers meet Bill Gates and other major people in the industry via e-mail, join a virtual community to find out what daily life is like, adapt to the World Wide Web, and build a Web site. The voice of the book is at times comic, at others rueful, wanting to believe in the good things about the Net but sceptical of the hype, trying to account for the engrossing nature of this new frontier.

Microserfs by Douglas Coupland

Microserfs is not about Microsoft--it's about programmers who are searching for lives. A hilarious but frighteningly real look at geek life in the nineties, Coupland's book manifests a peculiar sense of how technology affects the human race and how it will continue to affect all of us. Microserfs is the hilarious journal of Dan, an ex-Microsoft programmer who, with his coder comrades, is on a quest to find purpose in life. This isn't just fodder for techies. The thoughts and fears of the not-so-stereotypical characters are easy for any of us to relate to, and their witty conversations and quirky view of the world make this a surprisingly thought-provoking book.

JPod by Douglas Coupland

Ethan and his five co-workers are marooned in JPod, a no-escape architectural limbo on the fringes of a massive game-design company. There they wage battle against the demands of boneheaded marketing staff who torture them with idiotic changes to already idiotic games. Meanwhile, Ethan's personal life is being invaded by marijuana grow-ops, people-smuggling, ballroom dancing, global piracy and the rise of China. Everybody in both worlds seems to inhabit a moral grey zone, and nobody is exempt, not even his seemingly strait-laced parents or Coupland himself.

We all know that managers like to talk about models, methodologies, and methods. They like to sound clever, throwing acronyms around, and spouting catch phrases and buzz words as often as possible. No realm of information technology seems to display this mania quite so aptly as software development methodologies. Given the amount of hoodoo, fear, uncertainty and outright rubbish written about the various ideas, I thought it might be timely to write a post outlining what each one really means – both for my own reference, and my own sanity – if this is of any use to you, that’s a bonus.

What is a development methodology?

Broadly speaking, it’s the description of an approach to building software – the reason to have the description in the first place would be to get a team of developers to work in a similar manner to each other, and so that team leaders have a clue what’s going on.

Right. So what are the various well known methodologies?

Waterfall

The waterfall model is a sequential development process, in which development is seen as flowing steadily downwards – like a waterfall – through the phases of Conception, Initiation, Analysis, Design/Validation, Construction, Testing and maintenance. The process is followed with rigour, and loved by pedantic team leaders who like to tick boxes, and make everybody’s life hell. It’s incredibly expensive to do, and customers both love it and hate it – they love it because it can be run on a fixed price, but they hate it because a calculator application ends up costing as much as the space shuttle.

Iterative and Incremental

Iterative and Incremental development is a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interaction in between. So, essentially, this is Waterfall where we admit that waterfall is idiotic, and we agree to go round and round in circles, until we’ve spent just as much time, effort and money as Waterfall. I guess brakes can be applied in the form of somebody in the middle of the mayhem who continually asks “is this good enough – will it do?”. Iterative development is often tied to the “Rational, Unified Process” – another meaningless description heard often, but understood by nobody.

Rapid Application Development

Rapid application development is a structured technique where early designs are turned immediately into prototypes, which are then iteratively evaluated, refined, redeveloped, ad nauseum until the finished product is produced. “RAD” was invented to combat the main problem of Waterfall based development methodologies – by the time anything got built, the requirements had changed – and by the time the redeveloped solution re-appeared, the requirements had changed again. Rapid application development became very fashionable in the mid 1990s with the advent of visual design tools such as Visual Basic and Delphi that allowed fast interface development. It also caused some of the worst spaghetti code in the known universe due to nobody paying their “code tax” and inviting developers to go back and clean up after requirements have changed.

Agile Development

If you are a fellow developer, you were expecting this one to be in the list – probably because it’s the fashion of the moment, and all managers in the known universe think Agile sounds cool when talking to clients. I expect they stand in a “ready for action” fake karate pose when they say it. In reality, the “Agile” label covers a swathe of similar methodologies – the Wikipedia description reads as follows;

Agile methodologies generally promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Phew! So it sounds like it will save the known universe – and it’s growing popularity has resulted in more being written about it than any other method – meaning basically that Managers can now have big fat books about it on their shelves, and communicate in pure acronym when discussing project plans. In reality, all Agile really means is that you will communicate, you will try to make things work, you will be trusted (!?), and you will not blow a gasket when requirements change. Of course the customer also has to realise that change equals longer.

Extreme Programming

Quite unlike extreme ironing, extreme programming does not involve carting a laptop halfway up Aconcagua to write some C++. It is however similar in taking ideas from several flavours of Agile development, and constructing a set of “ideals”, or “expected behaviours” around them. I can only imagine the anal, ivory towered developers that dreamed up Extreme Programming as a methodology – whereas most of us might well follow a lot of the ideas anyway, there is a strict swathe of rules, behaviours, and guidelines that you can follow if you really want to be an extreme programmer. I’m guessing the people who like working this way also have 20 sided dice in their desk drawer. I’m being cruel, aren’t I. One of the ideas within Extreme Programming that I really like is working together so that one of you programs while the other thinks. Can you imagine – sit there, with your feet up, sipping coffee and spouting lofty ideas at somebody all day?

In summary…

I’m guessing this blog post is going to generate it’s fair share of laughter, snorts of derision, outright anger, incensed murmurs of “he didn’t get it”, and various other rumblings of discontent.

It’s worth remembering that 99% of development teams use elements of all the methodologies that have been written about in the text books. It’s also worth noting that all attempts to build software in a faster, more efficient, more responsive manner are eventually defeated by millions of words being written about them in textbooks, and managers applying so much structure, measurement and review that you may as well call them all Waterfall and have done with it.

In order to combat the endless torrent of tasks, requirements and commitments surrounding me throughout the past couple of years, I have been experimenting with the "Getting Things Done" methodology. I first heard about it while reading Merlin Mann's 43 Folders website, and have since bought the book by David Allen, and found myself returning to it again and again.

"Getting Things Done" is based on a loose set of ideas - a toolkit to help bring organisation to your chaos. The tools are not specified - only the manner in which you might use them. Each person will prefer different tools, and each person's chaos will be different.

My chaos consists of a demanding full time career as a professional software developer, a sometimes equally demanding "second string" freelance career as a web developer, and the remainder as the husband of an infinitely better half, and the father of three young children.

Central to the "Getting Things Done" or GTD methodology are three basic ideas;

• If it's on your mind, your mind isn't clear. Anything you consider unfinished in any way must be captured in a trusted system outside your mind, that you know you'll come back to regularly and sort through.
• You must clarify exactly what your commitment is and decide what you have to do, if anything, to make progress toward fulfilling it.
• Once you've decided on all the actions you need to take, you must keep reminders of them organized in a system you review regularly.

So the basic idea is to forget about everything you don't need to be thinking about - to store it away somewhere - and to regularly pull tasks from that store as they need to be done.

The idea of freeing your mind from anything that doesn't matter right now has been the most difficult for me to embrace. While listening to one of Leo Laporte's podcasts recently, a rather novel nuclear tactic of sorts was put forward - if your desk has mountains of unknown "stuff" on it, get a great big box, and sweep everything into it - then mark the box "some day". You will of course return to the box, but only to fish out things that need to be done as they crop up.

Over the past year I have experimented with a number of tools for my "trusted store". Remember the Milk, Toodledo, GMail tasks, and a variety of quite brilliant iPhone applications. For several months I used (and loved) 37Signals Backpack - it was simple, flexible, and good enough.

After tinkering, playing, using, breaking, and misusing all manner of task list software, websites and services, I probably have more perspective than most about what I need in a solution, which it turns out is very different than what I would like.

The concept of an In-Box is perhaps the lasting influence Remember the Milk had on me - with the idea that you could throw any tasks immediately into an inbox to get them out of your way. It falls into the same paradigm as Inbox Zero (where you try to keep your email inbox empty as far as possible).

I was going to write about my specific solution, but I'm not so sure it's really of much importance to you as a reader. The great thing about any productivity methodology is that you are free to modify and adapt it to the tools you have. It doesn't really matter if you have a desktop computer, a laptop, a paper notebook, an iPhone or a Blackberry - it's forming a regular habit of managing your store of notes that really matters.

What books does a real software developer have on their bookshelf? I thought it might be interesting to cast a glance over my shoulder at the bookshelves, and list some of the more noteable books that sit covered in varying amounts of dust.

It's worth pointing out that no books have been bought in a very long time - therefore those that do exist have earned their place through various culls that have happened over the years. The books that remain have not been given away, sold, or lost.

The Technical Books

• The C++ Programming Language, by Bjarn Stroustup (Addison Wesley)
• Peter Norton's Complete Guide to Linux (SAMS)
• Running Linux (O'Reilly)
• Joy of C
• Programming PHP (O'Reilly)
• CGI Programming with Perl (O'Reilly)
• Programming Perl (O'Reilly)
• Mastering Joomla 1.5 (PACKT)
• SQL in a Nutshell (O'Reilly)
• Linux Complete (Sybex)

Of the above books, by far the most thumbed, and perhaps most useful was "SQL in a Nutshell", which differs from most of the other technical books I have ever used - it gives all common TSQL database instructions, with worked variations for each of the leading systems (Microsoft SQL Server, Oracle, and MySQL being the most obvious).

Apart from the huge (and brilliant) C++ book by Stroustrup, all the other books suffer from the same problem - at least for me - they serve as a leg-up, but you quickly outrun the knowledge held in the book, and resort to hacking (in it's true sense), or googling.

I don't just have technical books though...

Non Technical Books

• The Cathedral and the Bazaar
• Where Wizards Stay Up Late
• A Brief History of the Future
• The Order of Things
• Darwin Among the Machines
• Microserfs
• The Music of the Primes
• The Dilbert Principle
• Burn Rate
• Accidental Empires
• Deeper
• Hackers

All of the above books are wonderful - without exception. A particular favourite would have to be "Accidental Empires" by Robert X Cringely - a pseudonym given to a number of writers over the years within Silicon Valley (not a lot of people know that, either), although there really is a "real" person - and he's the author of the book. It tells a lot about the inside stories from HP, Apple and Microsoft during the early years of the personal computer revolution.

Hackers is perhaps the most famous book on the list - and again recounts the early years of personal computer history - from the railroad club at MIT, through the various PDP mainframes, Richard Stallman, Gnu Linux, the development of the internet, Wozniak and Jobs building the first Apple computers, and the emergency of Microsoft.

There are of course more books behind me than appear on the lists above - but you don't really want to hear about "The Time of Our Time" by Normal Mailer... or do you?.

I guess the point I am making is that professional developers - good ones - are not entirely focussed on software development. We are interested in where we came from, where we are going, and the human story - the journey - the wider view.

Long time friends, colleagues and acquaintances will know that I have long been a fan of the various productivity solutions created by the team at 37 Signals.

During my day to day work on freelance projects a couple of years ago, I absolutely relied on Basecamp to keep everything and everybody organised. Basecamp is an excellent online project management portal, allowing teams to share integrated email messaging, live chat, file sharing, task lists, milestones, time recording, and more. It's simple, it works well, and doesn't try to force you into doing something a particular way.

While working in London, I found myself balancing too many plates - with professional, home, and freelance commitments all competing for my time. I found myself relying on Backpack as a personal online notepad, diary, reminder, file store, and to-do list.

Of course 37 Signals also make other successful products - such as Highrise, and Campfire, but it's perhaps fair to say that Basecamp and Backpack are their primary offerings. My use of their products brought about the realisation that software doesn't have to be a tightly fitted solution to a problem - sometimes it's far better to have a flexible toolkit that can be adapted.

The development team at 37 Signals obviously realised they were doing something right, and distilled much of their rational, thought processes and ideology into a book - "Getting Real" - and what a book it is.

Coming from the world of professional software development, it's refreshing to read the views and opinions of a successful modern web development team. Where my world is encumbered by requirements, estimates, timescales, version control, testing, delivery and deployment, their world is comparatively free.

Without giving too much away (go buy the book!), the chapters of their book give a pretty good idea of the direction it takes you in - I've given a very brief abstract alongside each of the first 10 titles - there is much more in the actual book;

• Go With the Flow
  Do not do big design up-front - embrace change. Avoid sentimentality.
• Beware the Bloat Monster
  Keep everything as simple as you can. Avoid needless complexity.
• Keep up with the Joneses
  Read industry news feeds, and watch what competitors are doing. Have no shame.
• Ride Out the Storm
  Do not react immediately to issues. Let things calm down. Measure twice, cut once.
• All Bugs are Not Created Equal
  All software has bugs - you don't have to fix every bug immediately.
• Better, Not Beta
  Never do a public beta. Make sure what you deliver works, even if it has limited functionality.
• Keep the Posts Coming
  Keep the PR momentum going post launch - inform on fixes, updates, upgrades, and future ideas.
• One Month Tune-Up
  Quick updates show momentum - prepare missing features for a quick upgrade.
• Publicise Your Screwups
  Let people know what you fixed, and what you know is wrong.
• In Fine Forum
  It's all about growing a user community, and forums are a great way to do that.

If you are anything like me, and you have an innate interest in the methodology behind software and web development, you'll find "Getting Real" really interesting. You will know a lot of the advice already - but bringing it together in one volume is useful both as a reminder of important themes, and as a resource you can dip into now and again.

To buy a copy, head on over to http://gettingreal.37signals.com.

This is not a sponsored post, and I have no professional involvement with 37 Signals.

I discovered "When SysAdmins Ruled the Earth" while looking at the ePub digital document format a couple of years ago. I was commuting into and out of London each day, and found myself dipping my toe into the ebook waters. It remains one of the best short stories I have ever read.

The story is one of a collection by Cory Doctorow called "Overclocked", and imagines a scenario where a global apocalypse has occurred, wiping out most of the people. Chief among the survivors are the system administrators of large computer networks - holed up in the atmospherically controlled server rooms of large corporations around the world.

The story imagines the global communication - the sharing of news from country to country via IRC, email, and instant messaging, and the chaotic plans put in place by those few people who considered they might be the last left alive in the world.

Cory Doctorow has the following to say on his own website;

I started writing When Sysadmins Ruled the Earth on July 6th, 2005, while teaching Clarion. The next day, the London Underground and busses were bombed, including the bus I rode to work every morning (I was in Michigan, teaching Clarion, thankfully). These kinds of coincidences can be spooky when you're a writer. I ended up putting the story away for some months.

When I returned to it, I was fired anew with the story of Felix and Van and their vainglorious struggle to keep the servers online as the world went offline. Once created, apocalyptic anxiety can't be destroyed -- the 1980s fear of nuclear annihilation I grew up with surfaces anew with each theoretical disaster: Y2K, climate change, und so weiter. There's something primal about a story of the Earth's impending doom.

I was a sysadmin at an earlier stage in my career and I have infinite respect for the field: sysadmins are the secret masters of the universe, and they keep your life running.

It's a wonderful, wonderful story if you have any past experience of the internet, network infrastructure, IRC, usenet, or the other early protocols that still underpin the infrastructure we rely on. You can download the ebook for free from Feedbooks at the following address;

• http://feedbooks.com/book/335

Sometimes friends not connected with my career in software development ask "what I do", or "what it's like". I have often struggled in explaining the reasons I may sometimes appear so drained - what it is I do while sitting staring at the screen that might be so hard.

Some time ago while cycling home from work an analogy appeared in my head by which I might better describe the complexity of my work to laypeople. Perhaps it was the turning of the pedals - the repetitive nature of cycling. Perhaps a mundane activity releases your mind from it’s dominant activity, and causes a perspective change. I never studied psychology at college, so can never surmise in such fashionable terms as some of my friends - I cannot quote Freud, Chomsky, or Goeth.

So - the analogy.

Imagine a tree. It is an old oak tree that has stood proudly in it’s corn field atop a hill for generations. Our ancestors walked and sat beneath it’s bows while enjoying countless springs, summers and falls. The tree has many large bows, which each have many thousands of branches. Each branch has many hundreds of twigs, and each twig has many acorns and leaves.

Laying on your back underneath the tree, you peer up into the maze of branches, and quietly take it in. You begin by focussing on the end of one branch. You can describe at length the twigs, and the leaves that hang from that branch. Without too much trouble you can describe the relationships between the leaves - this one is bigger than it’s siblings, that one has an acorn, that one over there is a darker shade than the others. At length you begin to abstract the tree. Each branch has many twigs. Each twig has many leaves. Each leaf receives sunlight, which is passed back to the twigs, and on to the branches, the bows, the trunk, and the roots.

If you open your view, taking in the wider scene, you can see all the leaves on the end of your branch at once. You can describe them as a group. You can "see" the end of the branch, and understand it. After a few more minutes committing it to memory, you may be able to describe it’s twigs and leaves to somebody who has not seen it.

Here’s the trick. Take in the entire tree. See every leaf. Every twig. Every branch. Describe all of their relationships, all of their nuances, the individuality of every piece. Understand the big picture - not as an abstract "tree" - know each leaf. Know how each leaf works, how it came to be there, what came before it, what will come after it. Know how changes to one leaf will effect others - how changes to a root will affect every leaf.

In a roundabout way, I have described the mental gymnastics required to work on a sizeable software development project, and the reasons for my gradual downward slide from time to time. You may often work on small, isolated elements of a project (describing a leaf), but at others you may need to "imagine the tree", and these are the times that developers fear.

Hopefully you were able to make the jump with me between the tree and software development, and with a little luck the analogy will stay with you.

Following an attack of wonderlust at the end of 2011, I have begun two seperate blogs. I have no idea if this will work, if I'll stick at it, or anything else at the moment. I just know I'm too busy to carry on hosting my own blog.

The results of the continued tinkering are;

• Turning the Pedals
  The life and times of a software developer 
• It Will Never Fly
  Randomly scribbled notes about technical geekery

This is kind of coming full-circle on the blogging journey. Hopefully it's the last lap.