Monday, November 21, 2011

Visualising your technical debt



For non developers:

Technical debt is an expression for the increasing level of difficulty a developer will have to introduce a desired change in the codebase. It encompasses lengthening estimates, increased unpredictability, increased number of side-effects, increased levels of developer fear, etc.
There are several reasons you might want to visualise your technical debt. I have tried to summarize them below:

  • Premise one:  You are a developer, and;
    • Parts of your code suck.
    • You don't want your code to suck as much as it does.
    • You have to convince someone that doesn't understand code to allow you to invest time in making it less sucky, or you just want to compare the suckiness of your code at two points in time.
  • Premise two: You are a code-illiterate manager who wants to know how sucky your code is.

So, how can you visualise the debt you have built up? Well, as debt is composed of various things such as the average cyclomatic complexity of your methods,  the average method length, test coverage, etc. etc. then you should be able to calculate these metrics and then combine them somehow to get some figures which you can then plot on a graph. And guess what? You can! Eric Dörnenburg has, with others, done some amazing work on Toxicity Charts and Tree Maps.
Figure 1: Example of a Tree Map. (Green is good, dark red is bad)
Figure 2: Example of a Toxicity Chart. (Short columns are good)
Using these visual aids even managers with no understanding of code can see where problem areas are in the code base and also compare the code base from one point in time to another. But they can also be useful visual aids within you team.

To find out more about these visualisation methods check out Erik's blog article and his excellent presentation of Software Quality - you know it when you see it.


Friday, November 18, 2011

What we can learn from the Swedes.

If you have your head in the clouds you'll keep tripping over pebbles. If you are only looking out for pebbles you'll lose your way. You have to watch the horizon without losing focus on here and now to make sure that you are going in the right direction without tripping over forgotten details.

The same is true in almost all aspects of software development - be it the technical development environments, the project process, documentations, testing, whatever... You have to make sure that you are not just fighting fires all the time but at the same time you can't ignore the smoldering embers you have or a fire might just break out. You have to maintain the situation while at the same time looking forwards and making sure that everything you do carries you further towards (and not away from) your goals.

Thinking about this subject reminded me of the Swedish word "lagom". As any Swede will proudly tell you this word does not have an exact translation in most other languages. It means something like: "just right", or "exactly enough, not too much nor too little." It is often used to refer to having the perfect amount of something and may be replaced by a combination of "in moderation", "in balance", "optimal" and "suitable". In software development we use the concept of lagom very often. It is, I would claim, the aim of us to be "lagom" in our planning, design, maintenance, all forms of testing and system documentation.

In nearly everything I do at work I have this concept of "lagom" to successfully steer my thinking. It is a wonderful concept and is extraordinarily helpful in everything from strategic planning to day to day operations.

And, as with all things Swedish it can be used wonderfully sarcastically such as in the phrase "lagom fun", to describe something that really wasn't that much fun at all (you can't really have too much fun).

Tuesday, November 15, 2011

Creating an #agile mindset

Mindset is a book by Carol Dweck. In it she talks about "fixed" and "growth" mindsets. These mindsets are created in childhood and affect performance and attitudes to an astonishing degree. Even organisations can possess and propagate these "mindsets".

The fixed mindset believes that our abilities are more or less fixed and we can do little to change this - some people are just more talented than others. The growth mindset believes that our abilities can be developed and grown, given the correct stimulus, and that talent can be developed over time.

These beliefs lead to two basic problem solving mindsets: The fixed mindset sees problems as opportunities to showcase one's abilities, whilst the growth mindset regards problems as opportunities to learn and grow. Needless to say people and organisations with the growth mindset consistently out-perform those with the fixed one. Luckily for us we can change our (and others) mindsets moving us (or our organisation) from a fixed to a growth mindset.

Apparently, generic praise leads to a fixed mindset, which is demotivating in the long term. According to her research, people with a fixed mindset consistently avoid more difficult tasks (when given the choice) and were even prone to lie about their performance. Non-generic praise leads instead to a growth mindset and increased performance. Unfortunately, the differences in generic and non-generic praise are subtle and mistakes are easy. In the case of children Carol gives the examples; "you are a really good painter" (an example of generic praise which will lead to a fixed mindset) and "that painting is really good" (an example of non-generic or specific praise which will lead to a growth mindset). An example for those of us in development organisations might be: instead of; "Thanks Eric, you are a great developer", we should be using; "Thanks Eric, you did a great job on that task/task x".

So, from now on I am trying to remember to give specific, non-generic, praise! (I have been trying this at home with my one year old and it's a lot harder than it seems!)

You can find out more about the book or buy it at mindsetonline.com and learn about her other project at brainology.us

Technical Excellence

Here's a very basic first introduction to the concept of Technical Excellence. It covers the basic concepts:
  • What obstacles to achieving technical excellence exist for developers. 
  • What are non-functional requirements.
  • What is technical debt, why is it bad and how can you measure and visualize it.
  • And what are the practices you can use to encourage and foster technical excellence.
Unfortunately, I tend to talk a lot in my presentations so there isn't so much text but perhaps it's a useful introduction to the subject for someone.

Here's a link to the presentation for those of you unable to see the embedded version.

Thursday, November 03, 2011

What's more important than retrospectives?

I was recently asked what I thought the most important thing was that a new team should focus on in their Scrum process. Was it the backlog? Or the sprint planning meeting? Or was it the retrospective? I thought about this for a little while and realised that these were all process-related. Yes they are important but they are still just tools. We should focus on the mechanic not her tools. People are the most important focus for a new team. As stated in the Agile Manifestos "People over Processes". Here's why:

First you need clear leadership. Not control or micro-management but leadership. The team (not to mention everyone else) has to have a clear understanding of the goals and they have to have committed to these. Commitment to some common set of goals is crucial. This commitment is, in my opinion, the single most important success factor - though I doubt if it's relevant to talk about single most important success factors for complex adaptive systems - so lets call it a critically important constraint instead. Unfortunately, this is also the one thing I see lacking most in most struggling organisations/projects. Without the inspirational leadership, necessary for forming commitment in the team, then people will only half-heartedly try to solve the problems, technical and otherwise, that will appear as time goes on. Without this leadership they will have also difficulty building/maintaining the second part necessary for commitment:

Motivation is critical for building commitment and is closely tied to leadership. But they are not the same, I have seen situations where there is a highly motivated team which totally lacks leadership. I am a great believer that people are naturally motivated to do a good job, but the presence of de-motivators can erode or even remove this intrinsic motivation. Lack of inspirational leadership erodes motivation. As does; unexplained or seemingly arbitrary decisions, poor working environments, a culture of blame, etc. etc. The list of de-motivators is long and most organisations have some of them. Luckily, often we can cope with one or two of these, it is when an organisations collects de-motivators like stamps that things begin to get ugly, and it takes far far longer to build back motivation again. I have seen two main results of demotivated teams: Either the team loses it's team spirit or, even worse, the team's loyalty to the organisation or stakeholders is lost. They begin to see themselves as somehow victims in a kind of internal organisational struggle.

Finally, if you have leadership and a motivated team, you probably have the third critically important constraint; trust. Trust is vital on a bunch of different levels; between team members, between the team and management, from management towards the team, etc. etc. Trust ensures open and honest communication, without which any project involving human beings will have a high risk of failure. Trust ensures that problems are raised, and therefore addressed, early on. Trust ensures that retrospectives are open and blameless, a prerequisite for successful retrospectives. Trust between team members is vital for the transition of a group to a team and the growth of team spirit. Trust toward management is vital in building commitment to the goals and, finally, trust from management - that the team will do their best and don't require micro-management or control, and that they should be allowed to solve their own problems - is vital in all Agile projects.

Regardless of your development method if you have these then your team will perform well. People will then have the commitment necessary to overcome obstacles and to solve problems as and when they occur. Then, and only then, it is worth investing time and energy in improving process related things such as retrospectives and planning meetings. If you don't have commitment built upon inspirational leadership, motivation and trust then no amount of trimming your Scrum meetings will make a huge difference to the success of your project.