NDC 2010 was great. This post is inspired by Tom Gilbs ”Lean quality assurance” talk:

Often we set out to build high quality software without really considering what that entails. How can you really know, when project has finished, that you have created quality software?

Clean code, test coverage and executable specifications created iteratively together with the primary stakeholders seem to be the main focus for most agile projects, at least, in agile theory. There are other concerns that can easily be overlooked when people go into “agile mode”.

Numeric entry and exit

As a stakeholder in a project you don’t really care about testing and executable specifications. You care about the ilities. Usability, Maintainability, Reliability, Security and Scalability are some that come to mind.  Often requirements emerge as the software is developed, but many of these are well known in advance, at least to the stakeholders.

How can we identify these requirements and ensure that they are met at the end of the project? 

A coder will leave it to chance. A software engineer will measure and verify that the requirements are met.

To identify the requirements you first need to identify the stakeholders. This is a process in its own right. Later you can start identifying the requirements. 

According to Tom Gilb you can measure *any* requirement numerically. Later in the process you can use these numbers to evaluate the quality of the software (or some other item) you are producing. A requirement is considered done when your software meets the numeric target for that requirement.   “Numeric entry and exit” is a term that describes this way of thinking.

How can you measure things like usability of a feature? The answer is obviously “it depends”. One metric can be the percentage of grandmothers that understand the feature on the first try. If 80% get it, you have a usable product, and you have met your target for that specific requirement.

Obviously dissecting your requirements this way requires a lot of time and effort. For some projects doing it this way makes no sense, for some it’s too cumbersome and expensive, and for some it totally makes sense.

You get what you measure

Later.

Comments F Share

In software development we often end up with local optimization. Developers focus on getting the development work done, testers focus on getting the testing done, and the analysis team focus on getting their work done. This is a problem, because local optimizations does not optimize the whole.

The development process should be optimized for global productivity. Work should flow thru the development pipeline without batches of work accumulating within the pipeline.

In the following diagram imagine the work flowing from left to right. First it enters the analysis team, then it’s developed, then tested, then finally it is delivered to the customer. A work item is indicated using the letter “x”.

This shows a situation where the testers are a accumulating work because they cannot process all the work the developers are handing over. Notice every team is working with top efficiency. This way of working introduces problems.

Problems caused by large batches

What are these problems we are creating ? If you look  at the entire development process as a queue of work going from left to right, you will see that more work in process creates a longer queue. A longer queue means that the time it takes for one item of work to pass thru the entire queue is longer. This means that the delivery time of our software increases ! When work in progress increases, the delivery time increases. This is obviously a problem for many reasons that I will not go into right now.

There are other problems with the above work flow as well. Developers continue developing before their previous work is validated by the testing team. This means that they are creating work based on possible false assumptions. When this propagates thru the system it creates even more problems.

Limit the work in progress

The key is to limit the work in progress. In the previous scenario the testing stage of the software development process is the bottleneck. To avoid the accumulation of work in progress we need to increase the thruput in the test team, or lower the rate at which work is arriving. One solution could be to move some of the developers over to the testing team. Another would be to slow down the work upstream (to the left) of the test team, by giving the craftsmen there some “slack”.

Having people not doing the work they should be doing is often a problem for managers. They measure success by how efficient their  team is. Suddenly we are back to local optimization. Having slack is actually a good thing. In the right enviroment it creates opportunities for learning and innovation.

In rigid  functional teams, it is hard to do anything to modify the flow. People are happy with local optimization. In cross-functional teams it is easier to modify the process to accommodate the flow.

Some additional thoughts

1) It is easy to think of work in an software organisation as small items of work flowing thru the pipeline. In reality the work items varies in size as they flow thru the pipe. Also the issue of rework puts a little brake on the happy path. Keep this in mind as you take your next steps to improve the flow :)

2) There are things to be said about having the testing team upstream from the development team and making the batches of work smaller. That’s something for another post.

3) Focusing only on the work in progress withouth thinking about keeping the team members happy from a social point of view is a good way to fail in the long term.

Feel free to comment :)

Inspired by:
Kanban Chalk-Talk  (http://vimeo.com/7814701)

Comments F Share

We (the team) just had a chat about some ideas we should follow when it comes to source control and code ownership. Here is a short summary.

Code ownership

”Shared code ownership: ” To ensure that more than one person is familiar with a certain part of the code base we have shared code ownership. This will make the team more flexible, and making change easier. It is always allowed to refactor code to make it better. It is actually required to prevent the code base from deteriorating over time. That said, there might be people who knows more about the code base than you do. Also, somebody else might be working with the code right now. ”Consult before making radical change.” Communication is always important.

Check in

”Check in early, check in often: ” The code is what is in source control, not what is on your computer. By keeping the code in isolation on your computer you are setting yourself (and the team) up for big trouble. By updating(first) and checking in (second) often, you prevent merging and communication problems. Partition your current work into sub problems, and check in when each feature is created or updated. Work on one problem at a time. If you find yourself working on 10 features, where each one is impossible to check in, you are doing it wrong. It’s a code management anti-pattern. The philosophy behind this is simple. Problems are easier to fix right after they occur. In a day, or a week, solving the problem becomes exponentially harder. Considering this philosophy, keeping the code on your machine to avoid problems MAKES NO SENSE !

”If the code isn’t checked into source control, it doesn’t exist”

Write tests

Write tests for the expected behaviour and your usage of the code. This will ensure that new features and refactoring is compatible with existing usage.

Standard

“Standard” is what we do right now (or should do). The standard can be changed as we find better ways to solve our problems. However, we should all follow the current standard.

Comments F Share

The other day when I was up in the mountains in my cabin, I suddenly started thinking about development processes and rapid feedback loops.  I sat down to write about it, and here is the result:

There is a saying “culture eats strategy for breakfast”.  It’s true. I have seen it in action.

Introducing a new process often requires changing the culture in the company. This is hard or impossible. Radical change creates too much friction. Working with the existing process and modifying it slowly is the most feasible route.  Identify your goals and see how you can slowly modify your existing process to achieve the goals.

Let assume that building software faster and with better quality is a good idea in your context. It usually is.  Let’s say this is our goal, assuming that it in the end will lead to more profitability.

I firmly believe that to create maintainable software there is one term that is more powerful than all others. That term is rapid feedback loops (RFL). Rapid feedback loops is the common denominator of all agile processes. The only process I know of where RFL is not a central concept, is the waterfall model.  It is not the details of the agile processes that make them succeed. It is the fact that they all embrace rapid feedback.

Test driven development tells us every minute if our code works. Continuous integration tells if our code is working in the bigger picture. Integration tests checks whether we are fulfilling the product requirements. Periodical demonstrations and conversations with our customers tell us if we are building the right product. It’s all about getting feedback. If you are writing bad code, or creating the wrong features, feedback nudges you back on the right track. Design reviews can prevent architectural erosion. You need feedback as soon as possible so that you don’t waste time working on the wrong thing. Working on the wrong thing is expensive.

Feedback is a good thing if the feedback you are getting is correct. If it’s not you have a problem. We can usually trust well written unit tests. Integration tests are harder, because they are only correct if they are actually testing a feature we need in the end product.  We need to constantly check with our customer that we are on the right track. The customer might be wrong, so we re-check on a continuous basis.

If you want to improve your current process you should start looking at your feedback loops. Slowly introduce feedback on all levels. You don’t need to pick Scrum, XP, RUP, Lean, Kanban, Crystal Clear or ScrumBut. However, you should know roughly what they are about. This way you can pick from a toolbox of practices and make them fit into your existing culture.

I don’t believe in picking an out of the box process if it will crash with your current company culture. However I really do believe in feedback loops and you should introduce them slowly into your current process. There is obliviously more to creating a smooth software machine, but feedback is a key concept.

Peace.

Comments F Share

Building software requires people with a certain skill set. To build a successful product you need a person with a clear vision of where the product is going. This person is the most important member of the team. Without him (or her) you will not be successful. This person, the champion, can guide the development towards the goal. The champion knows what features to include and what features not to include in the product. His clear vision will stop feature creep and lengthy unproductive discussions. The champion listens to others but has the final word. Democracy is not the way to go if you want to build remarkable software.

Developing a quality product is difficult, and a champion is only one piece of the puzzle. To build a great software product, you need great software. You won’t fool anybody by putting lipstick on a pig. This is a key aspect missed by a lot of companies.

To build great  software you need a person who knows how to build software. It sounds obvious doesn’t it ? This person, let’s call him a developer lead, should be responsible for the development team.  He is responsible for ensuring that sound software engineering practices are followed throughout the project and that the software quality is up to par. This is not a simple job.

Ideally the champion and the developer lead is the same person. The reason is simple: Communication. Communicating the vision  is hard, and fewer people means simpler communication. If you want to develop software effectively you need to make trade-offs between the features you would like to have and the time it takes to implement them. Often you can make small adjustments to your requirements and gain a lot in terms of development time and better technical solutions. This translates to faster time to marked and eventually more revenue. Identifying these trade-offs are difficult, but if the champion knows the technical aspects of software development this problem disappears.

Having one person doing the work of a champion and a developer lead can be a recipe for failure if this one person fails at any of the two roles. A common mistake is to put a domain expert to the task of leading the development team, and thinking that if you put enough developers on the team the software will build itself.

I have seen many products become mediocre due to the lack of a champion or a dev. lead. The roles need not be explicit, but they need to be present in the team in some form.

What kind of people do you think is required to develop remarkable software ?

Comments F Share

I my last posts I have been talking about DDD and the CQRS Architecture. There are certainly situations where the CQRS Architecture would be a good solution form a theoretical point of view. I know from experience that rolling the best suitable architecture is not always the way to go.  We need to consider the people as well. It is really dependent on the culture in the company if a “new” architecture can be rolled out.

Company culture

In some companies being a craftsman is valued. You are working in an environment where creating unreadable code will get you in trouble and major design decisions are well thought thru.  There’s process, there’s design and there’s coding. The goal is to create code that can be maintained over time and at the same time meeting the needs of the business.

In other companies there is chaos. The recognition that software needs to be built with care does not exist. The goal is to create the next feature without any thought of the maintenance hell you will experience in the future. The developer who implements the next feature in the shortest amount of time is the one who gets rewarded. Spending time creating SOLID software with well proven development practices is not valued.

I’m painting a black and white picture here, and as we all know, the world is grey :) Now, let me continue my rant.

Both these companies can grow and gain marked share. If you are in a marked where you have monopoly, or are one among a few you can keep delivering mediocre software and still be in business. If you are in the “chaos company” category you will start seeing problems when competitors starts entering your marked or when you just can’t deliver more features in reasonable time. Suddenly you are dealing with crappy software, unmotivated developers and a bad business.  Not a good place to be if you are in the business of making software.

The best design decicions are not always the best design decisions.

Back to my original thought. Yes. I was planning to advice you not to apply the CQRS Architecture, or any architecture that requires a certain amount of thought in companies following the chaos model. You will probably cause more problems than you solve. You need to be able to control your environment to roll these kinds of solutions. Eric Evans talks about creating bubbles of quality software in your organization. These kinds of bubbles burst quickly if you are in the wrong company. In other companies a bubble is a viable solution.

Introducing new ideas in a company must be done with care and the first thing you need to consider is the people and the culture, not the best design from a technical perspective.

…and that was todays rant.  Makes sense ?  Hit me with a comment :)

Comments F Share