Christopher Johnston

Category: Uncategorized

  • Chris’ First Rule of Software Development

    Chris’ First Rule of Software Development

    I once worked with a team that, for some reason, valued complexity. It seemed like their egos were tied directly to how hard something was to do. If something was hard and they completed it then that proved that they were smart 🤷‍♂️? I tried multiple times to introduce the idea of simplicity to them, but it never stuck.

    In response to the above, I developed a simple rule that I follow and I tell every team I work with and every engineer that I teach and it is:

    “If what you are doing is getting more and more complicated, then you are heading down the wrong path. Conversely, if what you are doing is getting simpler, then you are probably headed in the right direction.”

    Me

    That’s it. If what you are doing is hard, then stop, think, maybe backup and figure out what you’re missing. However, if what you are doing is simple, easy to reason about, and straight forward, then keep going.

    You will notice that the complicated path is phrased as an absolute whereas the simple path is less certain. That is because we have to take into account that

    “For every complex problem there is an answer that is clear, simple, and wrong.“

    H. L. Mencken

    Thankfully, the opposite is also true. There is a solution that is clear, simple, and correct. And, as engineers, this is the solution that we should be constantly aiming for.

    In everything we work on there are two kinds of complexity; Inherent Complexity and Accidental Complexity.

    Inherent Complexity

    This is the complexity that is part of the problem. Think calculating compound interest. There is nothing that can be done to simplify the calculation, it is just complex. However, we can still isolate that complexity, trim it down, and find the simplest form of it to initially implement.

    Accidental Complexity

    This is the complexity that we as developers introduce to the code base by not taking time to refactor or problem understand the problem we are trying to solve. We go for the easiest implementation, shove the new code into place and then call the problem solved. And we don’t take the time to be professionals. I always use the analogy that this is like going to the doctor and finding out that they couldn’t be bothered to sterilize their instruments before seeing you.

    This idea of simple is reinforced by the second rule of Test-Driven Development (TDD). Get the test to pass by implementing the simplest thing that will work. And by the third step of refactoring. If we make a mess, we also need to take the time to clean it up. We need to pride ourselves on the simplicity of our solutions and not how hard it was to implement. This isn’t to say that refactoring is simple.

    “…for each desired change, make the change easy (warning: this may be hard), then make the easy change”

    Kent Beck

  • What is Agile?

    It’s been more than 20 years since a group of software professionals got together and created the Manifesto for Agile Software Development. And yet, I think this question is still just as valid today as it was in 2001. Most people think “Agile” is about daily stand ups, pairing, TDD and the like. They think it is about the processes and rituals that development teams practice on a daily or weekly basis. However, these practices represent XP (Extreme Programming) or Scrum and not Agile Software Development. So if Agile is not about practices, what is it.

    The reality of the manifesto is twofold: 1) it was a reaction to waterfall and 2) it represents the only points that the people that created it could agree on. Each of the signatories of the manifesto went to Snowbird with different ideas, different processes, and different theories on how to create software better and in the end, the four points in the manifesto really represent the intersection of all those ideas.

    We can get a hint about what the manifesto is about by looking at the words, or word, used. In particular, “Agile”. What is agility? According to the Oxford dictionary, Agile, or Agility, is the “[ability] to move quickly and easily.” This is important. The Manifesto is about moving quickly and easily. It’s not the Manifesto for planning software development or the manifesto for ritualistic software development, it’s the Manifesto for Agile Software Development.

    Let’s look at another definition; “ability to think and understand quickly.” At the heart of both of these is the idea of change. Changing easily and quickly in response to some stimuli. It means changing course, focus, ideas, visions, and most importantly, plans.

    I would posit that planning and agility are antithetical to one another. If you have plans, you have rigidity. You have ideas that cannot change. If you have a 3 or 6 or 12 month plan for features that have to be, or should be, released and ROI calculated on those features, etc., you don’t have Agility. Therefore, in order to be Agile and follow the ideas in the Manifesto, you can’t have plans. The question I know many are asking is how do you develop software without a plan.

    Simple; you develop software through feedback. Remember, a aspect of Agility is the ability to respond quickly. But to respond to what; shareholders, stakeholders, customers, user research, etc.? Yes to all of the above. The basic idea here is that you create an MVP (Minimal Viable Product), release that into the wild, and respond to the feedback that you get. And by MVP, I don’t mean something that you take months to create. This should be something that is created as quickly as possible and then released to see how it fairs. This is an experiment.

    At the heart of Agile Software Development is the idea of generating experiments and see how they do. Some will fail, some will succeed quickly and then plateau, and some will get adopted slowly and then take off. But at the heart of all the experiments is the fact that you now have data. You have experiences and anecdotes and stories that can be used to refine the original idea and make it better. And best of all, you have spent as little money as possible. Instead of waiting for 12 months and releasing something that is perfect only to watch it fail, you can release an idea, gather feedback, and ensure it will succeed by slowly developing it according to what your users really need.

    At the heart of the Manifesto is the idea of eliminating guesswork, “well I guess we need Y in 12 months, or we hope their will be a market for Z in 2 years” and instead, releasing software by knowing exactly what you got right, what you got wrong, and what amplifying the former and reducing the later. Guesswork and hope is replaced with data and the ability to respond quickly to that data.

    That is what Agile is.

Copyrighted Image