I've been educating and coaching a fair share of projects in TDD and agile practices now, and in one there was a developer that decided against the harsh discipline of TDD/BDD and agile. The reason was his love for coding away at a solution, going as far with it as he could envision (which he was very good at btw).

The principle of YAGNI has to do with focusing on current needs and satisfying only them, as prioritized by the customer and/or as is evident from the backlog (xp and scrum). It's related to the well known issue of design partitioning.

On this project, we used the term or token "golden future" to claim that we were reasoning about issues that were far from where the project was. Another term that made an entrance was "deep" coding. This is used in many places to mean locking yourself up and focusing on a problem, usually also a problem that requires the dev to go deep into the underlying technology to find a solution.

Here we meant something similar, but referred to the solution space (rather than the technology/system space): To code "deep" was to take a task / user story and develop it as far as the dev could at that point in time. A spike, if you will.

My point here is that the term has a positive ring to it, in the ears of the engineer/developer. To go deep and solve something hard requires skill and means that you are doing hard and complex work.

We would probably have been better off to choose the term to code "far" or code "away". Coding far means to wander off in one direction, hoping that it is the right one. It means to never check the map or the compass until you are feel "done" and have exhausted your vision knowledge. By then you are far out in the forest, all alone.

Are you close to your destination? Or did you just spend alot of time wandering?

At the rails workshop yesterday, we got into a code readability discussion (one of programming "holy wars", i e endless debates). One thing that remains subjective is the use of comments. Since compiler optimizations give us great flexibility in how we code, I refactor intensely towards readability: Extracting helper methods, logic tests, etc - all in order to make the code almost as readable as normal english.

My take is that comments are almost a last resort, something you do when there is information that the reader needs, that the code cannot convey in a smooth manner. Essentially, I focus on making the code speak for itself, as much as I can.

Here are some articles that I liked, and a couple on c2 that are nice.

Comments are for communicating to other developers what the code does. The compiler eats simple text, yet other humans are often well served by images, and colors - hence we get color coding in our editors. Why hasn't this gotten further? I envision colorizing and straight out drawing beside the code, to augment it:

Drawing lines instead of making them with equal signs.

Custom color coding, where types can be assigned colors (I think layers) and use would show up easily as a background color, or the like.

Today, we create regions around code and insert a comment for them, why not pick a color as well? We will even more easily remember and browse the code.

Of course, I often create ad-hoc diagrams. Some I like to keep. These are for coders only - why not keep them with the code? Small diagrams, sitting right there in a comment. If word can do it, so can any modern editor, right?

Lutz Roeder (author of the .NET Reflector tool) had some thoughts in this direction, apparent from the presentations you can check on his page here.

I will be speaking at the Øredev conference in November. The conference is in Malmö and is probably the largest software developement conference in Sweden geared at professional software developers.

The session topic is modifying existing code in a reliable way by using tests to verify your work. If you are anxious about doing such work and/or are facing such work in the near future, come and get some practical ideas for how to proceed.

On the other hand, if you have already started doing such work, come along and share your experiences and tips! I (and presumably many others) will be most interested in hearing them!

The lineup at Øredev is pretty awesome this year, so if you are in the area, you really should clear out those three days in your calendar and listen in on great software development guys such as Martin Fowler, Jim Coplien, Don Syme, and a whole host of others!

A little on the level and prerequisites for my session: The topic is pretty advanced, so a fair chunk of development experience is best in order to understand the issues and solutions presented. The code will be .NET C#, and some specifics for .NET will be discussed, but the general strategies and ideas are applicable to most OO environments. My idea is not to cover TDD and/or basic testing mechanics, so an understanding of writing tests is strongly recommended. One excellent way of getting such knowledge is to attend the TDD workshop held by Martin Fowler and Erik Doernenburg on the workshop day (the day before the session).

In case you've missed it and live in the Copenhagen-Malmö area, there is a free Ruby On Rails workshop in Malmö on Sunday arranged by the cool company polarrose. Speaker is guru and rails book author David Black. Check the polarrose site for info and registration.

(or "MSBuild sucks at solutions - one simple proposal you can try")

MSbuild is a product with some great advantages, the foremost being the flawless IDE integration. However, it does have some weaknesses - one being the weak solution story.

Sample of stuff you cannot do with MSBuild without resorting to hacks:

- Theres no story for executing something just before a compile actually happens
- You cannot set up anything to happen at the end of a solution build
- The API (object model) is weak, you cannot even get a hold of the currently executing project (!).
From there on it just gets worse.

This is by design - you are not supposed to operate on the context and there seems to be no way to set up any state for the currently executing solution build.

The solution story is very weak, it generates a project in memory from the old syntax, and you cannot really access it - to set up solutionwide properties, imports, hook into the process, etc.

The general idea of having a very clear and limited interface towards tasks is naturally good, and would work if the solution story was stronger - and in line with the rest of the design. Since it is this way however, many things prove difficult to accomplish.

Ugly hack it! There have been proposed solutions using wrappers, but those are unusable in the IDE, which again really is the forté of msbuild. If we don't get IDE integration there are other solutions (SCONS, rake) that beat msbuild with one hand behind their backs. So one option is to put state into environment vars (pretty, aint it - gets that 80's smell back into the room). If you want static properties you can meddle with the files in the framework (system) directory, but in many companies that is not a tolerated option.

When confronted by a problem such as this, I usually have faith in the designers and start researching - banging my head against the wall trying to find an appropriate solution. This time was no different. Then comes the realization phase that there is actually no way forward by means of the intended uses. You step back...

My proposed solution is simple; for me the problem was essentially twofold - I wanted to be able to keep state that all projects could share over the course of a solution build, and I wanted to hook into the start and end of the solution build process. My idea: Create a singleton that stores state over the life of the appdomain and a set of tasks that allow the projects to interact with it.

1. For state there are tasks that allow you to get and set data
2. For hooks there is an initialized flag and a task to set it as you set data, and then there is a task by which you may retrieve the value of the flag.

In order to use this alternative, you are only required to put an import into each project file - which seems to be the standard and least obtrusive way of mopdifying the build process (analoguous to MSBee).

Note that this is still a hack! Why? First, it doesnt adhere to the design of MSBuild, with very clearcut interfaces between tasks, targets, etc (although, that is the problem since MSBuild is half baked, see above). Second, the end-of-solution targets are called from a destructor - which is bad (read up on who executes the destructor and how to find out why it is bad, save for the fact that it is conceptually bad). So this is at best an interim way to get things done - the first thing I could think of.

The best way to see how this works is to download the src zip, and open it up in visual studio (or just review the example test solution). It has a test solution that you can run (F5) and examine it to see how to use this little piece of code.

Please get back to me if there are bugs, improvements or maybe better/cleaner ways of accomplishing what I want.

Known issues: No logging when "end of solution" target runs.

SolutionUtilTasksSrc.zip (128.36 KB)

SolutionUtilsBin.zip (11.23 KB)

(The iteration demo)

Jim Shore has put up yet another text from his upcoming book ("The Art of Agile Development") for review on his blog. This time he talks about the iteration demo: A live demonstration of what has been accomplished during the last iteration, that can be attended by anyone that is interested. Jim describes the demo as a "way to keep the momentum going" and lists three purposes to the iteration demo: (1) Demonstrating progress, (2) keeping the team honest about progress and (3) soliciting feedback from interested parties and stakeholders.

I feel that an essential benefit of the iteration demo is how it portrays progress and instills the feeling of momentum in the team. Agile development can actually suffer from the way progress is flows in tiny increments, making it difficult for developers to perceive the speed and momentum of the progress. This may make the team feel that there is little momentum and that little happens - since everything evolves so incrementally. It's like when you watch some slow movement, such as watching clouds on a calm day, trying to discern what direction they are moving in with no fixed reference point: It is not immediately apparent.

However, to someone outside the project, the progress made over one week is obvious, since (presumably) a great deal has happened since the last reference point (the last review of the product). Again, if one were to mount a camera at the sky and take pictures at longer intervals, movement would be immediately obvious.

When an outside stakeholder reviews progress, there is commonly a strong positive reaction - "wow, all of this has been created since last time? Cool!" When developers see this emotion, it is "transferred" to them - they effectively experience the feeling of momentum and progress via the reviewers of the demonstration.

The negative effect of *not* perceiving progress and the momentum of a project is great - a project that is taking great strides forward feels successful, and causes team members to be substantially more productive. The iteration demo is a device that allows a team to get that valuable feeling and productivity.