Massive improvement with code snippets in this blog

I have been pretty unhappy with the way code snippets were shown in this blog. But I just stumbled upon a blog post that shows how to add syntax highlightning to them. I did it like that and added bsh and bash shell support by adding this line to the template

<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushBash.js' type='text/javascript'/> 

and the results are very nice. It works for C, Perl, Java and Ruby, too (and others I won't list here)!

I also changed the template to one that stretches to the width of the window instead of using a very narrow column for the text - something that made code lines wrap all too easily.

.. and never mind that. I'll post the code snippets to Smipple, and add their embed script instead. It's a service that is somehow connected to Google as is Blogger so hopefully they will work well together.

OSS meets Agile methods

I had an interesting revelation yesterday: there are several things in common between open source software (philosophy) and agile development methods (at least Scrum). Of course OSS in itself is pretty agile, but more as a by-product of the field rather than something by design.

Transparency. In both the aim is to be open about things. In OSS the big thing is of course that the work artifact is there for all to see and usually developers are pretty open about what they plan. In agile software development the aim is to have everyone in the project to be able to know where the project is at at any given time. In Scrum there is a host of things with this purpose: the Daily Scrums, the Burndown charts, the reviews, the whole aim of having the team sit near each other and so on.

Trust. OSS creates this by default - anyone can check the product. No hidden agendas. In Scrum trust is both delivered and expected in many layers: for the teams to work well, the managers need to trust the teams enough to give them the power to make decisions, in return they should receive accurate information on where the project is. This creates mutual trust. Teams within themselves should also trust each member, otherwise performance will suffer.

Self-organization. In open-source development people can pick and choose what they want to do and in what order. In Scrum this sort of self-organizing is also a core idea, the management should not intefere with day-to-day work. Of course commercial development usually has more constraints in what can be done, but still, to get best possible performance it's better to let the team decide on the minor details regarding job organization. Micro-management isn't very effective.

These are all, as can be seen, inter-connected. It's harder to have one without the other. And they are all very beneficial.

On top of this, the open-source has one huge advantage for Scrum teams: since the source code is freely modifyable teams and companies can modify them to fit their needs. In Scrum the idea of modifying the process, methods and tools to fit the current project as well as possible is a core idea.

Testing and Scrum

There is a small problem with Scrum when it comes to testing when a full complement of tests takes a long time. In wireless products a full set of tests can take weeks and even what you would call release tests can take days. This of course doesn't lend well to the concept of Continuous Integration when you can't run your tests even nightly, never mind after every commit. On the other hand you don't want to allow untested code to your code repository trunk so what to do?

Here's my idea, pulled from the way many Linux components do it. It assumes a version control system with fast branching and merging, incidentally Git fits this very well. The idea is to have the tree trunk as your "unstable" version. Code going to the unstable undergoes a test set that can be run quickly. When ever a release is needed / wanted, a testing branch is created. This version undergoes heavy testing and, if needed, small patches can be applied directly to this version instead of going through the unstable. If many changes are required, it's probably better to scratch this version. This shouldn't happen often if unstable testing is decent enough. But when tests pass, a stable version is created and the patches are merged back to the trunk.

This way the developers don't need to worry about anything but the trunk (of course they should still use branches when developing new features) and new features can be integrated all the time full-filling the Continuous Integration idea and staying flexible while still having the extra layer of testing required before releases are made. This creates the minimum possible amount of overhead while keeping things safe. The following figure illustrates this idea:

Error handling in Scrum

I posted a question to Stack Overflow some time ago about how to fit error handling in Scrum. I re-read the answers and the first one got me thinking and here's how I could see doing it:

There is a "Defects" task in the Product Backlog. Size is estimated by past experience or just guesstimated.

During the Sprint Planning, a new task is created in the PB, which could be called "Defects for Sprint X" (X = sprint number). The Product Owner adds items to this, team could add some etc. After all the bugs that are planned to be fixed are added to the task, the team evaluates them for the task size estimation like they do for any other tasks. This task is set to the top of the PB and normal Sprint planning resumes.

The main "Defects" task can also be updated at this point to reflect the work that will be done during this Sprint, i.e. by decreasing the size of this task. It should also be updated for any other new developments, for instance once the bugs start rolling in, the size can be adjusted. This all has the nice effect that we have an estimation of one of the things that often gets overlooked.

This way we will handle the defects like other work that has not been completely planned yet. We have a rough idea of how much work should be left for this task but we can also follow our estimations over time. It should be worrying if the "Defects" task doesn't get any smaller during the consequent Sprints. A draw a crude picture of this process to illustrate the idea:

Wiki as a more serious documentation tool

Wikis are great for creating documents collaboratively. They are easy and quick to edit by anyone and there is no overhead like you usually have with normal documentation.

But they have one fatal flaw when it comes to using them to document something: you have no way of evaluating a certain version. Because anyone can write anything, the version could simply have false information, knowlingly or unknowlingly written. This is the reason why project documentation is reviewed, people make mistakes.

This got me thinking of how to combine the best of both worlds and I quickly iterated my initial thought to something much more useful.

Initially I thought that each document could have different, per wiki selectable phases like
- "Draft": the latest version)
- "Proposed": someone thinks this is a good version and
- "Accepted": someone with the authority to say that a version is correct has done so.

Users could then choose which version of the pages they want to see. When implementing something, for instance, they might only want to look at Accepted pages.

This is advantageous, but not collaboration in the sense wikis are meant to be. Why not let the users decide which are good versions?

So my second idea was that users could vote for the correctness of each version and you could set per wiki when a document is deemed "accepted", say five votes.

This would already be a lot better idea, but why make it so strict? How about not having states at all, rather just show how many (and possibly who) has thought this version is good and letting users select their own standards of what is acceptable?

Or, better yet, combine all these and let the Wiki admins (e.g. project members) decide how to use it. Some projects might still like that certain persons check the pages because they understand the system best, i.e. democracy doesn't necessarily work while some would prefer to decide how many votes are regarded as "Accepted" and lastly some might just want to know the number of up (or down) votes.

There is still the problem of how to tell something is not right. With a normal wiki, you change the errors, but in this case you would "lose" the votes. On the other hand, this would maybe be exactly what we want - obviously the page was incorrect so people voting for it were in a sense wrong. Having down votes would still necessitate fixing the errors, so instead of voting a page down the users should just fix them.

I don't know of any wikis that have this sort of system. It would be interesting to know if someone else has had the same idea.