Another blog about software
Archive for January 2008
Is…
The separation of user interface (screens, forms, web pages) from application logic.
My current estimate is that 1% of programmers understand the abstraction and apply it successfully.
If 100% of programmers could make this leap, then I predict software quality would improve 1000x.
Enough said.
So you develop a framework for a project, and it is great. All is good. It does what it needed to, and it does it well. Maybe a few unexpected requests come in, and you manage to incorporate them into the framework. You are very satisfied. Other people are impressed too. Co-workers on other projects start to notice, and they want to use part of your framework to make their own project easier.
Except…that part that they want to re-use has some dependencies on other parts of the framework, that they do not want. “No thanks”, they say.
Sound familiar? Perhaps you have been the co-worker, asking after the framework? Was the framework wasted? Is re-use unachievable in your organization?
The fact is, the only way that re-use has been shown to work is to “componentize”. A framework is just *too big* to do this with.
The best you can do is ensure that your framework has many individual parts, each of which has potential for re-use. Even then, coupling is a big challenge. The parts become dependent on each other (for good reason).
The missing piece of the puzzle is packaging (componentizing). Only when you do this can you truly achieve re-usability across a broad range of projects. This is not as trivial as the word “packaging” implies. There is documentation, removal (or internalizing) of dependencies, retrofitting it into the existing system, versioning and deployment. There is also the challenge of letting others know it is available.
When your co-worker came and asked you for part of your framework, the sad truth is that it was already too late. Packaging takes time, and the other project needed its answer today.
Your organization needed to be more pro-active. It needed *someone* to notice the potential of the situation, and have the time and the resources to make something of it.
Consider TDD (test-driven-development). TDD is a great design technique. It creates systems that are wonderfully decoupled. It lets you build something very quickly and effectively. It allows developers to transcend their own limitations, and results in a system that is more than the sum of its parts. Beautiful.
TDD software is an evolved work of art, beautiful like an organically grown crystal.
Compare that with a system that is designed by a software architect. Architecture is about drawing lines, and encapsulation. It is about understanding current and future needs and using that understanding to define the edges of a system, how they should interact, and which pieces should be interchangeable.
Software designed by an architect is like a piece of machinery. It has lots of moving parts, which interact in well-defined ways.
A TDD system that is under the guidance of an architect will be better than one which is not. Similarly, an architected system that is implemented using TDD will be better than one which is not. TDD and architecture are complementary techniques.
At a small scale, the distinction is not as important. For a small system, TDD can evolve something very nice, with limited architectural input. At larger scales however, someone needs to be looking at the big picture. You simply cannot evolve the design of a machine, or a house.
Getting to my point…
It bothers me that none of the Agile techniques stress the need for the role of architect. They assume that you can put together a group of equally skilled programmers and the design will evolve. This is true to an extent, but TDD and similar techniques can only take you so far. At some point, you need someone who can see the “big picture”.
In software development, a kanban board is a way of putting your todo-list (backlog) on a whiteboard using one post-it per item. I have been experimenting with my own style of kanban board for some time now. Its benefits are:
The above benefits are substantial, especially considering that the technique adds almost no overhead. It requires a short daily stand-up meeting of developers, in front of a whiteboard. It requires you to breakdown features into small, manageable chunks. If you already do Scrum, that adds zero daily overhead, and may well allow you to subtract some.
The technique works well for generalist-style teams of developers. (A team of 5 specialists working individually on separate parts of the application will not get the full benefits of the technique).
Moving on. Materials you will need:
The technique is very simple, but it has multiple dimensions. I will explain it in terms of those dimensions. First dimension deals with the flow of post-its on the whiteboard.
Each post-it will represent a system feature. For planning purposes, you should aim to size the post-its to around 2 development days, i.e. it should take a single developer no more than 2-3 days to develop the feature. That said, the technique allows larger post-its (with increased risk). Simply use a different colored post-it for features that are too large (we use pink for large, and yellow for normal). You can also mark an existing post-it with a red-X to indicate it is too large.
The whiteboard will be divided into several sections. Post-its flow from left to right and never back.
The first area is the “broader backlog”. For each planned customer-identified feature, place a post-it in this area. Large (pink) post-its are acceptable in this area.
Next is the “release planning area”. Its purpose is to group together the features that will be in the next release of the software. In order to transition to this area, large pink post-its must be discarded and replaced with smaller post-its, as much as possible. This implies some sort of planning and estimating meeting. The technique allows for variances in post-it sizes, so do not stress estimating too much. Just break it down as much as feasible. Later on you will have a measurement of estimate quality, and can use that to motivate spending more or less time estimating and planning.
For Scrum users: There is no need for the 2-day items to be customer-focused. At this point, if your client agrees, then you can break-down into technical tasks.
For each release, count and record (on the whiteboard) the initial number of post-its. We will call this the “size of the release”. Later, once we have measured velocity, we will be able to simply divide the size by the weekly velocity to reach the estimated weeks until release.
Next area of the whiteboard is the “current backlog”. This is a prioritized area where higher priority items are towards the top, and lower priority items towards the bottom. The area is limited in that there is only space for 7 items. (7 is a good starting number – you can tweak the number later). The area represents a “turnaround guarantee” to the client. We will say that the client can put anything (sized appropriately) at the top of this area, at any time, and we will have it done within X days. The X days is calculated based on the team’s velocity. For example, if the teams velocity is 1 post-it per day, then we will completely empty the current backlog (max 7 items) in 7 days. Based on this, we can guarantee (not 100%, but close) a turnaround time of 7 days.
When I said “the client can put anything” in the current backlog, I really mean *anything*. The item can be a bug, a new unforeseen feature, or whatever. It does not matter. They write it on a post-it, and put it in the current backlog.
Developers pull items from the current backlog, usually from the top (high priority) down. If possible, they should avoid pulling more than one item at a time.
Next whiteboard area is the “developer assignment area”. Each developer has a small box with their initials. When they pull an item from the backlog, they place it in their box.
Next area is the “impediment area”. When a developer cannot proceed on an item (waiting on purchase of 3rd party component for example) then they move it out of their box into the impediment area. Next to the impediment, they write the reason. While impeded, the developer stops working on the item. They can pull another item from the backlog. Impeded items are escalated as needed. Once they become unimpeded, they are moved directly back to the developer that was working on them.
When done with an item, the developer can move it to a “done” area. This is drawn like a weekly calendar, and the developer simply places the done item on the day on which it was completed. Done items stack up beneath each day (and provide a surprising sense of accomplishment).
If you have additional steps between the developer saying they are done and acceptance of “doneness”, you can add those as areas in the whiteboard. The following is important though:
And that is how the post-its flow. Pretty simple, but by itself, it does not give you much.
The next dimension is the colored stickers. Each post-it is decorated with stickers, in the following way:
The final dimension is the measurements. There are 3 measurements, taken weekly (first thing on Monday works for me). The me
asurements are all performed by counting post-its in the “done” area. Once counted, the post-its are removed from the white-board. They are:
And that’s it, in a nutshell.
Velocity is measured relative to the release planning area, which is the only way that is meaningful to a client. Use velocity directly to plan releases and choose a max size for the current backlog area.
Estimate quality is a measure of the risk of using your velocity for planning purposes. Each point was an unknown at release planning time. We did build the risk into the velocity, but a high enough value is…risky. If that is a concern, then you need to spend more effort planning and estimating.
Product Quality is a measure of how bugs are affecting your ability to implement new features. A high value means that you should put more effort into improving quality before saying something is done. This is almost always a good investment.
