Thoughts in the Wilderness

When I was a junior-level programmer, I felt like I had one responsibility – be good at programming.

Later in my career, once I became a lead developer, I learned that I now had another responsibility – deliver a project on time.

Still later, as a software architect I picked up another responsibility – to make it easier for the team of developers to be successful.

Today, I recognize another responsibility – deliver value to the business.

In the above chart, blue represents focus on Self, red is focus on the Team, and yellow is focus on the Business.

What does your chart look like?

In my ramblings on Values, it came to me that it is relatively easy to redefine “traditional” and “agile” project management in terms of Values.

Traditional project management has the values of “fixed budget“, “fixed scope“, “fixed delivery date“. Sure, the project manager can vary these (iron triangle), but they are the only values that traditional project management recognizes. (I know, thats an oversimplification of traditional project management).

Contrast this with agile project management. It has values of “maintainability”, “time-to-market”, and “feature prioritization”.

No wonder the two are so hard to reconcile! But that is not the point of this post.

I am proposing a new style of project management, “Value-Driven Project Management“. This new style encompasses both Agile and traditional project management – they are two subsets that focus on specific sets of values.

At the core of Value-Driven Project Management is the notion that all of the practices of project management exist only to support the values. An example is in order…

Lets consider “risk”. Traditional project management devotes large amounts of effort to risk management. This is because the values are inherently risky – “FIXED budget”, “FIXED scope”, “FIXED delivery date”. Let us contrast that with Agile project management, which has far fewer risk management tools (spikes, tracer bullets). The simple Agile risk management techniques, support the value of “time-to-market”.

There are many more values than the ones I have mentioned. Too many to mention, but consider “high initial quality”, “low development cost”, “certain set of core features”, “performance measures”. Both traditional and agile project management fall short of addressing these values. And when you ignore them, they suffer. We need to help our clients to identify and prioritize their values. Only then can we truly design appropriate project management strategies.

Once we know the values, we need to be able to pick and choose our practices in a way that supports those values. We must pick practices that will combine to provide the client with a satisfying project experience, much as a chef must pick ingredients that combine to provide a satisfying meal.

Let me bash Agile project management for a moment. I have little doubt that Agile project management is one of the most efficient strategies for delivering software (because it prioritizes features). However, it does not directly address “quality” as a Value. Because of that, it is difficult for teams to know how much of the quality practices (TDD, code reviews, automated acceptance tests, formal QA) they should be applying. All it takes is a conversation to identify the value of quality to the client (relative to other values), and then a team can motivate the quality-effort.

That brings me to the final point of this post – it is all relative. The iron triangle is an ugly and blunt tool, but it is correct in the sense that you have to choose certain values above others. That is still the nature of project management.

All developers do the following things in various proportions through the day (starting with T, for fun):

• Typing
• Thinking (design)
• Twiddling thumbs (waiting)
• Tinkering (experimenting)
• Trying (debugging)
• Talking (design, analysis)
• Testing
• Tweaking (refactoring)

Some add no direct value (Trying, Typing, Twiddling thumbs, maybe Tweaking) and some add value in moderation (the rest).

The value in this list is that you can use it to motivate the validity of various practices. For example, doing TDD will increase Typing, but it will almost eliminate Trying, significantly improve the efficiency of Thinking and do some Testing for you. For many scenarios, this means that the benefits outweigh the costs.

Filling in timesheets will increase Typing, but will not improve anything else.

Pair programming will increase Talking and Thinking, but maybe decrease Typing (only one person can type at a time).

Meditate on these, and you may achieve some enlightenment

Steve’s first law of good architecture:

Identify all core services to the application. Code against the interface of the service you wish you had, not to the implementation of the one you actually have.

Steve’s second law of good architecture:

Keep as much information as possible in an accessible, declarative form. This will eliminate duplication, and enable your software to be discarded and re-written without losing quite as much.

Corollary to Steve’s second law of good architecture:

A particular application domain is effectively solved (and no longer requires custom code) once all information about the application can be represented in declarative form.

Another Corollary Steve’s second law of good architecture:

When using a tool to generate some or all of an application, ensure that the declarative data of the tool is stored in an accessible form.

Steve’s third law of good architecture:

Usable components may evolve, but practical, re-usable components must be designed.

Corollary to Steve’s third law of good architecture:

Component re-use is only practical once you have designed an approachable, stable interface to the component.

Enlightenment Image by Sakka, licensed under Creative Commons ShareAlike version 2.5

Just doodling…What’s the most important aspect of long-term-quality software? I’ll define long-term quality software as some piece of software with a lifespan of many years, over which that software can be extended and changed to suit new needs without compromising quality.

Some potential answers, with my best spur-of-the-moment arguments:

• Strong typing – not just variable types, but any sort of type, like a database table. If something changes in the contract (field name changes, or a 1-1 relationship becomes 1-many), then I should be able to make the change and within minutes, know each of the places that are impacted in the code. The justified fear of making changes to a system is driven by the unknown impacts. If I know all of the impacts, then I am in a very strong place.
• DRY (Don’t Repeat Yourself) – If logic is represented in multiple places, then someone will only change it in one, which will automatically create some inconsistency. If you are lucky, then the inconsistency will be noticed quickly. If you are not, then you will only find out later when the damage is done.
• YAGNI (You Ain’t Gonna Need It) – Software is complex. At some point, the complexity becomes too much for us to fit in our minds at one time. The longer we can defer that point in time, the more maintainable (and learnable) the software will be. There are two distinct types of complexity though – inherent complexity (because the problem is complex) and artificial (unnecessary) complexity. By introducing functionality before we know for sure that we need it, we are creating artificial complexity. Thus, we will reach the point of too much complexity before we should have.
• Minimized Coupling – The complexity of software is directly related to how big it is. When we couple things together, we are making something more monolithic, and thus harder to understand. We also cross a line that is difficult to un-cross. (One coupling-point is just the first of many). Minimized coupling is an antidote to complexity.

I think minimized coupling is perhaps the most important, because it has such a direct impact on complexity. I looove DRY though – it is addictive once you try it in earnest. Strong-typing is of limited use without DRY. YAGNI is good advice, although some take it too far.

Are there other candidates?

One of the foundations of all Agile techniques is that of frequent iterations developing working software. I think maybe this is a developer-centric view of a deeper concept.

When we talk about iterations, what we are really trying to do is to work with a client to break down their “big goals” into smaller ones. We ask them to call these mini-goals “stories” or “backlog items”. Perhaps “goal” is a better word. Why…?

For one thing, it is less feature-attached. A backlog item or story usually translates to a feature. Maybe thats not the intention,but that is how it works out.

I’m digressing though. The main thought is that one or more iterations fulfill some client goal. This goal often corresponds with a release. That is a very concrete view of reality. Anything smaller is not meaningful to a client.

We ask them to shuffle backlog items around in order to decide which features make it into a release. What we should be asking them to do is to decide on the minimal set of functionality that meets their goal. Anything after that is meeting some other goal.

On another tangent…

When we ask developers to think in terms of backlog items and stories, we are making it too easy for them. They need to be made aware that the code they write has to work towards the client’s goals. If a “feature” can be avoided or changed by meeting the goal in another way, then the developer needs to realize that.

For example? …. The client proposes a feature. Under certain circumstances, when the user clicks the Save button, we should pop up a dialog asking them if they are sure they want to do this. They must click “Yes” to continue.

Seems like a pretty normal feature. It will make a fine backlog item. But what is the goal of the client? In this example (based on real-life), the answer was that we needed users to manually assert their intentions.

The implementation of a dialog box is a poor solution (as it almost always is). A better one was to supply a checkbox that became enabled (and required) when the right conditions occurred. Thus, the user had to pro-actively assert that they were sure this is what they wanted.

The point is this – when we tell developers to think in terms of backlog items, we are really saying “think in terms of features”. Experienced developers will intuitively sidestep this and get to the real goal. Less experienced developers will do exactly what the backlog item suggests.

If we had stated the requirement as a goal instead of a feature, then the less experienced developer would have had to suggest the details of the feature. This implies design, and thought. Exactly what we want in an Agile environment.

My last post was almost a year ago…

The reason for that was that for a while now Google’s blogger has been screwing with me – ever since they started the beta blogger service. The short version is that it was too much trouble to login to make posts. Now however, they have gone out of beta, and I can actually login again! Woohoo

The new interface is much the same, with some minor additions, such as tag support and integrated login with my Google (g-mail) account. There’s more, but I couldn’t find a link to a simple “new features” page.

(In unrelated news) I found a nice quote today:

“In preparing for battle I have always found that plans are useless, but planning is indispensable.” – Dwight D Eisenhower

Sort of relevant to Agile software development. We like to plan, but we are not bound by the plan as we would be in the older waterfall model.