Lukasz Machowski

Life is a mystery, wrapped in a conundrum, nested in a recursive method.



What Information Theory can teach us about Software Development – Notes from Scrum Gathering

I recently attended a very thought provoking talk by Janco Wolmarans (@jancowol) at the Agile Scrum Gathering Conference (@SUGZA, #SGZA). It really got me thinking.

Janco Wolmarans
Janco Wolmarans

I have captured my notes from the talk so that I can internalise what was presented and also to share it with you. My hope is that it can shed new light on how we perceive coding and it can make you look at the activities surrounding software development differently next time.

Since I am an electrical engineer, the idea of going back to this rather technical view of software development as the transfer of information across a channel really appealed to me. Although aspects of the talk appear to be very theoretical, the magic of Janco’s presentation is that it leaves you thinking… “Hmmm, that actually does apply to software development”.

At the end of the blog, I also explore some of my own ideas surrounding code comments and the benefit of double-encoding.


Janco started his talk with a reflection on whether there is something more fundamental to software development. When we don’t understand something, we use a metaphor in its place. “Something is like something else”.

“Metaphors reign where mysteries reside” – Chuck Missler

The problem with metaphors is when they don’t apply.

What is Programming?

  1. A set of instructions for a computer to exercise (insert favourite dictionary definition here).
  2. A description of a solution to another programmer disconnected in time. This could be another physical person but it could also be yourself later in time.

What is Information? Is Code Information?

Janco ponders the thought of whether code is information. Information is a polymorphic concepts and the definition of it is specific to its context.

The general definition might look like this:

  • X consists of one or more data.
  • The data in X is well formed.
  • The data in X is meaningful.

Therefore, we can answer the question: “Yes, code is information”.

  • The data is made up of the characters of the source code.
  • The code is well formed and complete because of the syntax that defines the language.
  • The code has meaning, not only to the machine, but more importantly to other programmers.

Information Theory – Claude E. Shannon (1948)

Claude Elwood Shannon - Father of Information Theory
Claude Elwood Shannon – Father of Information Theory

Claude Elwood Shannon is known as the father of Information Theory. Just about every form of digital communication we use today is based somehow on the seminal work that Shannon did. Janco gave a brief overview of Shannon but I was most intrigued to hear it again because of my recent interest in data compression (watch this space). Janco presented the following illustration which describes communication in just about any information system. Notice the important distinction between the signal and noise. This means that a message “X” might come out slightly altered “X’ ” on the other end.

Generalised communication in an information system.
Generalised communication in an information system.

Janco presents an interesting idea, which is “What if we drew software development in this fashion.” Below is my rendition of his picture, with my own ideas on what could be considered the signal and noise.

Coding represented as a Signal and Noise
Coding represented as a Signal and Noise

Signal vs. Noise

  • The signal is the solution to a problem.
    • I added my own ideas on what would belong in the signal in the illustration above.
  • The noise is all the other things that are around the code.
    • Fluff
    • Accidental (but necessary) complexities.
    • I added my own ideas on what would belong in the noise in the illustration above.

Information Entropy

Entropy in physics is the tendency to move towards disorder.

Shannon’s definition of entropy in an information system is different.  Information entropy is the log-base-2 of the number of possible outcomes [wiki].

With two coins there are four outcomes, and the entropy (N) is two bits.
With two coins there are four outcomes, and the entropy (N) is two bits.

Janco makes the following remarks about entropy:

  • It is based on the probability.
  • Entropy is equivalent to uncertainty.
  • Uncertainty of the code doing what I expect.

The way that I like to explain entropy is with the following example…

Try and guess the next number in the sequence: “1,2,3,4…?” If you answered “5” you would be right. Now try to guess the next number in another sequence: “1, 9, 0, 6…?”. If you answered “8” then you somehow miraculously would have also been right. The second time it was a bit harder to guess what the next number might be. Therefore the second sequence had higher entropy. I base this example on my understanding of what is written on the wiki:

If one of the events is more probable than others, observation of that event is less informative. Conversely, rarer events provide more information when observed. Since observation of less probable events occurs more rarely, the net effect is that the entropy (thought of as average information) received from non-uniformly distributed data is less than log2(n). Entropy is zero when one outcome is certain.

4 Rules of Simple Design – Kent Beck

Janco then presented some important design concepts made popular by Kent Beck, the father of Agile Programming.

  1. All tests must pass.
  2. DRY: Don’t repeat yourself. Refactor the code to avoid duplication of logic. Call the common code.
  3. Clearly express intent.
  4. No superfluous parts.

Janco makes the clear connection then to an information system:

  1. Signal
  2. Entropy
  3. Entropy
  4. Noise

XP Values – Kent Beck

  1. Communication
  2. Feedback
  3. Simplicity
  4. Respect
  5. Courage

Janco points out that 1-3 relate to effective communication. He then asks: “What would a model for Dev-to-Dev communication look like through the medium of code?”

Dev to Dev communication in TDD
Dev to Dev communication in TDD


Refactoring is a way to achieve “DRY” and to “Clearly Express Intent”. To refactor is to express the solution in a different way but to keep the same outcome. Refactoring increases the clarity of the solution by raising the level of abstraction. This is done by encapsulating many low-level concepts into one higher-level concept (by adding more context). This leads to a reduced message space, thus lowering the level of uncertainty throughout the system.

“Being abstract is different from being vague” – Dijkstra

Abstraction = New Level where you can still be precise

Good programmers write code that other humans can understand.

Things to Explore

These are some ideas that came out from the audience or were raised by Janco as additional ideas to explore. If you have some thoughts on these or additional ones to add, please leave a comment below.

  1. We need to better articulate “Noise”. What are concrete examples to look out for and can we mitigate it?
  2. We want to have a Ubiquitous Language. See Domain Driven Design (DDD).
    1. Strive for one mental model across Client – BA – Dev.
    2. Have a problem with different perspectives of the problem.
  3. Mob Programming
    1. Reduces noise because we all share a common signal.

That was the end of my notes from Janco’s talk. Below are my own ideas to augment what he presented.

Comments are Noise! Really? I say no! It’s a redundant Channel.

Something that really struck me as odd during the talk was Janco’s negative attitude towards comments in code. This sentiment seemed to be shared by several members of the audience. This didn’t sit well with me at all. It seemed like Janco’s take was that code should be self describing. The problem with code comments was that they tend to be superfluous and they can easily get out of date. Maybe I was missing a critical piece of context that they were privy to and I wasn’t.

I have also heard other people saying “Only write comments where the logic of the code is not obvious”. My personal commenting style obviously annoys the heck out of those people, because I comment everything. Sorry.

My take on it is simple (you will see why it makes sense later):

Write comments everywhere so you can tell the whole story of the code only by reading the green lines (comments). Ignore the actual code until you need to dig into the detail.

This seems crazy at first. Why on earth would you write the perfect solution in code and then write it again (imperfectly) in English? Let me reveal another important concept that was NOT addressed in the talk by Janco but I learnt the hard way at my excellent time at Cyest. It was once again confirmed at Synthesis.

The Value of Double-Encoding

Imagine if I could tell you that we could write code in such a way that a positive outcome is guaranteed when a bug is discovered. You would probably say I was crazy. The answer is simple…

Encode the solution more than once. If one encoding has a bug then the other encoding can be used to look where the logic differs from the first. If the bug is a logical error then both encodings will not make sense in the context of the situation (thus highlighting the logical error). This is a win-win situation.

We have been doing this with Unit Testing for ages. Unit tests are an additional encoding of expected outputs given known inputs. It checks that the code (encoding 1) behaves exactly as expected when compared to the unit test (encoding 2). If the outputs differ then the system reports a failure and a bug is picked up. What is interesting is that at the extreme end of this argument it even makes sense to simply “copy-and-paste” actual implementation into a unit test and compare the outputs against each other. The value in this is only made clear down the line (later in time) because unit tests tend to change slower than code. If a bug is introduced into the code, there is still the previous implementation in the unit test that will give capture the old behaviour exactly. Obviously this approach assumes good sets of known inputs.

My idea is that the code comments act as a second encoding to the code but it’s not in a completely separate [disconnected] place in the code (like unit tests are), rather it’s inline with the code. The wording then becomes the following:

Encode the solution more than once by commenting everything (even the obvious code). You can find encoding bugs by looking for places where the code differs from what is described in the comment (or vice-versa). You can find logical errors by tracing through the expected logic and seeing where either the code or the comments tell a different story. This is a win-win situation.

3 Possible Outcomes with 2 Encodings
3 Possible Outcomes with 2 Encodings

For the first time, Janco’s idea of relating code to an information system gives me a language to use where my argument makes some sense. The idea is commonly used in very noisy channels. By adding a redundant channel to transmit the signal, you are able to compare both results at the end and more easily pick out the signal from the noise. The chance of both encodings having an error is much smaller than only one of the encodings having an error. With one channel, you really can’t tell.

If you were to extend this idea to 3 channels then something even more useful pops out:

Best of 3 wins.
Best of 3 wins.

If we use inline (or in-band) redundancy in the form of code comments AND we use out of band redundancy in the form of unit tests then we are able to use a “best of 3” strategy to decide which encoding has the bug. The chance of all 3 being wrong is now even less, making bugs much easier to find.

I have found this technique SO useful when writing and maintaining rather complex code (the calculation engine for a financial modelling tool, for example) that I have now decided that I will write all my code like this. As with all developers, writing the unit tests is a “Best-effort” endeavour. I always have great intentions but there is usually some external factor hindering me. However, inline code comments are something I can ALWAYS do, and therefore I have chosen to do exactly that.

Therefore, if you ever come across my code and it’s commented EVERYWHERE (even in the obvious bits), please don’t get upset with me… there is some method to my madness. I never know where the bug will be in my code, but the tiny bit of extra effort it takes to add the multiple encodings pays itself back many times given the full life span of the code.

“It’s not magic… it’s statistics” – Luke

Comments from my Colleagues

The following is a very interesting set of replies that I got from people I work with. I humbly thank them for their insight because I have a lot of respect for their ideas. I feel that it’s very important that I post this because it captures to polarization of thinking around the topic above. It also provides a very seasoned perspective on how my argument around comments in the code should be considered carefully.

I have only provided first names here to keep the conversation flow simple.


I have to say that I agree with Janco that comments are mostly noise and really don’t buy your idea of commenting everything.

I like Robert C. Martin’s reasoning that your code should be human readable and therefore comments add no additional value.  The emphasis should therefore be on writing “Clean Code”, and not cluttering your code with comments.

Check out Robert C. Martin’s “Clean Code: A Handbook of Agile Software Craftsmanship“.  I found this book to be incredibly inspiring and good at showing what “clean code” is and what “clean code” should be.  The book is in the “library”, so check it out.


I believe that comments can be noise however have a look at the following code:

using System;
using System.Numerics;
namespace PiCalc {
internal class Program {
private readonly BigInteger FOUR = new BigInteger(4);
private readonly BigInteger SEVEN = new BigInteger(7);
private readonly BigInteger TEN = new BigInteger(10);
private readonly BigInteger THREE = new BigInteger(3);
private readonly BigInteger TWO = new BigInteger(2);
private BigInteger k = BigInteger.One;
private BigInteger l = new BigInteger(3);
private BigInteger n = new BigInteger(3);
private BigInteger q = BigInteger.One;
private BigInteger r = BigInteger.Zero;
private BigInteger t = BigInteger.One;
public void CalcPiDigits(){
BigInteger nn, nr;
bool first = true;
while (true) {
if ((FOUR*q + r - t).CompareTo(n*t) == -1) {
if (first) {
first = false;
nr = TEN*(r - (n*t));
n = TEN*(THREE*q + r)/t - (TEN*n);
q *= TEN;
r = nr;
} else {
nr = (TWO*q + r)*l;
nn = (q*(SEVEN*k) + TWO + r*l)/(t*l);
q *= k;
t *= l;
l += TWO;
k += BigInteger.One;
n = nn;
r = nr;

private static void Main(string[] args) {
new Program().CalcPiDigits();

From the function names it is clear that we are calculating PI. However, I believe that comments or a link to the algorithm IS needed. Just renaming the variables will most probably not work. Further, I have had many times where clients that are not technical looks at the code and can understand what it does via the comments and have been able to give valuable input. So even though comments do tend to ‘decay’ over time if the ‘signal’ component is strong enough in the comments they will continue to provide pointers in the right direction.


Hi Johan. My argument would be that the code example you have given is NOT an example of clean code and hence it is confusing to read.

The main problems with the code is that:

  • Variable names are not descriptive
  • The method is way to long

A clean code example would probably be more something like:

while(true) {

The names of the methods then lend to describing the logic and the code becomes more “human readable”


Both comments really add a lot more depth to this discussion. Both sides highlight important aspects that need to be considered in context.

I appreciate you taking the time to shed light on the parts that matter in code.

I might not have the perfect commenting strategy but it is interesting to relate the idea to Information Theory as Janco presents it. It makes you think…

What Garth presents is clearly a good method to enhance the fidelity of the signal (in one band). I would imagine that we all would agree that If this is possible then it’s always preferable. However, Johan highlights a case where (for arguments sake) it’s not. When I look at the PI digit calculator, I also know that the code is usually used in a performance critical section (eg: I want to calculate PI to the billionth digit etc) and there might be good reasons (that I am not aware of from the little context we have) why the code needs to be written in that fashion. It that was the reason for the style of code as written, then I would personally prefer to have the inline comments to help me along without having the performance knock of the extra method calls (and yes, I do realise that I might be opening a can of worms now around the debate on micro-optimisations being done by hand vs the runtime jitter).


My turn!

While I agree with Garth on better descriptive names, I think we must use some common sense and judgement not to normalise to the n-th degree. In languages with first-class functions then it’s mostly cool, but in crummy Java and C# you tend to end up with a proliferation of rubbish functions that are only useful in a single context.

E.g. Too many functions called batty names like:
If (StringIsNotNullAndEqualToSynthesis(myString)) {
.. Blah

are actually not as readable as
If (“Synthesis”.equals(myString)) {
.. Blah

Also – I find it really helps to try to make your code as immutable (google it) as possible,

e.g. Garths previous example:

while(true) {

Shows clearly that mutation is happening and therefore not clear what the code is actually doing (because it all happens outside of this snippet). This makes this code difficult to lift out without diving into the rabbit hole of each function. The rule of thumb is that a function should take as parameters all it’s inputs, and are a return value return all the outputs. It should not mutate anything else (as far as possible).

Soooooo many benefits to doing this:

  • Truly testable code (no injecting weird dependencies into seemingly unrelated objects during test setup).
  • Super easy to debug (maybe no debugger required even! Stuff doesn’t ever change!)
  • Performance benefits! You don’t need to copy data around for various usages, because you can guarantee that data doesn’t change you can simply pass around a reference to each caller without the danger of them modifying it! (flamebait achtung!)

Hey I’m not saying this is a firm rule, it’s simply a nice starting point – obviously you are going to need to mutate stuff. I’m just stating that I bet you the “mutant” area of your code will contain the bulk of your bugs 🙂


Hi Tom,

I fully get your point about immutability and functions taking all their inputs as parameters and spitting out one output.  What I find is that this is a natural by-product of test driven development.  So for me this is one of the reasons why test driven development is a must and not an option.


Hi Luke, great that you took the time to write this down. I like the direction; esp. with double verification and in-line value of comments. The problem is comments are not machine-verifiable/runnable. Perhaps if we write our comments in a language like gerkin, we’d achieve in-line unit tests. Something like (excuse inaccurate syntax):

// Scenario: Sums 2 numbers
// Given 15 and 12
// Expect 27
int sum(int i, int j) {}

Another point, is the trends seem to be towards higher level unit-test; so the double verification is not on the base utilities – these will get covered through broader, more efficient sweeps.

Of course code should be as expressive as possible.

Can Agility Change the World? – Notes from Scrum Gathering

Some people just have it. Cara Turner (@Cara_Faye) at the Scrum Gathering definitely has it! She delivered an inspiring and thought provoking keynote, which I would like to share with you. Her slides are here and I borrow several screenshots from them because she has great visuals.

Cara Turner (@Cara_Faye)

Cara is involved in a company called Codex which teaches eager South Africans how to become coders. They embrace Agility as a key tenet of their methodology and give the students hands on experience on how to deliver working code. This is their solution to the scarcity between skills and jobs in the country.

My post starts with a realisation which stems from the thinking inspired by Cara. It relates the current student-crisis in South Africa to the startling realisation that Cara and people at Codex discovered. My post follows with a brain-dump of my notes from her presentation. I hope there are some interesting ideas that you find useful in here. Leave me your thoughts in the comments below.

Double Pyramid of Needs

The missing link between Government and Industry

Cara presented her thoughts on scarcity and privilege. This is relevant because there is a severe shortage of programming skills amongst the have’s and have-not’s in South African society. At the time of writing, South African students are protesting because of fees (news article here, and here: #FeesMustFall). My take on it is that there is an underlying (deeper) issue at the root of the problem and it’s NOT education, and Cara’s presentation gave me a glimpse of what it might be.

When CodeX started out, they (diligently) believed that the solution would be to uplift education in order to improve employment. This is how Cara presented it:
Network Effect

This makes intuitive sense. Sure, why not! What startled me was when she said that they learnt the hard way that their real challenge in achieving that was to first bridge the digital divide that stopped students from being able to spend time on their education. It’s all the stuff at the bottom that has to come right too.
The Digital Divide

The real problem is NOT people’s unwillingness to get educated. And not even their access to education. The real problem is their inability to do so due to constraints on all the factors below education. Eureka! For the first time I can see the direct connection that the government has in the technological upliftment of its people. They mustn’t worry about the upper factors because people like Cara can do that. Industry can do that. Business can do that. Universities (which I see as a bridge between Industry and Academia, themselves being a Business) can do that.

Instead, Government MUST provide people with the basics: electricity, water, sanitation, safety, health, social support etc. The rest will sort itself out. Governments responsibility is to ENABLE education by allowing the factors below to come right for each individual.

I like to see the double pyramid like this:

The double pyramid showing what Industry and Government should focus on
The double pyramid showing what Industry and Government should focus on

Governments responsibility is to do this. It has let us down! Dear President Zuma @PresidencyZA, please focus on your pyramid and we will handle the rest.

The way that Cara explained how they overcame this challenge (or to use a software term: ‘worked around the issue’) was by applying an agile-inspired solution to the problem. Flip the triangle around. They instead acknowledged that people will have transport issues and be unreliable. Going to the clinic is not something you do in an hour… it takes a whole day. Looking after your brothers children while he goes to your grannies funeral is just a part of life. Instead of having set lectures and exams at specific times, students work at the pace they can sustain (Khan Academy comes to mind). There are concrete milestones along their learning path. It doesn’t matter if you go away for a week. You can continue where you left off. This is genius. It reminds me of how Agile has broken the reliance on Fixed Requirements upfront. So too has CodeX broken the reliance on firm commitments by the students all the time.

Someone on the radio said today ‘People in positions of privilege won’t understand these issues that the students are facing’. With the context presented so elegantly by Cara, I think I am able to get a glimpse of it now.

I have an open challenge to you… while we wait for government to bridge the gaps of the first pyramid (relying on mass-action like tomorrows march by students to the Union building to make the issue real), what are ways that you can ‘flip the triangle around’ to work around the gaps? Swap one thing for another in your context and imagine what would happen… then try it out!

What follows is a collection of my notes from Cara’s keynote session. This provides additional context to the argument above but also has several gems that are worth taking from her talk.

Can Agility Change the World?

Cara Turner’s Keynote

What makes a hero? Ordinary people that decide that they will make a change and embrace the opportunity to make a change they want to make.

Hero = Ordinary People + External Trigger + Change

But we are all too busy with the problems in front of us. In spite of our best efforts, when the going gets tough, we fall back to our old habits.

Scarcity Science

Relevant for anyone that experiences a “Sense of Lack” or “I never have enough”. What happens to the mind is that our active and background mind is fully consumed on the problem in front of us. We get tunnel-vision focus on what is in front of us. This is an important mechanism from an evolutionary perspective but it also becomes a hindrance in our modern day world filled with stress. This becomes a problem if it persists all the time. We go into a mode of “What is the lesser of two evils”.

In times of scarcity, when there isn’t enough of a resource, the following happens:

  • No time to stop and think
  • We make poorer decisions
  • There is a greater cost to making mistakes
  • This causes more problems
  • Leads to failure
  • Puts more pressure by creating a demand to solve
  • No slack

In a time of scarcity, you behave in a way that reinforces that you will have very little in the future.

The effect of Design

Cara shared a story about Bomber planes during the war that would come back from successful missions, only to crash during the landing at their home airport. The reason was poor design where the landing gear lever was right next to and looked very similar to the air brake lever. All it took was one small change to change the whole situation around. They simply put a rubber band on the one lever to differentiate the two.

A rubber band was placed on one of the levers
A rubber band was placed on one of the levers

One small change can make a big difference

Agility and Scarcity

Look for tools and practices that can:

  • Improve feedback
  • Support decision making

Change Super Powers

  • Change and adapt. Make an assessment on where you are and whether you are getting better.
  • What is the next small change to make a constant cycle of “Change and Adapt”?

The Network Effect

Consciously choose to act on our strengths. It has a rippling upward-spiral effect on the whole system. I like to say: “Always be positive. Its easy to focus on the negative but don’t, learn from it and focus on the positive instead”.

A small positive change can have a positive spiral effect on the whole system
A small positive change can have a positive spiral effect on the whole system

Continual Improvement

“We are uncovering better ways by doing it and helping others do it.” – Agile Manifesto.

It’s our responsibility to share our techniques and insights with others. That way we can ensure a continual improvement.

What’s Next?

  1. Challenge: What are the small things that you can change to see what kind of effect it will have?
  2. Don’t try to learn everything upfront before you start. Just start.
  3. Start and keep learning as you go.
  4. Share your knowledge as you go. [This is the line that inspired me to start blogging].
  5. Be part of a community.
  6. Keep inspecting and adapting as you go.
  7. Build us a new super her tool. Build it together with your community.
  8. We need all kinds of hero’s.
  9. Solve the problem in front of you.

I aim to use the above as a personal checklist. Very inspiring Cara!

Our Next Challenge

One demographic holds all the skills in software. There is a great digital divide between the different demographics. Why? Because of Scarcity and Privilege.

We are not all made equally.
We are not all made equally. Some enjoy more benefits than others.

Help short people be like tall people. The system is designed for tall people but we have a workaround.

Tall people are just better off. The system is designed for tall people.

Everyone's perspective matters.

How do we change the system?

  • Innovation is social.
  • We need people that have skills and knowledge of their specific problems.

Organisations with greater gender and ethnic diversity pay better dividends. Gender and racial diversity is a good sign of health in an organisation.

Diversity + Inclusion = Improved Business Performance

Change is hard. Gestures cost money to achieve the benefits and avoid the costs. We must make a meaningful investment into it if we want to reap the reward. This sounds similar to where the Agile community has been.

Change Routines

  • Mentorship
  • Change the way you recruit
  • Extend invitations broader than you normally do. Invite people.

Agile Skills

  • Create a safe space.
  • Talk about the issues. Have those uncomfortable communications.

Why is it so hard? Because we have a sever shortage of skills. CodeX aims to bridge that gap through education in agile software development. Eduction is a foundation, but actually it’s at the top of a basic needs pyramid.

Next Challenge

  • Scaling agile training
  • Person to person interactions

Creating Change

  • Look at the problem in front of you.
  • Make an experiment.
  • Share it with the community.

Parting Thoughts

  1. Tackle the Wicked Problems
  2. Be unlikely
  3. Be yourself
  4. Rise to the Challenges to create the change you want to see in the world

“The best way to predict the future is to invent it.” Alan Kay

Unlikely Heroes – SUGSA Agile Scrum Gathering Conference

I recently had the privilege of attending the Scrum Gathering in Rosebank, Johannesburg. This was my first proper Agile conference and it was quite an eye-opener for me. In this post, I would like to share with you some of my observations and comments. Mainly as a way for me to internalise the content, but hopefully so that you can find some aspect of it useful and thought provoking too.

Where are all the Woman in Software?
In Agile, of-course!

One of my most pleasant surprises from the conference was how many active, passionate and inspiring woman I saw at the conference. Speakers AND attendees. Not as software developers, but as scrum masters and coaches [NOT project manageresses]. The fact that I find this surprising is a sad reflection of the software development industry but I was excited to take part in an event that really show-cased thinking with a female touch. Both Keynote sessions that I attended were presented by ladies (Thato Kgatlhanye and Cara Turner). I must say that I haven’t been this inspired in a long time. They really packed a punch. Good on them! Thank you!

Thato Kgatlhanye - Rethaka
Thato Kgatlhanye – Rethaka
Cara Turner (@Cara_Faye)
Cara Turner (@Cara_Faye)

It’s as if any male-dominated influence in the software development world hasn’t yet had a chance to dominate, leaving a much welcomed gap for women to take the lead. It makes sense, because the agile movement is still relatively young – as in youthful, not infantile. Everyone started on an equal footing so there hasn’t been a chance for the vacuum to be created.

This transformation is one of the unsung heroes that the agile movement has enabled!

It often seems to get forgotten when mentioning agile. It wasn’t explicitly said anywhere in the conference (unless I missed it), but I feel it should be.

Disconnected Circles

supervista_educationicons_maths_256Another interesting thing that struck me at the conference is how segregated the various communities seem to be. I am making a concerted effort to attend as many user groups, events and gatherings as I am able to (and I thank my wife for giving me the space to do that), but I was surprised at the lack of familiar faces from the other groups. You almost expect to see some familiar faces that are always present in certain gatherings, but this group seemed completely new to me. During the sessions I realised why this was… most of the people attending were NOT developers… they were Scrum people. That made me think how segregated the groups actually are. I felt lucky to be part of the conference because I felt like I got to find out some “inside information” that I otherwise would not have been able to get access to. It does make you wonder why more developers don’t attend agile conferences. I would really recommend this for any developers that need to better understand business, their users and working in a team (and that should be all of them). It also makes me realise how valuable the culture is at my work (Synthesis). It’s a culture worth protecting because it emphasises the need for this multi-faceted thinking. Agile seems to have that covered.

Lightning Talk: Saving the day by starting today
Tjaard du Plessis

sigma_projectmanagment_energy_128My colleague, Tjaard, was asked to present a lightning session within a window of only 10 minutes. This means that the speaker really needs to think carefully how best to get the their message across effectively. True to Tjaard’s style, he managed to pull this off flawlessly. I felt that his session was just as impactful as any of the longer sessions.

In his talk, Tjaard introduces 2 important principles that often relate to each other:

  1. Parkinson’s Triviality Principle
    • We have a tendency to focus on trivial problems and ignore complexity… because it’s easier to do so.
    • We tend to digress into solving the simple cases.
    • Therefore we shouldn’t spend most of our time focussing on a trivial problem.
  2. Pareto 80/20 Principle
    • 80% of the land is owned by 20% of the people.
    • 80% of the value in our system is due to 20% of the functionality/features.
    • Engineers and Entrepreneurs see the world as a problem to be solved.
    • The problem of trying to get all the “What-Ifs” is: “What-if I haven’t thought of all the what-ifs“?

His realisation is that both 1 and 2 are related.

“We tend to digress to the trivial because we can’t think of all the what-ifs.”

The solution is to “JUST START!

So how do we define “Start”? Well, in engineering, the process is well defined: Analyse -> Design -> Develop. In software, the process of development is part of the analysis.

A start in software is NOT something you do AFTER you have certainty. You gain the certainty only after you have started.

Delivery is the best way to gain certainty. While you are gaining certainty, you are delivering. We need to be in the correct arena to solve the complex problems.

I imagine that Tjaard had this picture in mind (which he shared with me during a break).

This highlights how the traditional waterfall model fixes the features at the expense of uncertainty on time and cost. Agile on the other hand insists that the cost, time and quality be fixed and the features that will be delivered are the unknown.

Tjaard then proceeded to show a photo of their user story map, highlighting how stories that are important are placed above a release line (20% features that give 80% benefit), while other items are captured below the line. This technique breaks the tension usually experienced because thoughts by team members at random times are acknowledged and captured but they are placed below the line so that they don’t distract from what is important.

Tjaard’s challenge to all of us is the following:

How is it that your team is obtaining certainty?
… and START there!


There was definitely a lot more covered in the conference that I have not captured above. I intend on completing my notes over the next few days.

Blog at

Up ↑