My principles for work life balance

I have just spent the most amazing two weeks in my old neck of the woods. One week in my hometown of Port Elizabeth and a week in the most stunning place called Cape St Francis, right on the beach. We have spent some quality time together as a family with most of it been spent on the beach and playing in the waves, and just enjoying the surroundings. This has given me plenty of time to do some thinking about what I want from my life and the principles that I want to measure myself on, both in my professional pursuits and my leisure pursuits.

Be the best

I want to be the best that my potential will allow me to be. Whether this is in my pursuit of becoming a better middle distance athlete, or in my career of becoming a better Software Craftsman. Either way it takes effort and practice to improve oneself.

Have fun

As part of becoming better at what I do I want to make sure that I am having fun while doing it. If I am not having fun in whatever I am doing, then the situation needs to be re-assessed. If I am not enjoying coding then I will not enjoy practicing in order to get better. Even though I have been on holiday in the most amazing setting, I have still managed to practice my craft by doing a little bit of coding every day. It is not a chore, but something I look forward to when the family goes to have there afternoon nap.


I read a book called Spark: The Revolutionary New Science of Exercise and the Brain shortly after I got back from my sabbatical and it had a marked impression on me around the importance of exercise and how it affects how we function.

If we don’t make an effort our lives become very sedentary, we sit in the car to work, we sit at a desk all day, we sit in a car on the way home, we watch tv and then got to sleep. This gets repeated day in and day out, and before we now it we are suffering from any number of health issues.

My experience is that if you are not disciplined about what you put into your body and how you exercise, when the going gets tough at work this is first to go. And I have had the experience where as my health suffered so did everything around me. So for me being fit and healthy is part of my success and it also needs attention.

Work with like minded people

It is important for me to work with and associate with like minded people. If you see your job as just a pay check, then that does not inspire me. It becomes more difficult to live by ones principles when the people that you surround yourself with don’t strive for similar objectives.  I want to discuss the awesome run or bike I had, or I want to have a discussion around some exciting coding technique or technology I uncovered with the people I associate with. I want the people around me to be as excited as I am about what I do.

Continuos learning

Continuously learning is very close to my heart. This goes further than just practicing your craft. You need to expand your boundaries by reading on different topics, exploring new technologies or different techniques to accomplish something. Part of my continuous learning is reading a lot and going to Meetups where I can learn from and engage with peers in the field of interest.

Measure success by happiness

Finally I want to measure my success by my happiness. Over the last 18 months I have had the opportunity to re-evaluate many of the principles that drove me before. So for example, job titles are not important to me anymore, sacrificing these principles for a bigger pay check will not happen, working to dead lines that constantly break my principles will not happen anymore.

My job is not a 9 to 5 stint that I despise every day, rather I enjoy what I do and I enjoy investigating solutions to problems, whether at work or at home. There is nothing better than getting paid to do something that you really enjoy doing, essentially your hobby. This is a mindset I hope to instil in my children, in what ever career they undertake, so that their careers will also be something they enjoy doing one day.


Posted in Uncategorized | 1 Comment

What Software Craftsmanship means to me

I don’t feel comfortable calling myself a Software craftsman, I am more like a journeyman striving towards one day becoming a software craftsman. And this is a journey and experience that makes me get up everyday to go do work I enjoy.

There are a number of posts lauding the virtues of software craftsmanship, as well as a number that highlight the negative sides of the Software Craftsmanship movement. And when I read these arguments, both sides have merits.

One argument against Software Craftsmanship is that it puts “beautiful software” above software that simply does the job. And I think that if this is true, then indeed there is something wrong. When I read the Software Craftsmanship manifesto1 this is not how I understand it at all.

For me, however, it is about being pragmatic, if I am working on a piece of code that is going to be worked on a lot by a number of developers, then I will spend time to make it look good and tell a story. But if it is a piece of functionality that has not been touched for the last five years, then I am not going to spend days refactoring the code into something that is pristine.

In this regard I believe in the Boy Scout Rule2 of leaving the area cleaner than when I found it. I would rather do a simple spring clean with some refactoring to help me in understanding the code. And if I am not sure as to how often the code is going to change then I will do what I think is enough to make it easy for the next person to read and understand the code. So I am always thinking of the next person who is going to read the code.

As a code base is becoming cleaner, smaller and more understandable the ability to deliver valuable business features is enhanced. When a developer does no have to wade through masses of spaghetti like code to complete a feature, everyone benefits. So sometimes slowing down to speed up is definitely worth it.

Software craftsmanship also allows me to give back to my colleagues. I think it is so important to play a mentoring role to junior developers who are apprenticing to become software developers. This allows me as a more senior developer to assist them on their journey to becoming better software developers. If the mindset around Software Craftsmanship is going to grow positively, it is important that the more experienced developers play a role in guiding and assisting juniors in shaping their values for software development.

Mentoring also allows for my continued improvement. Not only do I also benefit from being a mentor by having my thinking challenged by fresh minds, but I am constantly challenging myself on how I can do things better. One part of this is by finding tools and techniques that will allow me to craft software that adds business value at a regular cadence.

As someone striving to become a Software Craftsman I believe it is important to understand the business intimately. This understanding allows us as developers to craft software that is simple and tells a story which, our business counterparts would be able read as well. The benefits of this is that when we are talking about concepts or features we are talking with a common language.

It is also important that the business or customers are taken on this journey. If they could not care about the future maintainability or just want apps pushed out the door as quickly as possible, then I would not stay around long because these are my principles that are being broken. But if my customer cares and wants something that will stand the test of time and which everyone is proud of, then this becomes a very fruitful partnership.

So for me, Software Craftsmanship is a set of values that I measure myself and what I am delivering against. I want to surround myself with people who take these values to heart as well. This is not only for my benefit, but hopefully I can assist them in becoming better as well. And it is part of being a professional software developer.


  1. Software Craftsmanship Manifesto – available at
  2. Boy Scout Rule – available at
Posted in Software development | Tagged , , , | Leave a comment

My first Kata

This morning I did my first Kata, and I must say it was a really enjoyable experience. So, what is a Kata you might ask. A Kata, in the traditional sense, is a Japanese concept describing detailed choreographed patterns of movements practised either solo or in pairs1. In software development it is exactly that, you follow a predefined set of steps in order to solve a particular problem.

The intention is that by doing the Kata multiple times the good habit, that the Kata is describing, will be formed and becomes natural in your normal working situation. I did Uncle Bob’s Prime Factors Kata2, based on the recommendation of a colleague. And I will definitely be doing it a number of times over the next few months to enforce the TDD approach it is describing.

I have been doing “TDD” for a while now, but it is not truly TDD. I find proper TDD hard because you are required to write a failing test for a piece of code you don’t know yet. So I generally write a bit of the code, and then only start writing tests. I think I find it hard to do TDD, when writing new code, because of all the years of simply writing code, without tests, and the bad habits that have formed as a result.

I also like the it because the Kata takes what it is trying to convey beyond books. I have done plenty of reading around TDD and know all the theory, but the I have found the implementation harder than it looks when reading books and articles.

So by doing this Kata, and others, I hope to rewire my brain to undo any bad habits I have formed over the years and to start forming new habits that are more efficient and desirable when writing code.

This is definitely something that can be done whenever you have a quiet moment and are looking for some coding to do.


  1. Kata – available at
  2. Prime factors Kata – available at
Posted in Software development | Tagged , , , , | Leave a comment

Scrum alone is not the path to agility

First off, before I make a lot of people very angry with me, I just want to state that I love scrum as a project management methodology to manage work. But I believe that scrum on it’s own is not a mechanism to achieve true agility in delivering quality working software to your users.

Part of the power of Scrum is the approach to the planning of work. In the teams I have worked in, on a weekly basis we have groomed stories from the product backlog, which has been prioritised by the product owner. This allows us to have a view of the upcoming work, to discuss what needs to be done and to plan the pieces of work in the correct amount of detail.

Following on from this, scrum allows you to break up large pieces of work into manageable junks. These junks can then be delivered within a short period of time. This for me is a great benefit, because if you are delivering software every one to two weeks, even if it is into a staging environment, the team is achieving small wins often.

The product owner is also entitled to re-prioritise the product backlog in line with the changing needs of the business. This ensures that the team is always working on changes that are relevant to the business. And, because the changes are small, the team is able to adjust to the changed priorities far more rapidly than the traditional waterfall project management methodologies.

Scrum also elevates communication within the team. This is facilitated via the daily stand-ups where every member of the team has the opportunity to feedback on three aspects. Namely, what the team member did yesterday, what the team member is going to do today and does the team member face any impediments. This highlights issues early. If the same impediment is raised over consecutive days then it can get escalated or an alternate approach can be found. If a team member is stuck on a task for multiple days then a colleague can jump in to assist or alternative approaches can again be found.

So implementing an agile project management methodology, such as Scrum, is a step in the correct direction, but to become truly agile we also need to revisit our mindset around how we physically deliver software. This is where technology and practices come into the picture. In my opinion, the most important mindset shift is one towards Lean Software Development practices. By embracing Lean Software Development practices we are able to identify areas of improvement that allow us to achieve agility.

For me, a measure of a teams agility is how easily and how often they are able to deliver software that is valuable to the business and is of appropriate quality into production. To achieve this we cannot have manual regression testing, manual builds or manual deployments. The team also needs to have visibility of how changes, once deployed into production, are behaving.

To achieve this, firstly, the team must automate as much as possible. From automated unit tests to automated builds to automated acceptance testing. Secondly, the team must ensure that the infrastructure that they are deploying to supports deployments at any time of the day. This leads to a need for a level of redundancy in the production environment to allow for deployments at regular intervals, at anytime of the day and, most importantly, without impacting the clients using the system.

This requires that practices such as Test Driven Development or Behaviour Driven Development are embraced by the team as a whole. This is where, I believe, the role of testers starts to change in the team. They should no longer be manually testing systems, but should rather be assisting the developers in automating any changes that are made to the system. This frees the testers up to add input regarding quality throughout the development cycle, from analysis through to delivery.

Along with TDD or BDD by implementing Continuous Integration, the developers are getting feedback often with every check in, without having to do extensive manual testing to confirm that a change is indeed working. Once these practices are solidly in place the team can move to the ultimate delivery cadence of Continuous Delivery, where changes are deployed to production on a successful run of the automated acceptance tests. This is something I have not achieved in my career, but I am certainly striving to get to this point.

The last point that I want to discuss around achieving agility as a team, is the dev-ops movement. I am a firm believer in Werner Vogels, the Amazon CTO,  statement of “You build it, you support it”. Not only is this an incentive to maintain exceptionally high standards in the development cycle, I certainly don’t want to get woken up at all hours to support a buggy piece of code, but it also reduces the feedback cycle. The individuals making the changes are immediately aware of the impact their changes are having on the system, whether good or bad.

The dev-ops movement also eliminates the us and them problem that often arises between development and operations. And it ensures that efficiencies are achieved in the delivery of software into production. One example, that I have experienced in my development career, is the need for documents to describe each and every deployment into production. This is wasteful and should be automated, but because of the trust divide between operations and development often is not.

So if you have successfully implemented Scrum as a project management methodology in your organisation, well done. But don’t stop there, couple Scrum with Lean Software Development and Dev-Ops and you will truly start to achieve agility in delivering valuable software to your clients.

Posted in Leadership, Lean, Productivity, Software development | Tagged , , , , , , , , , , , , , , | Leave a comment

Lean Software Development Principle – Deliver Fast

As a developer, I really dislike having completed software sitting on the shelf. Possibly waiting weeks for deployment. I actually find it a bit disheartening and stressful to have complete software “gathering dust”. I want to get my completed piece of code into production as soon as possible. I want to get feedback on the usability of an approach, or whether the clients are actually using the piece of functionality I sweated over.

A developer truly only learns how their code reacts and how clients interact with their feature once it is in production. So by delivering fast, you are aiding in Amplifying learning. By delivering fast you are eliminating the potential for the perpetuation of incomplete or incorrect assumptions.

By delivering as soon as a feature is complete, any assumptions are ratified immediately. This allows for the developers to either continue on the same tack, or to change tack based on the feedback they receive. Thereby immediately eliminating any rework that could have arisen out of the incorrect assumptions.

Apart from my needs as a developer, getting code into production allows the benefits to, most importantly, accrue to the client and the organisation in a more reasonable time frame. Clients are on the receiving end of new features, that should ultimately be solving problems for them. And the business can make money, indirectly or directly, from these changes. 

Over time, requirements also inevitably change. And if they are not deployed, the requirements are changing based on assumptions of the business analysts or product owner. We want changes in requirements to come about based on feedback from the clients using the functionality in production. We want the validated learning that Eric Ries describes in his book The Lean Startup 1.

It is stated that

Changes in requirements as a percentage of the original requirements increases non-linearly as the amount of time increases. A typical 9-12 month project generates roughly a 25 percent change in requirements. However, the amount of requirements change over a month averages only 1-2 percent. And it is much easier to get users to accept waiting until next month rather than next year.2

Even though a month is still a long time to wait for a requirement to be delivered into production, a one to two percent change in requirement is a bit more tolerable than a quarter of your requirements changing over a course of the year.

In my experience, the 80:20 rule also applies to requirements. Very often 80 percent of the value is achieved by 20 percent of the features. So get the 20 percent out there quickly. Often you will find that many of the features are actually not even required. So by deploying quickly we are validating requirements and eliminating unnecessary work.

For a developer, there is nothing worse than having to support a piece of functionality when it goes into production weeks or months after it was completed. I can barely remember what I did yesterday, let alone what I did a week or a month ago. I want to get feedback immediately so that if things do go pear shaped I don’t have to dredge what I did from the back of my mind.

So, in order to achieve this, developers must have the practices and infrastructure in place to be able to deliver as often as possible into production. If you have to go through a number of steps to do a deployment, then doing one everyday is a drag. You should be able to trigger a build and deployment at the click of a button. Not only does this eliminate waste, but it also reduces risk by having a repeatable process. Humans make mistakes, machines don’t. Machines do what you tell them to do every time. And machines can do it quicker.

Developers must also be in the habit of checking in production quality code, often. If the developer is working on a large piece of work, which is not going to be complete before the next deployment, then they should be toggling their code with feature toggles. This takes effort and foresight on the part of the developer, but there are a number of benefits.

The use of feature toggles allows for the deployment of incomplete features into production. Feature toggles also allow for dark launching of features that can be switched on at a later date. There is also the added benefit of  having the capability to  “switch off” a piece of code that has recently being release if it is defective or not behaving as expected. Thus providing a “safety net” for when things inevitably do go wrong.

Delivering code into production as often as possible will eliminate the traditional, manual approach to quality assurance. As much testing as possible must be automated from automated unit tests to automated acceptance tests. Having teams of “testers” running manual regression test packs is not economically viable. Especially when you need to do this every day.

In my opinion, the role of the tester in a Lean or Agile team changes. In a traditional waterfall project testing would be a quality gate that must be ticked before moving into production. When a project is delivering at a high cadence then the role of a tester should be elevated to the start of the change to assist in the identification of missed scenarios, unit tests that need to be written or changes to automation scripts based on the change.

The culture of the organisation also needs to change to enable rapid delivery. Organisations that are very hierarchal and rely on waterfall development methodologies will battle to move towards rapid deployments. This is where a move to the DevOps model of teams really starts to bare fruit. I like this statement by Werner Vogels – “you build it, you run it”3. This approach leads to a longer term view and builds on my preference for “product teams” as opposed to “project teams”. Teams learn to work together and their decision making is directed towards the long term, rather than the duration of a project.

And obviously, agile project management methodologies are a must to be able to deliver fast. Techniques such as Scrum allow for short iterations and rapid feedback. Scrum also makes it harder to hide any incompetencies or issues. Even if the issues are not picked up in the daily stands up, the issue should not persist beyond the sprint duration.

Creating the ability to deliver fast is not something that can happen over night. There are many practices and tools that are required to be in place in order for a team to operate at its maximum cadence. Top of which are Test Driven Development, Continuos integration and Continuos Delivery in my opinion. Along with tooling and practices, the organisational culture also needs to evolve in order to enable this to happen, bureaucracy will slowly smother all good intentions to move towards delivering fast.


  1. Lean Startup – available at
  2. Lean Software Development overview – available at
  3. Operations is dead, but please don’t replace it with devops. – available at
Posted in Lean, Productivity, Software development | Tagged , , , , , , , , , , , , , | Leave a comment

Project vs Product team

When it comes to creating teams to deliver software, I believe the impact and lag of getting the team to perform optimally is underestimated. Project teams are setup for a specific goal, they work towards that goal, they deliver and then they disband. And in my experience this has the potential to have some bad consequences. You can bring the best developers together, and they will deliver, but it will not necessarily be optimal.

I believe there are two areas that project team fall short when it comes to delivering software. The first is around the team dynamic and how the team grows as individuals and performs as a unit. The second area is around the practices that are required to deliver software in a manner whereby the team is continually able to eliminate waste.

If we take Bruce Tuckmans model of Forming, Storming, Norming and Performing. Teams start out in the Forming stage, where the team members are more interested in being accepted and causing as little conflict as possible. Even though the team might be delivering, it most likely is sub-optimal.

As software developers we need feedback, and the people we get it from is our team members. In this stage we are likley to get only positive feedback and to give positive feedback. It takes time before we are comfortable giving and receiving the difficult feedback, which grows us as developers. We need to understand each other and how best to approach these difficult discussions. No developer likes to have their code critisised, and we need to learn each others temperament in order to deliver this feedback constructively.

Next the team moves into the storming phase, which is typically characterised by tension, struggle and sometimes argument. How long the team stays in this stage depends on the maturity of the team. Being able to constructively debate and argue around ideas is crucial for the delivery of good sound software. In this phase team members would be arguing strongly for their ideas in an attempt to prove their competency, possibly at the detriment of a idea of a quieter less outgoing developer.

This type or arguing is typically wasteful and the team lead must steer the team in order that the arguing does not lead to dissent. I have found that in this phase the argument often revolves around problems and not solutions, because the team members are not fully aware of the domain they are working in.

The team needs to be in a safe space where ideas are thrashed out and everyone contributes. All the pomp and ceremony of shouting loudest for ones own ideas needs to be replaced by efficient idea generation and discussion. This starts to occur when the team moves into the norming stage. During this stage the team is starting to all pull in the same direction with a common goal. They are starting to work efficiently together and they are becoming effective in delivering software. However, the leader must still be cognisant of the fact that team members might still be shying away from conflict and not debating problems to the fullest.

Finally we get to the performing phase, in this phase the leader becomes a participant and the team really performs as a unit. This is the phase that we want to keep a development team at. This not only allows team members to grow as better developers, testers or BA’s, but most importantly the team delivers software in the most efficient way that their constraints will allow them.

I have also notice that as team members come and go, the team will move between these phases. New team members bring fresh ideas and approaches that inevitably unbalance the status quo. This is a good thing, but the team leader must be aware of this and facilitate the team quickly moving back to the performing phase.

Moving away from the team dynamic I also believe that it is not in the project teams best interests to work towards a set of principles to enable continuous improvement. Unless they are working in an environment where tools such as Jenkins and Sonar are already in place there is no incentive to leave this legacy. The project team is there to deliver working software, not to ensure the future maintainability and quality of the software.

When a team is working towards long term goals, such as a product team would be, it is in their best interest to setup automated mechanisms to provide feedback that empower the team to constantly improve their software. In my experience, having something as simple as Sonar running against your code base daily and then fixing any new violations from the previous day, allows for the slow incremental improvement of software. And you experience the benefit of this over an extended period of time, not overnight.

A team revolving around a product has the prospective of performing manual tasks into perpetuity, unless they leave the team of course. A project team on the other hand has a set period after which they will move on. Therefore it is in the product teams best interest to eliminate these wasteful manual tasks and automate them.

I have just recently had the experience whereby deployments took multiple steps across multiple machines, it is now automated and deployments can be done with a single button click. This saves a developer 15 minutes for each deployment, and anyone in the team can now do a deployment. It is not a technical task anymore. We did this, not only because it is good practice, but because none of us enjoyed doing it and it would be a task that would not go away.

So, in closing, I believe that it is in an organisations best interests to have their delivery orientated around product teams, rather than creating project teams that are created to deliver a set of requirements and the then disbanded on completion. This tends towards a short term view that could lead to problems in the future.


Tuckmans stages of group development – available at:’s_stages_of_group_development

Posted in Leadership, Software development | Tagged , , , , , , , , | 3 Comments

Defect fixes – inside or outside the delivery team?

A week or so ago I went on a scrum bootcamp with my team at work. The course facilitator proposed, when asked about the disruptions that the team is exposed to for production fixes,  the pattern of having a separate team for production defect fixes. I have been thinking about this and, although there are some valid arguments for this approach,  I do not agree for the following reasons.

I feel that the development team should be striving to deliver software features that are defect free and operationally efficient in a cost effective way. The support desk and operations guys are the ones that traditionally bare the brunt of suboptimal deliverables.

If defect fixes are done outside of the delivery team, the delivery team ultimately does not experience the consequences of poor quality. If a developer is going to be woken up at all hours of the night, or spend their days fixing bugs, then I am really confident that they will spend extra effort to make sure their deliverable is defect free or come up with ways to improve the process. As developers we all want to be working on new features, not fixing defects.

If the team fixing defects is separate to the project team then the consequences for the developer are not as dire if they get it wrong. It basically becomes someone else’s problem when the code hits production, which is wrong.

I argue that, second and third line support should be the responsibility of the delivery team. If it is not, the delivery team can become separated from reality when they are not involved in investigating and fixing defects. I feel it is really important for developers to be aware of the production defects that are being logged and the types of issues that their clients are experiencing. Getting this information firsthand allows for reality to be used in future enhancements to improve the system and client experience.

This, one would argue, adds noise into the process of delivering new features and enhancements. And it most definitely will. However, if the team is motivated to do what they enjoy, that is delivering new features and enhancements, then it should only be for a short period until the issues in the process are resolved. But if the team is not involved in the second and third line support, and feeling the pain, then they will continue to deliver in the same manner and there will be no urgency to change. So the noise should only be for a short period until the team is delivering features that are defect free.

Without this type of team structure, opportunities to learn and improve are minimised. Feedback and learning are critical to enable continual improvement. Learning happens on a number of fronts from supporting defect fixes. Firstly you are getting first hand knowledge of how the system is being used and how it is performing. Secondly, it is an opportunity for the team to provide each other feedback.

The learning should lead to continuos improvement in development practices. As developers we should be continually looking for areas to improve our practice and without this type of direct feedback continual improvement is not as urgent. If defects are getting into production we need to ask ourselves why? What did we miss in our unit tests? Was there a gap in the requirements? Should we have done a code review and if we did not do a code review, why not? In my experience it has been the smallest, most inconsequential changes that often result in defects in production.

As a team after fixing a defect we should be striving to get this feedback to understand the cause and the effect. Doing the Five whys as a team is a good way to achieve this. This is an incredibly powerful tool but really difficult to implement. You need to really think outside of the box when doing a five why’s, but also it must be done in a safe space. And as a delivery team and a defect fixing team there is the chance of finger pointing. Difficult questions need to be asked, and doing one of these sessions in a hostile environment is not productive.

In closing, I am a firm believer that the team creating the new features should also be the team that is fixing the defects they create. Otherwise it simply becomes a continual circle of delivering sub-optimal code containing defects. The urgency needs to be created to change this cycle, by feeling the pain and continually striving to find out how features can be delivered that are defect free.

Posted in Software development | Tagged , , , , , , , , , , , , , , , | 1 Comment

Lean software development principle – Decide as late as possible

This is the fourth post in a series of posts on Lean Software Development. It was hardest one to write because I struggled with the differences between the Lean Startup principle of failing fast versus this principle of Delaying decisions.

The idea with this principle, is to wait until as late as possible before making a decision. This allows you to gather information during the process, by getting feedback, to make the most informed decision. The Poppendiecks state that delaying decisions is valuable because better decisions are made based on fact and not speculation, and a key strategy for delaying decisions is to build the capacity for change into the system1.

Clearly this definition eliminates the waterfall development methodology as a means to run software development projects. With waterfall big design is done up front, with all technology and functional decisions being locked into the scope of the project at the start. Compare this to Scrum as a development methodology, where the product owner and team are making decisions for short periods of time. With the shorter iterations the team is getting feedback regularly,  allowing the team to change direction often over the course of a project based in these inputs.

In Scrum, because the iterations are short, there is not as much effort been spent in a large documentation process at the beginning of the project, enabling the project team to rather provide functional and technical options to the clients. So how do I gather information and learnings to decide as late as possible?

If we take a Lean Startup approach these options could be created in the form of a Minimum Viable Product (MVP),  they could then be deployed into production to gather feedback using split testing or some form of feature toggling. We have just recently introduced feature toggling into our application and have expanded this to be more than a simple on/off switch. We now have the ability to launch features just to staff and gather feedback on the feature before launching to clients. We have as yet not used our staff toggle but the idea is that if there are any untoward consequences then we can fix and test again.

Teams should be encouraged to generate MVP’s in this way to gather feedback allowing for the informed decision making. But to do this your application must be flexible enough to allow for this.

One of the Lean Startup principles, describe by Eric Ries in his book The Lean Startup,  is the principle of “Eliminating uncertainty”. I see similarities between the Lean Startup principle of Eliminating Uncertainty and and this Lean Software Development principle of “Deciding as late as possible” and another principles of “Amplify learning“. So why do I see these principles being similar? Firstly options are being provided and decisions are being made as late as possible based on learnings, therefore eliminating uncertainty.

Deciding as late as possible is also very prudent when making infrastructure decisions. When creating a new system the first things we lock ourselves into are typically the OS, database, web servers, containers etc. As developers we should think carefully which of these infrastructural decisions we indeed have to make early.

In his talk on Clean Architecture and Design3, Bob Martin says that a good architecture is one that allows major decisions to be deferred and secondly that a good architecture maximises the number of decisions not made 4. This highlights the importance of architecting and factoring your solution properly, to be able to defer implementation decisions to when they are absolutely required. The approach that he took when creating FitNesse is a good example of using these principles.

This extract from the Complete IT Professional really sums up this principle nicely:

This principle means that there should be enough flexibility in the system and in the process to be able to make decisions later in the project. We shouldn’t need to make decisions early on that are defined by the needs of the project.

This doesn’t mean that we don’t make decisions at all. It means that using an iterative development cycle and the “amplify learning” concept, we should be able to gather requirements and facts quickly, and then make a decision, rather than deciding early without all the information we need.2

In closing, if your are cynical, you could see this principle as procrastination. However looking deeper, it is really about not locking your product or application into decisions that are costly to undo later and critically asking the question whether you truly need to make the decision now.


  1. Lean development introduction – available at
  2. Lean Software Development Principles – available at
  3. Robert C Martin(Uncle Bob) -Clean Architecture and Design-2012 – available at
  4. Robert C Martin(Uncle Bob) -Clean Architecture and Design – available at
Posted in Lean, Software development | Tagged , , , , , , , , , , , , , | Leave a comment

Why I enjoy using the Pomodoro technique

Shortly after I got back from my sabbatical at the beginning of this year, a colleague of mine introduced me to the Pomodoro technique as a method to manage my working time. Initially I was highly sceptical about working in 25 minute increments throughout the day, so it took me some time to try it out.

My typical approach to work is to sit until the job is finished. And I have a habit of sitting at my desk the whole day programming. I have the ability to sit and concentrate on work for long periods of time, which as I have found as I have gotten a bit older is rather destructive.

So I eventually gave it a try. Initially I found it a bit difficult to get into the habit of actually doing something different in the five minute break. I would just ignore the timer, or restart it immediately, or simply forget about it entirely. But with some time I got better at getting up for a walk around the building or switching windows to read something interesting on the internet for five minutes.

I was very disciplined with the Pomodoros for a few months and really enjoyed the benefits, but then somehow fell out of the habit. I think it was the change in cadence on the project I am working on, we had the big go-live and the pressure was off, so the bad habits came back. What I have found over the last few weeks is that I was becoming tired and irritable again, becoming less productive and battling to focus. So I did a bit of a retrospective to determine what had changed, and came to the conclusion that it was the Pomodoros that were missing.

There are sceptics as to the benefit of the Pomodoro technique, but below are some of the benefits that I have found while utilising this time management technique.


Although I can sit and work for long hours on end, ultimately at the end of the day I am not as effective as when I started in the morning. While utilising the Pomodoro technique, I feel almost as fresh at the end of the day as I did in the morning. I am not nearly as fatigued and my concentration seems to be improved as a result of the enforced breaks every 25 minutes.

Subconscious thinking

One might argue that taking a five minute break every 25 minutes is wasted time. What I have found is that, during my wanderings around the building, in those five minutes my mind is still working and subconsciously solving problems. I more often than not get back to my desk and I see the problem I was working on from a different angle. Prior to doing the Pomodoros I would often have “epiphanies” in the car on the way home, and I think it is a similar sort of process, whereby you are removed from the setting and your mind is subconsciously solving the problem.

One task only

Email, IM and other distractions are also not as prevalent. I typically do a couple of Pomodoros without these distractions, only one task at a time, and then at the start of the third or fourth Pomodoro I would clear out and answer any emails that need to be answered. This has been a great benefit for me in that the switching cost is eliminated and I truly focus on my task for 25 minutes. Previously, if I was finding a piece of work to be a bit tedious, it was always better to check the email that had just arrived than complete the task. So I would end up having more Work In Progress so to speak, which is very un-lean.


The best part is that I find my concentration is far better, primarily as a result of the above points. Because I am not being interupted all the time and I am giving myself a break every 25 minutes, my concentration within the 25 minute pomodoro is superior and consistent for the 25 minutes. I find that my mind does not ‘wonder’ as much as before, when I was not doing the pomodoros.

Pomodoros are not for everyone, but I think there is definitely something beneficial for those willing to try. As with everything you have to be pragmatic about it’s use. I am in the process of getting back into the habit of doing the Pomodoros again and look forward to the benefits again.

Finally, I found a great Pomodoro timer app for my iPhone, called Simple Pomodoro Timer. It is brilliant in that it has nice big numbers, it goes orange when then Pomodoro is complete and green when your break is over. So nice simple visual queues for the start and end of the pomodoro and the break, and no ticking. What I like about this is that, because I have got my phone sitting on the desk with the timer running, I can also start training my colleagues to not interrupt me when the timer is on. They would be blind to miss it.

Posted in Productivity, Software development | Tagged , , , , , | 1 Comment

Apprentice as a software developer

The notion of apprenticeship originated in the late middle ages where a master craftsman would be entitled to take on a apprentice as cheap labour, in return for food accommodation and teaching the craft to the young apprentice1. Apprenticeship was typically associated with tangible crafts such as masonry, carpentry, carvers, glass workers and ironmongery.

Although the notion of a apprentice being a form of cheap labour, being paid in food and accommodation, no longer exists,  there is still a pattern of apprenticeship in the modern day. If one looks at trades such as  plumbers, electricians and carpentry to name a few we have young people been taken on and trained in the profession. If we look at the less tangible professions such as accounting, engineering and law they have “apprenticeship” programs whereby graduates are taken on to do articles over a period of  a few years.

So what is wrong with the software development profession? Why has it taken so long for only a handful of software development companies to start seeing the value of offering an apprenticeship programme. And why should big corporates, such as banks, not be offering an apprenticeship program for newly graduated software developers? In South Africa I know of very few organisations that are offering apprenticeships for software developers, apart from where they are trying to meet empowerment quotas.

Looking back over my career, the first three to four years of my working life was really hit or miss. I came out of university and I was expected to program, which I could do. Did I learn much from my more experienced colleagues? Not really. Did anybody push me or challenge me in the way I was thinking? Not at all.

So why am I waxing lyrical about this now? Well, I have just finished reading two books, that I wish had been around when I started my development career. These two books should be in all software developers libraries. And I am sure they will become classics in the software development world.

The first one is Software Craftsmanship. Professionalism Pragmatism Pride. by Sandro Mancuso. There is no rocket science in this book but, Mancuso provides a brilliant description of what it means to be a software developer. From the importance of choosing the most suited tools, to practicing your craft, he really provides some great stories around what it means to be a software craftsman.

The second book is Apprenticeship Patterns: Guidance for Aspiring Software Craftsman by Dave Hooper and Adewale Oshineye. This book provides patterns that can be applied to your apprenticeship and again there is no rocket science here. Just some damned good advice. Almost every pattern in the book I could relate to.

As I said, I wish the books had been around 14 years ago, when I started on my journey to where I am now. The trip might have been a bit more direct, without the meanderings into management for example, and I might have taken becoming a software craftsman more seriously. But I am where I am, and all I can do now is to continue practicing the craft. But hopefully use my learnings to act as a mentor to other developers in the organisation I work in.

I like this quote from Albert Einstein 2:

Education is what remains after one has forgotten what one has learned in school.

And I feel that, as a Journeyman or Master craftsman, we need to be constantly educating ourselves. We need to build a culture of apprenticeship in the software development industry to continue and build on the education of our apprentices. I truly only started deep learning when I entered the workplace and much of what I learned at university I had to relearn over the years as I found a need for it, or realised how I could actually apply what I had learned at university.

If I had a master craftsman that I could have apprenticed under I strongly believe that my first few years as a software would have been a lot more productive and conducive to delivering quality software.

So as craftsmen, if your organisation does not already have an apprenticeship program, we should all be challenging our organisations to embrace apprenticeship and we should be putting up our hands to be mentors to junior developers, thus enabling the implementation of the patterns mentioned in Hooper and Oshineye’s book.

  1. Apprenticeship – available at
  2. Albert Einstein quote – available at
Posted in Leadership, Software development | Tagged , , , , , , | 4 Comments