Perfect Programs vs. Imperfect People?

Thoughts around people, web and production.


I’ve always liked to explore and develop ideas to help customers and, at the same time, ourselves within a company.

Recently, an ex-colleague and good friend of mine named, for anonymity's sake, “Taylor” arrived after a fourteen hour flight at O.R. Tambo International Airport. We met up and discussed some new ideas and thoughts talked about at @DrupalCon2016, which was in Denver, CO last year. Albeit all about ‘new news’, both Taylor and I already worked on some tried and tested approaches, which I'd like to share.


All of the staff in our office have had to work with complex or abstract in-house system’s procedures daily. We need specificity for correctness, yet also a way to get reach into an audience who might be less-technical with confidence in their new knowledge.

Keeping an eye on possible/plausible misinformation being conveyed was key - people are smart, never “dumb it down”.

We found that ‘The Traffic Approach’ example worked very well in our office at that time  — the fact that almost everyone had a car and drove to work by themselves everyday helped. The ‘The Traffic Approach’ example married abstract concepts easily with things which were more tangible, like cars  and their behavior in traffic flow and safely navigating through on a highway or city street.

Part 1

In 2010, I received an opportunity to work with a fresh startup in Johannesburg — I had great ambition and plans to build and integrate systems abundant — it was a grand endeavor! I took the leap and committed to the development, as well as went all-in financially.

That project never reached the market. It’s outcome took me to a new level of understanding on how to approach planning for software development. Why did our effort fail, did I fail?

The cacophony of potential business exploits, new features to be sold and exciting things that the execs were busy with ensured excellent marketing. However, when I eventually heard of it, the expectation was so bewildering, that entire marketed services never even reached development planning. The entire project crashed.


Technical layouts, process- and workflow are essential - just like everything else.

Part 2

Someone who knows their field can, and eagerly will, plan an excellent software component, build it, and also then proceed to deploy it - man-alone. This developer’s programming integration will make headway with speed improvements, backwards compatibility — the works - to any technical standard imaginable. It is an impressive piece of the complicated puzzle, which encompasses the entire scope of ‘the system’; this is no small feat. Because the project is done in record timing too, obviously, are congratulations are in order?

I’ve mulled around in my head with the word ‘planning’, trying to think how to explain its contextual meaning to people, team members and, most importantly, developers.

This method of teaching, cruel as it was at the time, showed me, as a developer, how an incomplete understanding of a business plan or the direction the company is taking cannot thrive. Our “super-developer’s” lack of intrinsic knowledge caused this “fantastic feature” to lose the business of an entire quarters’ returns for one client - not romantic in any way. Multiple serious issues were encountered later on, many of them unforeseeable from the outset. Had this leaky situation not been picked up, other clients would have soon followed, and it would’ve all came crashing down earlier than it did.

By not just being someone who knows their field well, but by also being the driver , you can spot congestion patterns, road hazards and keep all four wheels on the ground at all times.

Tying all of these concepts and ideologies of learning together contributes to making computers more-and-more human friendly. A noble cause indeed.