A case against detailed plans


While for now am not as active in the software consulting game. I have been there enough to come across the perils of overrefined plans. This issue primarily has come up as an artefact of how most westernized countries do work, through contracts.

A contract is a binding agreement between two or more persons or parties; especially :one legally enforceable

Now contracts and especially written ones are great, they have certainly played a key role in the formation of the economy as we know it. Yet their traditional use as loss prevention tools doesn’t auger very well with what we now know about software development.

What you find is the client what everything to be developed in written form and in great detail at while at it.

This is a bad idea. In this entry, let’s look at why detailed contract and detailed plans, in general, are a bad idea.

The future will likely turn out differently.

The art of predicting the future has a long and time honoured tradition of being dead wrong. Matt Nauvak has an extensive library of predictions made in the past and how they turned out.

The problem is when we think about the future, we simply imagine what we know today but in an exaggerated format. For example, the client imagines the application will have to handle thousands of query requests from sales managers who are looking to better understand their customers. This feature may be based on another plan to capture user activity within the application.

All this is well and good until we realize nobody wants to login to use the application and we now need to pivot! So there is no data to be showed on the beautiful dashboards to be used by the salespeople. Some time wasted, but still all good, the real problem comes six months later when the client once more wants their dashboard. You remind them you had a meeting and decided to pivot, they, of course, proceed to remind you meeting notes are not binding, contracts are!

I thus urge you, no matter how certain you feel about the project, bake within the agreement the provision things will change.

Decisions should be made at the last responsible moment

My personality registers as INTJ. One of our key strengths is the ability to make decisions quickly, as you already guessed it, this is also a weakness.

Plans are great because you are able to constrain the range of possible options and get everyone focused on one path. Swahili’s have a saying:

Kuishi kwingi kuona mengi

Roughly translated:

To live a long time is to see a lot of things.

This rings true in software. As your product unfolds more information comes to the foreground as assumptions get tested in the crucible of reality.

It would be terrible to ignore your insights because the plan you made one year ago is in contradiction to them.

Plans fail in highly dynamic environment

Homogeneity is great for some types of work. This tends to happen in routine types of businesses. To give an example, imagine the work of building an estate with fifty apartments all of the same design. There will likely be some surprises in the first few houses, but after that, you can make fairly detailed plans to take the remaining houses to completion.

Now imagine a software project, even if you were CTO at a successful startup say Stripe, if you then started your own business say Airbnb, you would still be encountering surprises every day. In fact, even if you stayed at Stripe, new technology say bitcoin, would still keep presenting new and surprising information.

Fighter pilots have a term I particularly like. OODA

Observe Orient Decide Act

The world changes, OODA loop makes sure we don’t stay stuck with our plans which are now irrelevant.

Avoid the trap of elegance

A common misconception is we love our children and that is why we give up so much for them. In reality, we actually love them because of all we have given up for them. Think about the concept of sunk cost fallacy.

Sunk cost fallacy: The idea that a company or organization is more likely to continue with a project if they have already invested a lot of money, time, or effort in it, even when continuing is not the best thing to do

Now, if you have ever been to a proper planning session, you know they can take entire days if not weeks. Once you have put in that kind of time, you generally don’t want to see it all go to waste. Your mind will play all kinds of tricks on you to ensure you stick to it.

Elegance is great, but as Reid Hoffman says:

If you are not embarrassed by the first version of your product, you’ve launched too late.

This is also true of plans if you put too much effort into your plans, its value is now lost.

Look through your own plans? Are any of them excessively detailed?  Talk to me in the comment section below or on my twitter @jchex




The DNA of Agile practices



Some years back, Martin Fowler and Alistar Cockburn adapted the concept of ShuHaRi from Japanese martial arts.

At its core, it’s simply a way to think about learning.

The idea is that a person passes through three stages of gaining knowledge:

  • Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
  • Ha: At this point, the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
  • Ri: Now the student isn’t learning from other people but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

From this lens, you realize the sacred cows of your own agile practice can be criticized.

Is it really necessary to have a daily standup meeting which is physical every day?

Does your Kanban board really need to have all those lanes?

Must all pairs share a keyboard in your XP practice?

In this entry, we will look past the individual features of the specific agile methods and look more broadly at what unites them, what is their DNA?

Frequent delivery

The idea that final products should well, be final is a pervasive one. It’s one thing to read all about the benefits of iteration and quite another to have your boss or client scream at you for presenting a half-baked product.

Thus we build generous timelines to protect us, to allow to do all the work needed to ensure we present the product that is just right. We know when it’s not. There will be hell to pay.

Agile adopts a more evolutionary mindset, it advocates you ship what works, for now, gain feedback and improve on the product.

This is why Scrum, for example, insists on two-week sprints. There is nothing magical about the number, its simply meant to convey you are supposed to ship something, perfection be damned what we need is working software.


You may have noticed this, the speed by which a project is executed is closely related to how well everyone understands what is to be achieved.

Simon Sinek explains the concept quite well.

If you did manage to forgive the audio quality, you got the vibe, people respond to alignment.

You see communication, especially in software development, goes much deeper than sending and receiving of signals. It took me long enough to realize you can be in a meeting speaking where everyone else is only there physically appearing to be listening to you but lost in their own world.

To properly communicate, you must be able to externalize your mental model and have the other person internalize it. This, in my opinion, is best done when you work together on a physical media, say a whiteboard or a shared doc to express what you perceive. This back and forth helps expose any incoherence in your understanding of the situation.



Thus boards and other interactive information radiators in Kanban help the teams build a shared mental model of the work to be done.

Continuous improvement

The primary school I attended had an interesting motto:

Better your best

It has taken me all this time to finally appreciate what it means.

Continuous improvement is the idea there is always something you can improve. It doesn’t matter if you are a beginner or have thirty years of experience.

Integrating this philosophy into your mindset has two advantages.

First, you never settle, your product is always going to be improving. This is in line with the more general truth of impermanence, no matter how fit the product is to its market today, the market will change tomorrow. Thus you must continue to adapt.

Second, you get the validation to ship your product imperfections and all. After all, there will be a chance to improve on it later.

In agile practices, this principle shows up in retrospectives, where the team stands back at the end of an iteration and reviews its work searching for clues on what they could have done better.

If you learn nothing else about agile, learn this three principles.

What do you think is the unifying theme of agile practices?  Talk to me in the comment section below or on my twitter @jchex



Striving for team balance



Recently, I have switched over from leading the software and design team at iHub to a new role at Twiga foods.

Just like iHub, Twiga has a great development team which I am proud to be a part of.

The big difference is that the organization is rapidly growing. In this environment, it has become critical to once more ponder the question, “What makes for a well-composed software team?”.

In this entry, we are going to go through some of my thoughts on what to consider when you have to rapidly scale your team.

Is there a right balance of junior and senior engineers?

I can’t tell you how many CTOs I have met who brag of an all-senior team. Don’t get me wrong, a senior team works much faster, gets higher quality work done. But when everyone is a senior, who is going to do the plumbing work?

Plumbing work is the necessary rote work in development. An example would be building out an email notification feature. Getting it right is simple in principle but time-consuming in practice. This kind of work would bore a senior engineer but present an exciting learning opportunity for someone greener in the field.

Junior engineers also tend to be a bit more amenable and thus more likely to fully buy into your vision.

With that said, you really don’t want a team skewed too much on the junior side. Their lack of experience means they will not see architectural land mines guaranteed to come back to bite you.

A ratio of 4 senior to 1 junior should work fairly well.

Is there someone with domain knowledge?

On paper, I learnt to drive from a driving school, in truth, I actually learnt from my uncle. One of the things he used to say was

You can only be a great driver of your own car, on the others you are at best mediocre

This statement might seem ridiculous, I mean, aren’t the control’s standard for all vehicles?

Yes, they are. But what about the time the car takes to break? Or accelerate? How has performance been fairing since the last service? In reality, you gain some knowledge of the performance of your car, something like its personality over time.

In the same way, a developer who has worked in the banking industry has some knowledge that a developer who has worked in Agri-tech just doesn’t and vice versa. You thus want in your team at least one person who has some tacit knowledge of how your industry works.

Does there exist a level of cognitive diversity?

In the current heydey of gender diversity, it’s easy to think that is all that matters. There is an even greater consideration, how do your people think through problems?

In a homogenous team, everyone comes to the same conclusion all the time. This is great for speed but it also means you lose out on creative ideas which would have possibly been a better fit for the problem at hand.

You also don’t want a team so diverse, no decisions can ever be fully agreed on. In this kinds of situations, all the energy is spent thrashing ideas which would have been better placed executing on any one of them.

Is the team cross-functional?

The most obvious question in agile, yet still worth mentioning. From a corporate level, functional teams are more legible than cross-functional ones. This means there will always be pressure to split up the team to functional roles.

Even developers do this to themselves, why do so many profiles have the tagline “PHP Developer” or “Angular Developer”? It’s because it’s so much easier to define yourself and your team by what you do rather than by what you produce.

Fight this tendency, focus on your outputs, you can better build a team that carries all the skills necessary to get the job done.

Do you have any advice for me as I embrace on this journey? Talk to me in the comment section below or on my twitter @jchex



The problem with big teams



If two are better than one, a small team is better than two then a big team is definitely better than a small one. No?

Intuitively it seems that the more people you have, the better.

For a software team, this is just not true and not because they are mostly introverts.

In the entry, what to consider when growing a software team, I hinted you should consider limiting your team size.

In this entry, I define a big team as one having more than 10 members. These kinds of teams come with their own set of challenges.

Communication over head

Have you ever tried to organize an unscheduled all hands meeting?

Getting schedules to match is almost impossible even with oversight into what is going on in the entire organization.

Now imagine an individual developer trying to get her blockers worked on in a 10+ person team!

What ends up happening is she spends most her time communicating with other people trying to get work done instead of you know, getting the actual work done!

This is not the perfect picture of effectiveness.

Individual effort lags

Maybe it’s because people feel less attached to others in big teams I am not sure. What is certain is less work gets done per person in teams.

It is natural to assume that someone else will do the work. In small teams, this assumption comes into sharp contrast. If you are not doing the work then who is?

Sluggish behaviour is likely to be more quickly noticed by the rest of the team.

As the Poppendiecks say:

Peer pressure is far more effective than the concept of a boss and much more powerful

In big teams, no one has the cranial capacity to keep up with what everyone else is doing so they just assume they are slacking off and do the same themselves.

Collective ownership goes down the drain

Just as there is individual skill, I believe there are also team skills which need to be nurtured.

When teams are large, the production line becomes the most effective way to organize work.

This is fine if your work can be broken down into small sub tasks which can be easily tested for completion.

Software projects are the antithesis of such work. To be successful it’s critical that all team members have a shared mental model of the product they are building and have a clear understanding of its value to the customer.

The negative effects of hand over will get to you before any Taylorian benefits flow.

There is no direct line between team and individual success

We are all the centre of our own universe. If I have pulled off several all nighters on a project (I don’t recommend this) then I want to see myself acknowledged when the product is launched or another similar success event happens.

If my individual effort will never be recognised anyway, then why bother putting in more effort than is expected?

In small teams, what each individual did can be clearly seen in the work output. This makes the work personal and meaningful with the effect that everyone is now more committed to it.

How big are the teams in your own organization? Talk to me in the comment section below or on my twitter @jchex



How to achieve consistent estimates



At the iHub, we work on multiple projects with multiple teams sometimes all at once. The process of software estimation is perilous at best even when there is only one team working on it.

Our situation is even more complex with individual developers serving in multiple teams and sometimes in a team of one!

Getting to consistent estimates across this various scenarios is not easy. In this entry, I will share some of the tips we have found to work in the past.

Find a common denominator

Estimates usually come in two flavours, days or story points. Ideally, estimates should always be in story points from which you derive days of work.

Unfortunately for most people, story points are just not intuitive. This means they make a great tool for establishing the work to be done but not a particularly great one for communicating the same.

Thus to establish consistency in communication, all our estimates are communicated in ideal days.

To be sure, this has come back to bite us once or twice where the client confused ideal days with calendar days but all in all the gains in shared understanding made for a worthwhile trade-off.

Review stories from similar past projects

Hofstadter’s law states:

It always takes longer than you expect, even when you take into account Hofstadter's Law.

Obviously, this is not a physical law, but you would do well to be mindful of it.

Thankfully, well measured past projects cut through our biases and reflect on us the truth.

For example, one of the more successful projects we worked on, our initial estimate was 5 months, as an e-commerce platform we were sure we understood everything related to it. In the end, it took 8 months from the first commit to a fundable version.

In current projects, we keep this hard lesson in mind as we think of the estimates we provide to clients. Particularly if a client wants a similar application, we now know how long it takes to get it done.

By having such a repository of past projects and the time it took to complete it, disparate teams can base their estimates on them and come up with consistent results.

Estimate some stories together

I expect developers to be very good at writing clean code that has a solid architecture with minimal coupling. I am however quite forgiving if they are not exactly masters of the black art of software estimation.

Still, the more estimators you have, the better. Groups will do wonders to the quality of the estimate.

Even if you will need the developers or individual teams to do their own estimates, it still makes sense to have a session where you work on it all together first.

How do you ensure consistent estimates in your organization? Talk to me in the comment section below or on my twitter @jchex



Fostering a culture of team learning



Recently, we were sharing our experiences with my friend. He mentioned a statement his boss used to tell him when he worked at craft silicon.

I would rather hire three average developers than one rockstar developer. Within six months they will have delivered more.

Obviously, this rings true to my team orientated mind.

Yet such delivery does not just happen automatically. In the same way, individuals need to learn, so do teams.

Anita et al describe why some teams are smarter than others

In this entry, I will be looking at what you can do to stimulate learning in your own developer teams.

Break down communication barriers

As companies grow, the amount of paper work grows as well. This is not necessarily a bad thing, it implies the organization is codifying its knowledge thereby reducing rework.

For example, if you are hiring 8 – 10 developers every month it probably makes a lot of sense to have the on boarding process in a document.

The problem comes when communication happens primarily via documents.

The key here is to challenge yourself not to create a policy every time something goes wrong. Policies are only useful when the situation reoccurs many times within the course of your business.

You maybe intimately aware of agile’s face to face communication principle, yet the allure of beautifully detailed dashboard is guaranteed to get to any manager.

Don’t get carried away, there is such a thing as, over collaboration, constant communication also disrupts creative work.

If you do manage to hit the balance between process and communication the next biggest challenge is to ensure the team is kept intact and members are learning each other’s vocabulary

Build whole team responsibility

I find it surprising some people deliberately pigeonhole themselves with meaningless titles; “PHP developer”, “Python developer” etc. Of what use is your language to the business?

Clients care about having their problems solved. This means everyone in the team is a problem solver first then whatever other titles they chose.

In this mindset, everyone owns the outcome, not just the tasks they are working on. This means if as an individual you do everything right but the project still failed, then you also failed!

The more everyone has been involved in everything the more responsibility they will feel towards its success.

Lynda Gratton puts it as:

    working with other people was never more exciting and exhilarating and when you knew deep in your heart that what you were jointly achieving was important and purposeful

Capture useful knowledge

Let’s start with some timeless advice from Seneca

It is the mind which is tranquil and free from care which can roam through all the stages of its life: the minds of the preoccupied, as if harnessed in a yoke, cannot turn round and look behind them. So their lives vanish into an abyss; and just as it is no use pouring any amount of liquid into a container without a bottom to catch and hold it, so it does not matter how much time we are given if there is nowhere for it to settle; it escapes through the cracks and holes of the mind.

Here he was referring to the people who waste their time. But I feel it equally applies to those who waste their experience.

Whenever you work on a project, there is always something new to learn. Maybe you just figured out the lighting in meeting room A does not allow for easy projection. How do you capture this knowledge? How do you ensure no one else does a client demo in that room? If you encounter a rare bug in one of your core libraries, what do you do about it?

Reconciliation is a useful concept in this regard. Whenever you are done with a sprint, a project or even a day. Consider what did you expect to happen vs what actually happened.

How do you foster team learning in your own organization?  Talk to me in the comment section below or on my twitter @jchex



Working with sceptics to new practises



There comes a time when you must introduce new practises or processes to your team.

Don’t expect it to be all smooth sailing, especially for well-established teams. They will question it. Unfortunately, it’s very easy to convince yourself that by virtue of your title you can push the practice and have it adopted whole heartedly

What you want to think of is the distinction between compliance and commitment.

Here are some of my suggestions for working with your sceptics.

Let them see the benefits

It’s bad enough you are introducing a new system for them to use it better work!

In leadership, it’s easy to assume what you know is correct and others are wrong. This dangerous assumption means you push practices that have no other value besides inflating your own ego.

If the practice is beneficial, then let the people see it. By adopting the practice, you should be able to show them via anecdotal evidence of its success and how it benefits them.

Provide training

The knowledge that is painfully obvious to you is likely foreign and unintuitive to your team.

Hanlon’s razor captures it beautifully:

Don't assume bad intentions over neglect and misunderstanding.

Training can be very useful in this respect, by running even an hour session with the team showing them how the process is done, you can make a lot of headway in getting them to adopt it.

Celebrate vocal sceptics

There is always that thorn to your flesh. The individual who is very vocal about your changes and how stupid they are.

The natural human reaction to such hostility is to close them out or attack them.

I suggest you instead keep an open mind and assume the individual is questioning the methods not you as an individual.

As such, invite them to all relevant process improvement sessions, let them air their views. Genuinely take them into consideration and address what can be addressed.

Hopefully, they can become your champions, if not, then maybe they can disagree but commit.

Have Backbone; Disagree and Commit. “Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.”

    ~ Jeff Bezos

Challenge them to do their best so that they can prove you wrong

All processes introduce a level of drag into the system, in effect what was getting done, gets done slower. The benefit usually lies in improved quality and less rework.

That’s of course if your process is a good one, there is always the chance you are wrong and unnecessarily burdening your team.

So teach the team the easiest way to shove it in your face is to do their best at this new practice and if no benefit accrues, you will be forced to reconsider.

While obviously a dangerous move, they can choose sabotage, if it works it will provide compelling evidence, enough to move them from compliance to commitment.

Show don’t tell

This is a particularly useful heuristic in many areas of life including the change in the process.

One of the great commandments of science is:

Mistrust arguments from authority

You want your team constantly engaged in a constructive disagreement with you, that’s how you get the most creative ideas out of them. If they become “yes men” your innovation capacity effectively shrinks to just one person, you.

By allowing for disagreement you then have the chance to show your new method will be of benefit to the organization of which you are all part of.

How do you introduce new practices in your own organization? Talk to me in the comment section below or on my twitter @jchex



On becoming a software engineer


About a week before this writing, I got an email from my friend. She asked, “How do I get to be good in Python before my interview next week?”

This is not an isolated question, with all the hype the field has been getting over the past years, it has created an illusion within the general populace that it’s easy to become a master engineer.

By consuming media through computers over many years, many have been disillusioned into seeing their familiarity with software products as wisdom into how they work.

Still, just like any other discipline, software engineering can be mastered using time tested techniques.

In this entry, we shall look at what I believe is a viable path towards becoming a master.

Make the big decision to make the smaller decisions

The common misconception is big decisions matter more than small ones. Thus the new year’s resolutions list or the strategic decision making seminar.

In practice, it is the small decisions which are the hardest and the ones that matter the most.

Deciding you want to learn how to code is easy, deciding this Friday evening you will not go out with your friends or watch Netflix but will instead wrangle with design patterns is the hard one.

Find a way to get feedback

The easiest person to lie to is yourself. Have you ever met an individual who first saw an IDE two months ago and today they call themselves senior developers? Well, I have. They are not even lying, they absolutely believe this to be the truth.

The problem this individual faces is they have no idea how they compare to everyone else or what the industry demands of an engineer.

If you can make it through the first arduous days and weeks of programming, it’s very possible for you to be able to hack a semblance of an application. This does not mean you have a programming product.

Brooks explains:

This is a program that can be run,tested, repaired, and extended by anybody. It is usable in many operating environments, for many sets of data. To become a generally usable programming product, a program must be written in a generalized fashion. In particular the range and form of inputs must be generalized as much as the basic algorithm will reasonably allow. Then the program must be thoroughly tested, so that it can be depended upon.

To grow then you must push yourself to work with others, to put your code out there in the world to be scrutinised by others, I assure you, it will make you better.

Build it into your identity

There is no done. The field is so wide, even if you dedicated every single waking hour to consuming the literature available, you would die before you had it all.

Is this discouraging news? I would like to think not, it means your life will never lack purpose. It means every day there is a chance to experience the subtle joy that arises when you learn something new.

Thus you must commit yourself to becoming an engineer, to continuously grow and learn. Becoming better needs to become a natural part of your life just like say eating or breathing. Have you ever met someone who is now a master of breath and now no longer needs to breathe?

Where are you on your path to mastery? Talk to me in the comment section below or on my twitter @jchex


What to consider when growing a software team

A few weeks ago, we had the chance to do Myers-brigs at our office. As it turns out I am an INTJ. You can find your own type on this site human-metrics.

As a base rule, mixing individuals from different personality types leads to better creativity albeit at the expense of efficiency.

Developers, in particular, have an even more nuanced environment. Fred Brooks famously said:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures....

This means as you grow your team, there are certain things to look out for. In this entry, we will be exploring the factors I think are the most important.

Does the team structure compliment individual’s strengths?

We perform best from a position of strength, yet somehow team leaders assign individuals to tasks optimised for the organisation rather than for the individual’s strength.

A simple test such as the MBTI can help you easily see who would work best with who.

As Wegner proposed in 1985 the greater intelligence born of the group mind which comes about from great collaboration is guaranteed to benefit your organisation.

Is anyone multitasking?

Human’s can not multitask. The illusion feels so powerful that the team leads don’t even need to push this agenda, the developers will take it upon themselves to do it!

Despite numerous studies, including this one Who Multi-Tasks and Why? Multi-Tasking Ability, Perceived Multi-Tasking Ability, Impulsivity, and Sensation Seeking we still assign developers to multiple projects.

Two projects are optimal for an individual developer, in this way, they can switch to a different task to give their mind a break and some room to chew on the project. Anything more is likely to lead to reduced productivity as the mind becomes too clouded.

Have you limited the team size?

We have limited cognitive ability in terms of the number of individuals we can maintain in our circle. Known as Dunbar’s number, it is shown we can actively keep at most 150 active social contacts.

I believe working groups are even smaller. Once the team size gets to more than 5, communication issues start sipping in. It becomes that much harder for the team to build and maintain a shared mental model.

Mike Cohn has an even simpler rule, no team should be so big it can’t be adequately fed by two pizzas!

What is the team’s purpose?

Shortly after joining Moringa, I was having problems getting the team to work together let alone towards any goal. I explained my dilemma to the CEO. She asked me, “Have you carried out a values exercise?”.

This question changed how I think about teams, yes we can impose what we want to the team, but the team just like any other complex system will work towards its own goals.

The only way to get your team to succeed is to imbue them with a sense of purpose which aligns with the organisation.

Can the team deliver the product from end to end?

A basic tenet of the scrum and agile methodologies, in general, is the concept of the cross functional team. The simplest definition I could find of such a team was:

A cross-functional team is a group of people with different functional expertise working toward a common goal.

Cross functional teams are the killer feature of agile. They bring about diverse views to the teams enabling good ideas to be quickly tested, built and shipped.

How long do the teams stay together?

In a previous entry, Stop killing your teams now! we discussed the tragic fate of most teams.

I believe now as I believe then, teams should be built for the long term. Like the tired cliche of the good wine, good teams get better as they mature.

How do you grow teams in your own organisation?


Core technical practises for your scrum team


Scrum is a fast moving development style. There is obviously a lot of advantage to this, but just like a sports car needs a better technical design to function at top notch, so does your code.

In this entry, we will be looking at the top three technical practices that you must adopt to ensure you are moving as fast as you could be.

Test driven development

A few days ago, our team was faced with the challenge of stress testing one of our applications. One particular use case proved particularly hard to do, the only way to run it was to literally have an actual human run through the steps!

This might be fair if we were doing UX testing, but in this case, it proved to be a big red warning sign on our architecture.

We have since worked to correct our process, but the point here is TDD helps you unravel problems before they become Problems.

By writing the test first then the code, you are forced to think through what it is you actually want to do. This makes your code clearer as well.

Not to mention, by having a “second opinion” on the validity of your code, you can deploy far faster knowing another system is checking the integrity of the entire product.

Continuous improvement

If you have ever struggled with your weight, I am certain this thought has ever come up in your mind at one point or another

Let me just eat this burger, I will work it all out later in the gym

A fantastically bad idea! Not because you will procrastinate later and not visit the gym, thou this is likely, but because you essentially threw a good chance of working towards your goal and worse compromised your future self.

In the same way, almost every day you jump into your code, you will come across an opportunity for improvement perhaps a better design pattern to adopt or even just to maximise on an opportunity to reuse code. Here you have the choice of either saying you will just do a patch now and fix it in the future or just fixing it now.

The formal term for it is refactoring and there is a wealth of knowledge out there on how to do it.

By continuously improving your code, not only will your code not rot but you will have code that gets better with age.

Collective ownership

Open source software tends to be of a much higher quality than propriety code.

We all care more about what we know someone else will look at than what we are sure only our eyes will see.

The long and short of it is you want as many eyeballs on your code as possible. Obviously open sourcing your code may not be the ideal solution, but what about having your team members work on the code together?

There shouldn’t be a part fully designated to only one developer, this gives you two key advantages:

  1. Not everything goes to hell if the developer goes on holiday
  2. Everyone cleans up their code just a bit better

Continuous delivery

In 2001, Paul Graham wrote one of the most prescient essays I have ever come across, it is titled The Other Road Ahead.

One of his key arguments revolves around the fact that faster code-test-deploy cycles lead to higher quality code.

I fully agree with this argument. Continuous delivery is guaranteed to significantly reduce if not eliminate the stress which comes naturally with software development.

No longer will demo day be a day of panic. For all intents and purposes, it will just be another day in the life of the boss developer.

I hope these pointers will help you towards a better scrum experience.

Which practices here do you use in your own practice?