Saturday, 23 March 2019

Don't be a hero :: How to build successful software in a skills-deprived world

I used to be a nice guy.

In the early days of my career I did a lot of training, both business and technically-focused. One of the most regular bits of feedback I got from course attendees was that I showed boundless patience with people who really struggle with the material.

I appreciated those comments and it is something I strive for every day.

But lately, I haven't really succeeded.

Lately, and by lately I mean the last couple of years:
  • My temper has gotten shorter and shorter.
  • My overall frustration levels have been increasing steadily (like my weight)
  • I have been sleeping less and less
  • I have gone on fewer holidays
And perhaps most importantly, while I've experienced a lot of "success" in my professional career, my overall job satisfaction has dropped significantly.

These days, I VERY frequently contemplate selling everything I own and going to stay in the mountains for a number of months.

To quote Bilbo Baggins: "I want to see mountains again. Mountains Gandalf"

So what happened?

Well, you can probably describe it as burnout in some sense, but the short answer is: I became a hero, and I got addicted to it. I got addicted to be the linchpin guy that the project depended on. 

But saying I got addicted to being the hero is a radical oversimplification. 

In reality, I would give almost anything to have a normal life. To go cycling on Saturday mornings. To improve my landscape photography. To fix the irrigation in my vegetable garden. 

In reality, I don't want to be the hero on projects. And given my specific role in my company I actually should NOT be getting involved in the nitty-gritty of projects at all.

In reality, I just often found myself in a position that I literally HAVE TO step in and become the hero, else projects fail. And I simply cannot handle failure.

Of course, it isn't all bad, and I have had many successes over the years. This article explores my journey, looking at:
  • Some of the things that cause projects to need a hero
  • What you can do to prevent it
  • Why you should focus all your energy on not becoming the hero

A teenie bit of context might be useful here: 

I play a leading role in the bespoke software development area of a large South African IT company. Which means we are often involved in projects where there isn't a pre-baked solution that can be purchased off the shelf.

Most of our projects start off on day 1 being under pressure, because:
  • It took the customer ages to get through the business case and get budget allocated
  • The procurement cycle took ages
  • And then more time was spent getting the project team assembled and ready to rock and roll
  • And of course, requirements are never defined or well thought through at the start.

But despite all of that, some big-shot exec has already made a delivery date commitment to the board of directors in order to get the money for the project.

So at the best of times, most projects have to start by wriggling themselves out of a hole dug by business people.

Understanding the different role-players in projects

Of course it differs from project to project, but I tend to see the following breakdown on most of the projects we get involved with (note: most projects tend to be a joint effort with the customer and sometimes even including other vendors)

  • Heros - People who REALLY know their stuff. Passionate about delivering the project - 15%
  • Divas - Passionate technologists who think they are too good to be on the project -  5%
  • Talkers - People who add little value except for the fact that they're old or seem to talk a lot in meetings - 10%
  • Workers - Worker bees who do one thing well and put in a solid 6-8 hours of work - 40%
  • Strugglers - People who want to work. And think they do, but they never seem to deliver anything - 20%
  • Dead wood. People who are literally just on the project to fill a seat - 10%
So based on these (admittedly very anecdotal) numbers, it turns out that most projects are actually delivered by about 50% of the team. 

But remember, when you originally do proposals and quotes, you can't double your estimations simply because you expect a bunch of team members to not really pull their weight. If you're in my business - the business of making a profit out of software development - then your Go To strategy must be to change the layout of project teams to something like the chart on the left.

It's probably obvious that we've killed off the Divas, the Talkers, the Strugglers and the Dead Wood, but what is also interesting is that:

We didn't remove Heros entirely - Every project, no matter how well planned will need some instance of heroic programming at some point. Let's not live in a dream world.

Building your pack

The best analogy that I can come up with for a project team is a pack of sled dogs. I'm not sure if it's just me, but I loved watching the Discovery series on the Iditarod, the epic dog-sled race in Alaska. In typical Discovery channel fashion they constantly tried to manufacture intrigue and surprising plot twists. But what I loved about the show was not so much the intrigue, but rather learning more about how these racers assembled their packs of dogs prior to the race and how they cared for them during the race.

A key measure of success for a pack of dogs is that they work together. If one of dogs has an issue and needs to slow down, there are two options: 
  • The whole pack slows down until the slow dog recovers
  • You remove the slow dog from the pack
But as lead developers, people with built-in Type-A personalities, that isn't often our instinct. My natural response, if I see members of my team struggling, is to run harder myself - Thinking that by running harder, I will balance out the slow team member(s).

Although this approach can sometimes counteract a performance problem with one team member, it has a significant unintended consequence - It pulls the WHOLE TEAM off balance. And once the team loses balance it is very difficult to get your delivery velocity back.

Depending on the project, there are two possible outcomes:
  • Small projects become a one-man show with other project team members feeling useless and just sitting on the side-lines
  • Large projects fail outright, because it is impossible for one person to carry a 10 or 20 person project.
So our goal is to go from an inefficient project make-up, like the one on the left, to an efficient make-up, like the one on the right.

And there are many tricks of the trade to achieve that. This article will focus on one specific side of the problem an how to fix it: How can we CONVERT THE STRUGGLERS INTO WORKERS?

We can probably debate for hours about how we should fix the education system in South Africa, or how we should improve recruitment to ensure strugglers don't get onto our projects, or why we should move to San Francisco to give ourselves the opportunity to work with the best teams of our industry.

Those are interesting discussions, but it is not the discussion I'm having today.

My question is: How do we convert the STRUGGLERS who are already on our projects into WORKERS.

And there really is only one answer: Teach them.

Accepting the Kruger Dunning Effect

So let's talk about South Africa for a bit. In South Africa we have people from many different languages, many different cultures, males, females, different religions, different races, different economic statuses.

And yet, there's one thing that brings us together as a Nation: We all believe we are ABOVE AVERAGE DRIVERS.

And that's a key observation I've made with strugglers on software projects. They don't consider themselves strugglers. They actually think they are experienced software developers.

Most CVs here in South Africa include a skills-matrix of some kind where the candidate lists their skills along with a rating from 1 to 5. In every single CV that I see from a young software developer, they drastically overestimate their own abilities. I've observed this over many years.

When I started to investigate this problem, I came across a phenomenon called the Kruger Dunning effect. But to really appreciate the Dunning Kruger effect, you need to hear the story that inspired it.

In 1995, a 45 year old guy walked into a Pittsburg bank and robbed it at gunpoint. Later that same day he robbed another bank. What was most interesting about this bank robbery is that the perpetrator didn't wear any mask or use any method to conceal his identity.

As could be expected, he was quickly identified and arrested. When the cops entered his house and placed him under arrest, the first words out of his mouth was: "But I wore the juice"
You see, McArthur isn't very smart. He had heard about the fact that you could use lemon juice to write in a type of "invisible ink" which is undetectable to the naked eye. He then reasoned that if he rubs lemon juice over his face, people in the bank, and the security cameras would be unable to see his face. Master plan!

What is interesting about this story is not just the complete ignorance of the perpetrator (which, let's be honest, is pretty interesting), but rather how utterly convinced he was that the lemon juice plan would work.

Psychology researchers Justin Kruger and David Dunning were inspired by this story to explore the idea that people who have low levels of competence in a specific field seems to greatly overestimate their own abilities.

The Kruger-Dunning Effect describes this phenomenon where someone with a low level of competence in a subject, let's say Programming, also lacks the knowledge to accurately assess their own competence. As a result, they greatly overestimate their own capability.

You can summarise this as: A little knowledge is a dangerous thing.

The graph below depicts this phenomenon by showing how someone, once they start to get experience in a subject, slowly begins to realise how little they really know.

This is what happens to a Struggling junior developer if left to his/her own devices. They literally don't know that they aren't adding any value to the project. They actually think they are experts in their field.

So let me give a practical example of this effect from my day to day life: On a recent project, we had a junior developer who was very clearly VERY Afrikaans. For some reason, however, he was under the impression that his English grammar was impeccable and that it was his duty to correct people at every opportunity. It was so bad that I once had to privately address the issue with him, when he "corrected" the client's product owner in a meeting.

Here's one of the classics he added into JIRA as a defect:

Yes, perhaps a whimsical example, but it applies to most aspects of young developers who fall into the "Struggler" category. It's not just that they lack the required competence, they also lack the knowledge to realise their lack of competence.

Your goal as a senior developer should not be to criticise their lack of competence, but rather guide them along the path, helping them realise what they don't know and then encourage them to learn it. We'll touch on some approaches just now.

The Curse of Knowledge

But first I want to address another cognitive bias that makes it difficult for experienced developers to teach younger ones. It's called, the "Expert Paradox", or sometimes the "Curse of Knowledge"

As a senior technologist, many things may seem easy or self-evident to you. This is function of your competence as well as years of experience. This knowledge and experience makes it difficult for you to actually empathise with the position of the inexperienced person. Your knowledge actually becomes an impediment to teaching.

I generally like to use a puzzle analogy: Think of your whole IT carreer as building a puzzle. It's the puzzle of knowledge. Each piece of the puzzle is a new bit of isolated knowledge - It only becomes valuable when you can look at it in context. As an experienced practitioner, your puzzle is already well established, so when you find a new piece, you have a much better overall picture and you can more easily understand where this fits in. Even if you find a difficult piece of blue sky or ocean water, you can more easily find where it belongs because you can compare it with the other patterns you've already constructed.

To a young and inexperienced person, they have barely begun assembling their puzzle. Each piece is a brand new experience and is often very difficult to see in context.

Practical mentoring

So how, in a practical sense, do you mentor inexperienced developers? I've seen ways that work and ways that definitely do not work.

Here's one way that absolutely does not work: You pick a small, apparently easy bit of work and give it to the new guy to implement. And then you wait. This fails for a number of reasons:

  • You wait too long
  • By the time you receive something back the learning opportunity is lost
  • You probably implemented it yourself, so the new person loses conffidence

I learnt a better way from one of my colleagues, William Gadney. I'm not sure if it is his own method or whether he read about it somewhere, but the process is both deceptively simple and yet deceptively difficult to execute.

But it is almost guaranteed to work. I refer to it as the 3-Stage Journeyman approach and it looks like this:

The idea is simple:

  • First, you find a piece of functionality that you will need to implement at various points in your project. A good example would be if you had to build a number of different REST services.
  • Stage 1: When building the first one, the inexperienced developer sits next to you. While coding you "Think out loud", explaining what you're doing as you proceed.
  • If it seems that the new person understands, you move on to stage 2, else you repeat stage 1 
  • Stage 2: At this point you switch seats. The inexperienced developer does the coding, but the mentor is right there, guiding, correcting and helping the whole time.
  • If the learner gets the hang of things, you move onto stage 3, else you can repeat stage 2, or even go back to stage 1.
  • Stage 3: At this point, the inexperienced developer goes away and writes the code by themselves. Followed by a detailed code review.
  • If all went well, the rookie has become a journeyman in this particular skill, and you can pick the next one.

Help the team see the bigger picture 

The next bit of advice I use to help inexperienced developers escape the Kruger-Dunning trap is by constantly assisting them with seeing the bigger picture. Effectively, I overshare information about the project so that they are always 100% aware that there is more to the project than the bit they are involved with.

This has two consequences:

  • They are frequently reminded that there is stuff they don't know, but
  • They have full access to learn that stuff - It isn't hidden from them

My strategy includes the following tactics:

Tip 1: Err on the side of a mono-repo
A multi-repo scenario might have many benefits, but it has one critical flaw: It entrenches a fragmented view of the solution. Even the most astute learner will struggle to fully understand how a solution fits together if he doesn't even know that he is looking at a partial picture.

A mono repo helps greatly with this. In fact, I prefer using a single repo that includes Documentation, BDD Testing code and Load testing projects all into one Git repo. If you do prefer a multi-repo scenario, then ensure that the repos are clearly documented and referenced in a single Master project repo.

Tip 2: Get the documentation into the repo
Add the project documentation into the single repo (or the project master repo if you follow a multi-repo approach). I use Sphinx, which makes this a breeze. You document right there in your IDE making it quick and intuitive. And you can generate and publish the docs as part of your CI/CD pipeline which means that the docs and the code are always in sync.

If your company uses Confluence, you don't have that option, so you just need to work hard to make the documentation accessible.

Irrespective of which approach you use, you will always need to work hard to make sure developers access the documentation. Trust me, it is a never-ending battle. 

Tip 3: Make the architecture visible
Architects tend to create their diagrams in isolated CASE tools that nobody else has access to. This is one of my most fundamental critiques against the discipline of Architecture, and is a problem that I have been fighting against my entire life. 

My mantra is simple: "An invisible architecture is just as bad as no architecture." 

All you need to do is to add the architecture diagrams into the project documentation. I use the 4+1 Architecture framework on almost all projects, and it provides a great skeleton for the project documentation as well. 

By following this approach you make the architecture accessible to the masses.

Tip 4: Create an Architecture Overview Diagram
Sometimes people get lost in the details of UML and they forget that architecture is about communication. The most successful approach I've followed is to create a bastardized UML diagram called the AOD - An Architecture Overview Diagram. It's like a component diagram, but it also includes Actors.

The result is a diagram that can depict the main Solution Building Blocks (as defined by TOGAF) as well as the context of the solution in a single diagram.

The goal is to create a single diagram, at a high-enough-level that it can depict your whole project on an A4 page, but still shows the salient aspects of the entire solution. Creating a proper AOD is an artform - it forces you to think hard about which details to include and which to exclude. It's almost like the battle Picasso went through while deciding which details to include in Guernica.

But if you get it right, the result is amazing and the resulting diagram serves as a reference point for everyone for years to come.

And, of course, the inexperienced developers can use it to assemble their own puzzles (Almost like looking at the picture on the box of the puzzle).

I have a few other tips as well, that have helped me in the past, I'll briefly list them here:
  • Add a GETTING STARTED section in the docs. Include reference links and introductory notes for each of the technologies used on the project.
  • Do VERY FREQUENT code reviews. Not just at the end of a piece of work, but while they are busy.
  • Establish a formal avenue for knowledge sharing. In our company we call it Lunch Time Learning - Every fortnight we have a team learning session on a Wednesday during lunch.
  • Introduce project team sharing sessions. We do it after retro each sprint, where one team member explains a piece of the project to others in detail - A level of detail that doesn't make sense when the product owner is in the review session

The Benefits

All of these tips and tricks take time and effort, so it is important to be patient. If you rush it, for example, by skipping stage 2 of the 3-stage journeyman process, you are dooming yourself to failure.

Also, it is important to be aware of the benefits that await you. So let me help by summarising the medium term and long term benefits.

In the medium term you will create a situation where you DON'T ALWAYS HAVE TO BE THERE.

  • You can afford to take a week off and go hike in the mountains where there is no cellphone signal. 
  • You don't have to be online with each deployment
  • You don't have to prepare fully for each sprint-review
Also, you create an overall reduction of the Bus Factor of your project - So if you leave (by choice or otherwise), the project will survive without you.

But the long term benefits are the most rewarding, and as someone who's been in this business for many years, I've now experienced it a few times. It's when one of the junior developers you had under your wing becomes a master in their own right.

It might take years, but the day will come when you can hand over an entire project to someone and know ABSOLUTELY that it will be a success and that you don't have to get involved at all.

That's the greatest feeling in our business.

And of course, if you have aspirations to begin that Tech Start-up you've always dreamt of, you are finally ready to get it started as well, because you now have people you can trust to get the job done.


Saturday, 19 January 2019

Weeding your garden :: Ignore the small things at your peril

I'm not sure whether it is caused by the pervasive reality of TED talks, or whether the MBA-culture has finally screwed up the world permanently, but I frequently find myself in boardrooms where people insist that we should stop worrying about the small things - and rather focus our attention on the big, strategic decisions. "Blue sky thinking" is a phrase that has come up a lot.

I disagree.


Here's why:

My leadership role in technology teams (both on projects and in organization structures) shares many similarities with my role at home as a VERY ENTHUSIASTIC amateur vegetable gardener. For starters veggie-gardening is a long game, just like running a sustainable business. It requires careful planning, diligent execution and frequently addressing unexpected curve-balls..

Currently the "big-blue-sky" vision for my garden is to reach the point where all the vegetable needs of our household can be supplied from the garden. This vision will have many benefits to us, but I'm most interested in the benefits of keeping my diet pesticide-free and saving some cash.

Typical Saturday harvest from my garden (Check out the Jalapenos!)

I'm calling this my vision, because it is a state that I have not yet reached, and I may likely never reach it. But having that vision defined guides me when making big plans for my garden. For example, during the spring of last year it guided me to a decision to build 5 new beds as a dedicated planting area for squash and pumpkins. My own little pumpkin patch.

Squash plants take up a lot of space, so we freed up a lot of it. We laid out the beds using concrete StumbleBlocs, filled them with a mixture of compost and potting soil, and even played around with different options for covering them up (to protect them from the chickens)

I laid down some drip-irrigation and popped a bunch of plants in the ground. Bob's your uncle.

Of course, Bob was a tired uncle because getting those beds ready and planted was a huge effort. And it cost a lot of money as well.

A few weeks go by and I proudly share the progress of my pumpkin patch on social media:

Aaah, this bliss of ignorance.

You see, even though I strategically laid mulch inside and between the beds to keep weeds under control, they still started popping up here and there. And squash plants grow very quickly once they get started - So even walking between the beds became difficult by mid summer.

And since these beds are not my primary vegetable garden, I really struggled to pay as much attention to them as was needed. In my primary garden I spend a few minutes every day just walking through the garden; having a look around, pulling a couple of weeds, tying up a cucumber, etc. You know, the run-of-the-mill stuff. This daily chore didn't really get carried over to the Pumpkin patch.

Then the pests arrived. They started eating my Zuchini and then the Patti Pans. But because the beds were quite crowded I barely noticed initially. And since I wasn't there often enough, by the time I realised what was going on it was far too late. Eventually everything succumbed.

In the end I harvested 1 Watermelon and 2 Butternuts from the entire endeavor :(

Luckily I still had my primary garden to keep my hopes up:

So what is the lesson here?

Well, there are a few, but I believe one stands out: Big, bold strategic thinking is essential. It gives you something to aim at, and the vision motivates you to push through the hard work needed to get results you may never have thought possible.

But it isn't enough.

My strategic plan was accurately compiled. It was diligently executed and it was perfectly aligned with my overall vision.

But because it over-extended my capacity, I started to drop the ball on the day to day necessities of running a veggie-garden. The mundane things. Like walking through the garden, pulling weeds, assessing the state of the plants, etc.

In business, and certainly in Software development, there are LOTS of mundane, run of mill tasks that need to get done. And yes, it is very often possible to employ other people to take care of those things. However, I'm of the opinion that the leadership (whether business leadership in a company, or technical leadership on a software project) should NEVER forget to focus on the small things too.

Unfortunately, it isn't just a matter of spending more time focusing on the small things, because if you spend all of your time pulling weeds, you'll never have sufficient time to do anything else - and then you won't be able to execute on the vision. If I followed that approach, my main veggie garden would still have looked like it did at the beginning:

6 years ago

2 years ago

This morning
IMHO the real answer lies in fully understanding all of the details. Assess them and then categorise them into two broad categories:
  • Small things that we should pay careful attention to once, so that we can forget about them. For example watering your garden. If you spend time thinking about and establishing an effective irrigation solution, then you never have to think about it again. The software equivalent is a continuous integration solution.
  • Small things that will always be part of your world. Like weeding. These problems are different, because they never go away, well, almost never.
If you're a leader (Whether by title or by personality), the approach to weeding-type responsibilities is to understand them well enough, to spend enough time on them so that you can standardise, document and communicate how to handle them. To really understand them, you need to pull out the weeds yourself - Don't sit in the office and think about what it might possibly be like to pull out weeds. Take off your shoes and go walk in the dirt!

That experience in the sun, working with your team will be invaluable for fully understanding the problem at hand, not to mention a huge opportunity to build rapport with the team. And once you understand the problem fully, then you can standardise the solution, and document it, and communicate it, and establish processes for monitoring that your standards are followed.

Of course, perhaps I'm just a control-freak.

It might be due to the pesticides that still flow through my veins - I really need to expand this garden!

Wednesday, 20 June 2018

Turn yourself into an amazing Software Developer

So it's 2 AM now.

My FitBit is complaining that I'm not getting enough sleep, but my mind is telling me there's a problem to be solved.

The Mexican stand-off started at about 1AM until I eventually gave up, so here I am


Anyhoo, what's so important that you need to face the winter cold at 2AM?

Well, over the last few days I've been battling head-on with an interesting conundrum of our industry (especially here in the good ol' RSA):
  1. There is more than enough work to be done, often leading to projects that are sitting on the back-burner because nobody is available to do it
  2. There are tons of people looking for an opportunity to join a project team and build cool stuff.
So surely this is an impossible situation - Let's just put these two problems together and we solve them both.

Not so fast! There's a barrier between the two problems that make them incompatible:


The skills problem plays the role of the Berlin Wall in my world, because even though there may be countless people available (and yearning) to join cool projects, if they don't have the skills needed by the project, it ain't gonna work.

So we have a problem. And, of course, there are many ways to skin the cat from the company's side of the fence.

But this post is about what an individual software developer can do to improve his/her own life by understanding this problem and leveraging it. In particular, it is focussed on developers who may be wondering why they are struggling to get the opportunities to do the cool things that they want to do.

You may be asking yourself:

"Why am I constantly being asked to do mundane things on the project?"


"Why are my job applications constantly getting rejected?"

Of course, I don't have all the answers, but below I'm expanding on a number of steps that I feel each developer should take on the road to becoming a master.

Step 1: Understand that job roles are irrelevant

Our industry is filled with job titles like:
  • Software Developer
  • Full-stack developer
  • Front-end Developer
  • Back-End Developer 
  • Business Analyst
  • Technical Architect
  • Enterprise Architect
  • Test Analyst
  • Scrum Master
  • ...
If you decide you're gonna pick an item from the list above and just be that one thing, you're shooting yourself in the foot from the very start.

A Software Developer who is not skilled at writing specification documents is never going to be able to lead teams who create magic. You're type-casting yourself into a corner.

An Architect who just draws diagrams with blocks and lines, but never opens an IDE is never going to be able to make well-informed architectural decisions. You're type-casting yourself into a corner.

A BA who doesn't actively write code on the project is never going to be able to compile requirements that lead to elegant solutions and expose previously unknown opportunities.

Let me say it again, you're type-casting yourself into a corner.

To become a master you must have a firm grip on the skills in each of these fields. Talk to your colleagues. Read the books that they read. Actively engage with the work they deliver.

Step 2: Get a better understanding of expectations

When you're on a project, your team members expect you to deliver. And with the rising popularity of agile methods, the iterations for delivery are getting shorter and shorter.

If you are given a specific task by a senior person on your team, make sure you understand what the delivery timeline expectations are.

In practice we generally work on 2 week sprints. During that time functionality needs to be fully understood, implemented, tested, deployed and then demonstrated to the customer. That means that any given task on a project is generally expected to be complete within 1-2 days.

In addition to understanding the delivery timelines, make an effort to understand what actually needs to be delivered. Always ask yourself the question: "How will I know I'm done with this task?". If the answer is "When XYZ reviews it and approves", then you don't actually understand the expectation.

If it's unclear, talk to people, get clarity, make it happen.

Step 3: Read

I shouldn't need to explain why reading is important, but let me help out by explaining what you should be reading.

The technical book suppliers (Packt, Manning, etc) all have regular specials and even general subscriptions that allow you to read any technical book available.

As far as possible, try to read at least one technical book every two weeks. And when I say "read", I mean cover to cover.

Yes, you may think that while reading Claus Ibsen's book on Camel, you should try to quickly distill the most important facts so you can get back to your IDE and code - But that is a mistake.

Think of it like this: Claus Ibsen is a globally renowned software developer. Surely, between the code examples there are tons of fundamental explanations that will help you become a better overall developer.

If you read books from cover to cover you join the author on the journey, you properly engage with the content and you become a better developer overall.

Don't skimp!

Step 4: Subscribe to an online learning platform

Don't wait for your company to give you a subscription to Udemy or Coursera or CodeAcademy, or whatever.

Take your own career seriously. Get your own subscription and start learning. Select a platform that works for you, but try to pick one that gives PDF certificates of completed courses.

Not only will your skills improve, but if you go to your boss/architect/project manager every two weeks showing the next course you completed you will soon be given the opportunities you've always dreamed of.

Step 5: Exercise

Write code every single day. Get a GitHub account where you can tinker on non-work-related projects or utility libraries that you regularly use.

Often times there might not be sufficient time to build whole things, and for those days you should keep up your score on platforms like CodeWars and HackerRank.

Step 6: Commit and Deliver

This is probably the most important step in the process. Your team members (not just your boss) can easily identify which team members are committed to the success of the project.

Every project has busy times and then crazy times. When the crazy times come, you need to step up and deliver on your commitments. And beyond your commitments, you must be on board with the team's commitments.

If your team members are staying late to ensure a demo is ready for the next day DO NOT WAIT UNTIL THEY ASK YOU TO STAY.

I cannot stress this enough: Immediately volunteer to stay and help, even if the issue isn't related to your work.

If you prove to your team members that you can be counted on when the chips are down, they will do the same for you. People remember stuff.

Closing remarks

We live in a free world, but freedom doesn't mean everything is free. The only way that you'll make your dreams come true is if you grab hold of the steering wheel and make things happen.

And in the words of Forest Gump: "That's all I got to say about that"

Copyright Note: The image at the top of this post is the iconic image of German soldier Conrad Schumann jumping the initial barbed wire fence that later became the Berlin wall. Photo by Peter Leibing, copyright held by Ruth Leibing. Learn more at:

EOH Connect 2018 :: #DevAnything Talk

If you weren't at the conference, check out the recording here:

Wooohoo - Bike Jumping

Join us in the Open Source Revolution

(Note: Article originally composed for EOH EQ Magazine)

Do you remember the famous Times Square scene from Vanilla Sky?
Tom Cruise parks his black 1962 Ferrari GTO in the middle of Times Square. The place is quiet. No noise, no people, and no cars. Just the black Ferrari.
In Times Square!
He gets out of the car and starts walking. Soon he is jogging, going faster and faster, until he’s sprinting flat out. And then he stops.
That’s how I've experienced the digital revolution over the last 20 years. First it was a few websites that I visited regularly. Then I created logins to participate in the forums. Forums turned into online communities. Websites turned into mobile apps carried in my pocket. All the while, innovation picked up pace until today:
  •   I talk with friends and family on WhatsApp
  •   I get my news on Twitter
  •   I keep in touch with parents on Facebook
  •   I catch up with old school friends on Instagram
  •   I learn new skills on Udemy
  •   I share my photos on Flickr
  •   I plan my holidays on Google Maps
  •   I watch TV shows on NetFlix
You get the picture.
Companies like Facebook, Google, Twitter, LinkedIn, NetFlix and Adobe have become synonymous with the new digital reality of our lives. Yes, these are large companies with thousands of super-smart engineers, but how are they able to build things so quickly? The answer lies in something else that these companies have in common: They are some of the largest contributors to open source software worldwide.
Have you heard of Apache? Sure you have, it runs almost every website you visit on a daily basis. Also, it's fully open source and you can download it for free right now.
Have you heard of Hadoop? Sure you have, it runs almost every big data lake in the world. Also, it's fully open source and you can download it for free right now.
Have you heard of Linux? Sure you have, almost every server in your data centre runs Linux. Even Microsoft has now built Linux into their platform. Also, it's fully open source and you can download it for free right now.
Have you heard of KVM? Perhaps not, but Amazon uses it to run the virtualisation of their AWS cloud. Also, it’s fully open source and you can download it for free right now.
And so it goes on…
Companies around the world have been realising (some faster than others) that the value of software does not lie in the source code, the value lies in how you use it, and in the new world of "Software Platforms" the value of your software often is directly tied to how many people use it.
And if you want your software to be used by many people, then a good starting point is to give it away for free.
You’re kidding me?
How are we supposed to make money if we give our software away for free?
Getting into the details of the Open source business model requires a bit more time than I have available in this short article, but allow me to provide some examples of companies that give away a substantial portion of their IP as open source software:
  • Alphabet Inc, AKA Google, Market Cap = 825 billion USD
  • Microsoft, Market Cap = 725 billion USD
  • Facebook, Market Cap = 552 billion USD
  • Twitter, Market Cap = 18 billion USD
So clearly, there are sufficient counter examples to show that this is perfectly possible. But in addition to simply being possible; in today's competitive IT environment it is essential to work in Open Source, just for your own survival.
A simple example is LinkedIn. In 2010 the company needed a highly scalable messaging system that was both faster and more robust than what the providers like IBM MQ and TIBCO could offer. So they decided to build it themselves. This product gave them a substantial advantage over their competitors in the social media space. However, instead of treating this product as a trade secret, they donated the code to the Apache Software Foundation. The product is called Kafka.
Today, Apache Kafka is used by 7 of the 10 largest banks in the world and 8 of the 10 largest insurers in the world. It has become an enormous success and plays a mission critical role in the routing and ingestion of big data loads worldwide.
A simplistic view of this situation could be that LinkedIn should instead have packaged Kafka into a product and sold it to all those companies. That's what Oracle would've done.
But such a view doesn't consider the whole picture. You see, although LinkedIn started the project, and continues to play a leading role today, there are now 312 active contributors to the Apache Kafka project. About 10 of them work for LinkedIn. So by using open source, LinkedIn was able to use a team of 10 developers to build a product that actually requires hundreds of developers to build.
In other words, by giving a little, they got a WHOLE LOT. More than 300 passionate developers, to be precise. LinkedIn got them for free, and they're building a system that makes LinkedIn a better company every day.
This example shows how the open source community is the perfect place for achieving something that is substantially larger than the sum of its parts.
It's like compound interest for software.
Of course, LinkedIn is not in the business of selling software, so perhaps that's why it worked for them?
Not true.
Many examples exist of highly successful software companies who use open source as a key strategy. For example, Adobe (Market Cap = 99 Billion USD), Microsoft and RedHat (Market Cap = 24 Billion USD). The key lies in not giving ABSOLUTELY EVERYTHING away for free.
These companies strategically invest in open source by giving away a lot of their software for free, but not everything. By giving some of their work away for free they can benefit from the Open Source revolution while also selling proprietary components that add value to the Open Source offering.
So it is possible to make money from Open source, and the most successful IT companies in the world are doing it right now.
We have joined this revolution of Open Source with teams who work on Apps, on Big Data platforms and Cloud Infrastructure. We’re leading the way, and sharing our experiences as we travel. Join us.

Wednesday, 7 February 2018

Where to start?

What is the state of the nation for software development in South Africa?

We have a big IT industry.

We have many people who are technically very capable
  • People who are highly skilled in deploying and configuring infrastructure
  • People who are highly capable in creating complex business requirement specifications
  • People who are highly experienced in installing and configuring packaged software solutions like ERPs, CRMs and manufacturing automation systems
  • People who are highly respected for their ability to compile elaborate and mathematically sound process maps
  • People who are exceptionally talented in designing beautiful mobile and web apps

But I have one concern: I'm not sure we have an abundance of people who have the ability to design and develop custom software solutions.

Of course, this concern of mine is based on my own experience. And that experience has taught me that we definitely HAVE expert software developers in South Africa. I'm just not sure if we have a great many of them. Too often I sit in boardrooms where solutions are discussed and technical details are glossed over: "Let's not get technical", they say, or "I'll discuss this with the development team and get back to you".

It seems to me that we have created an industry filled with sales people, account managers, business analysts, solution architects, user experience designers and more. These people are all amazing, and they have amazing ideas - ideas that could well change the world. But ideas need to be implemented.

And I suspect.

Based on some hard-won real-world experience:

That when the time arrives to implement ideas, we are a bit short on capacity in South Africa.

To be fair, I may be entirely incorrect, and in reality this blog is part of my research to investigate whether I am. But the anecdotal evidence all points in the same direction: When we see problems, we look for existing products that we can buy to take our problems away. We buy CRM systems and configure them according to our needs. We buy ERP systems and configure them to our needs. We buy content management systems and configure them to become our websites. And much, much more.

On the face of it, this is a perfectly logical approach. After all, it is definitely faster and cheaper to buy an existing product than to develop it from scratch. But unfortunately, this approach comes with a built-in assumption: That our problems have already been experienced by someone else, and someone else has already solved it.

Which means we have admitted defeat in the innovation race; even before the starting gun has been fired. Innovators are people and companies who create problems that nobody even knew they had. They design a car when others are still figuring out how to make a faster horse.

If Sergey Brin and Larry Page were followers, Google would've created just another Altavista, which in turn was just another electronic version of the Yellow Pages. But they were innovators, and in the process they created a brand new problem: How do we build a highly scalable index of the Internet where search requests return accurate results.

There was no existing product that they could buy and customise with their logo to create Google.

Today, Google is a world leader in many fields, well beyond just search technology. Interestingly, following the release of Elasticsearch v1.0 in 2014, any company could buy a product, configure it according to their needs, slap on their own logo and establish their own global search engine. In effect, ElasticSearch is the productised version of what Google was when it launched in 1998.

So that's the difference between a leader, and a follower: 16 years, and 744 Billion US dollars.

And the same applies to any other field of technology: If you can buy a product to solve your problem, then your problem is old and stale. Yes, solving your problem is necessary, but it is necessary in an effort to CATCH UP, not in an effort to GET AHEAD. If you want to GET AHEAD, you need to start with fresh ideas. You need to assume nothing. You need to create your own problems.

When Netflix wanted to create a streaming video service, the technology for scaling and load balancing such data volumes didn't exist. They couldn't approach IBM to purchase a packaged solution to their problem, because nobody ever had that problem before. So they built Ribbon and Eureka themselves, and that has made all the difference. Today, there are many streaming video services worldwide, but there's only one Netflix and Chill!

So innovation requires breaking boundaries. It requires opening your IDE and writing the first line of code for a new project that exists nowhere but in your mind.

If we want to foster innovation in South Africa, we need to ensure that more people are enabled to write that first line of code.

We need to ensure that more people are encouraged to write that first line of code.

And we need to ensure that more people choose to write that first line of code.

Don't get me wrong; I'm not saying configuration is a bad thing. Many problems that we face on a day to day basis have been solved already, and for those we need to leverage the collective minds of the past. We need to buy tools and configure them according to our needs.

But if we want to lead the way, we need to create new problems.

Don't be a hero :: How to build successful software in a skills-deprived world

I used to be a nice guy. In the early days of my career I did a lot of training, both business and technically-focused. One of the most re...