Coding Notes

Ars Technica recently posted an article on Mozilla’s future version of Firefox.  This version, deemed Namaroka, is the version of the web browser that will be released after Firefox version 3.5, which is currently in beta.  In the article Ars Thechnica talks about the various features of version 3.5 and the upcoming features of the Namaroka release.  As part of the documentation for Namaroka Mozilla has put out a roadmap documenting the various goals and specific features of the release.

Many of the open source software that I keep an eye on include roadmaps in their external development documents, however I have read very little about the idea of creating roadmaps as tools for development. Part of the reason for this may be that what I have read just refers to roadmaps differently, or I haven’t read enough, or possibly that roadmaps counteract the ideas of agile development. Since there seems to be a lack of input on the subject, I thought I would examine some roadmaps and look at their purpose in Software Development.

Songbird’s Roadmap:

If you haven’t been introduced to songbird I highly suggest you check it out, it is an excellent media player built on Mozilla’s software that allows you to both play and store you’re music as well as explore the web in a musical context. They have published roadmap’s up to and after their release of their non-beta software (currently version 1.1), you can find them here: http://wiki.songbirdnest.com/Roadmap. Songbird appears to use their roadmaps as a way of tracking the progress of various large objectives of upcoming releases of their software. They also allow the community to interact with it via comments and the fact that it is in a wiki.

Songbirds roadmap seems to be a resource for the community to see what the development time is being spent on and how far things are coming along. Internally I would assume that it is used in much the same way, a way to track the progress of large objectives as well as pinpointing what the large objectives are.

The Wordpress Roadmap:

You can find Wordpress roadmaps here: http://wordpress.org/about/roadmap/.  Wordpress is an open source blogging platform (I use it for Coding Notes). Wordpress seems to use their roadmaps in a much more specific way than what Mozilla or Songbird does, Wordpress utilizes a ticket system to track the progress of and allow developer involvement in the process of dealing with issues that need to be tackled for certain release “milestones” or versions. As a result there are far more and much more specific items being taken care of on the roadmap, and the entire roadmap as a whole looks much more like an internal document than an external overview of whats going on.

The pro’s of this approach are that the community can get a much more specific view of the changes that are being made, and can perhaps have a more beneficial involvement in the large scale development process. The con is that naturally it is harder to see the overall picture. However by looking at the number of open tickets and closed tickets one can get a very basic picture of the progress (as of this writing for the 2.8 release it stands at: 271 closed tickets out of a total 762 tickets).

Mozilla’s Namaroka Roadmap:

The Namaroka Roadmap can be found here: https://wiki.mozilla.org/Firefox/Namoroka. While Ars Technica calls it a roadmap, Mozilla does not use that name but it is very much the style of a roadmap. Like Songbird’s roadmaps the Namaroka roadmap is a broader overview of the development that needs to take place. However, it differs significantly from the other roadmaps by providing multiple perspectives on what needs to be accomplished for the Namaroka release. What I mean by this is that they have provided multiple sections, a broad overview of goals, a rough timeline of when different items should be completed, and various areas of interest and requirements plus others. This allows for multiple perspectives to be taken on the same things. They don’t provide a way to see what is completed or in progress however, but the document is in a wiki so as the items are accomplished perhaps the document will change. Also like songbird they invite community involvement via a discussion section.

Personal Experience, a basic roadmap from my Senior Project

While I was completing my senior project my team developed a basic roadmap; it was meant mainly as a rough diagram of what needed to be done and a time line of when we could expect things to be finished. However, since we where following a win-win spiral lifecycle model we where working in a risk-driven environment, which meant that whether the timeline said we needed something done or not was purely based on the current biggest risk and not on what the timeline said (however, risk assessment included time constraints). Thus what was really more of our roadmap was our list of current and past risks and their level of significance, this not only showed what we needed to eventually consider but what was currently being dealt with (the highest risk). Unlike the other roadmaps both of these documents where used internally only and where never shown to our “client”. Since our client was also our professor he did see both documents but not as our client, instead as our mentor. Unfortunately, I don’t have a copy of either documents as neither where stored in our CVS.

Final Analysis: where roadmaps fit in agile development

As I stated earlier I think that one of the reasons that roadmaps are not discussed as a part of the development process as much as other documents are is because they tend to orient themselves more toward a waterfall model or non-agile life-cycle. I don’t think that this means that they can’t be used in an agile process, I do think they must be used differently though. So if you are trying to be agile how to roadmaps fit in?

In agile development more of an emphasis is taken on dealing with what needs to be dealt with than dealing with a specific order that common development tasks must be accomplished in. Thus by creating a roadmap it would seem that you are forcing certain tasks to be accomplished in a certain order or direction. As can be seen with the Songbird and Wordpress roadmaps there is not a specific deadline for the tasks other than the over all goal of the version release date, this allows for the various tasks to be accomplished in any order. Also the Namaroka roadmap does not give individual tasks a deadline but instead outlines a very rough idea of when groups of tasks should become “finished” in each various phase of the development. By not giving firm deadlines for specific tasks it is possible to maintain the agility of the development, furthermore, it is always possible to change dates, and by doing this agility can be maintained.

Along with maintaining flexibility in a roadmap they can be great tools in the beginning of a project by outlining a project and preventing developers from diving too deep too fast, and later on they can help developers still see the big picture while developing small sections of code. The key to utilizing a roadmap in an agile development is allowing change within the document, if it stays static and is the absolute rule to the path of development then it is much more like waterfall development and a hindrance to the naturally changing environment of development. However by allowing it to change constantly (like the risks in my senior project) it allows for the whole project’s progress to be visible without hampering agile development.

Furthermore, as all three of the open source roadmap examples shown above are available to the community, it can be seen that roadmaps can also be an excellent way to provide progress reports to the community (or client) of software projects while still maintaining flexibility. Although, depending on the client it may not be a good idea to reveal as detailed an overview of the actual design elements of a software project as these roadmaps provide.

I am very interested in hearing what others think about this topic, or if you know of any articles or books that talk about roadmaps involved in the development process I would like to hear about them.

You have either just stumbled on this blog from somewhere else on the internet or you’ve found it from my previous location: codingnotes.wordpress.com.  But you are in the right place, and I welcome you.  As I have had some free time recently due to currently being unemployed and searching for my first Career job I have been getting my personal website up and running and so this is the new location of my Coding Notes blog. I don’t have anything in depth to post on today so I thought I would just point out that first if you have a bookmark or an rss feed pointing to the wordpress.com location you should update it to this location (codingnotes.alephcipher.com).

Secondly, I would like to point anyone interested in software life cycle models over to the Songbird teams blog. They have written, along with many other excellent posts, a series on their path of moving from a waterfall development model to an agile model.  It is really interesting to hear the differences that it made and to see an example of their new development process.

Check out the first three parts of the “Songbird path to agility” series here: part i, part ii, part iii.

I hope you enjoy them as much as I have, and I look forward to posting on more topics shortly (I’d love to hear any comments or suggestions in the comments).

- Legit

A while back when Mozilla released Firefox 1.0 and I started to explore the extensions I was amazed at the basic utility that I gained from some of the extensions. This made me think about the methodology of Mozilla in developing Firefox, I was sure that they would add some of the extensions into the core code base of Firefox. When 1.5 and then 2.0 where released I was somewhat amazed that they hadn’t added any functionality that where in my favorite extensions into the Firefox core program.

My senior project is essentially to develop a new quiz type for the MOODLE platform. The M in MOODLE stands for Modular, unfortunately the MOODLE platform wasn’t developed with the same methodology that Firefox was. MOODLE comes prepackaged with several modules, like a wiki, forums, and even a feature rich quiz engine some of which are in the core code base. Since my senior project is to develop a new quiz type the fact that MOODLE includes its own quiz engine would seem like a good thing, possibly less work for the team I’m working with on the senior project.

I now understand why Mozilla didn’t add some of the Firefox extensions to its code base. In order to spawn creativity and encourage extension development the extension can’t already exist. The problem with including extensions, no matter how basic, in the core code is that if anyone wants to add on to the functionality of the software and a module/extension already exists then most likely it will share some of the same functionality and developers, rather than develop the new extension, will simply learn to live with what exists. Unless specifically asked for (like my senior project) when something already exists in the code base it simply stifles development of anything new that follows the same functionality line.

I will say that MOODLE is very modular and has several great places where key components can be added. The problem with MOODLE’s design is that it includes too many modules as standard code base items, meaning they have documented the fact that certain modules are part of the core MOODLE code base. This creates difficulties when developing a new quiz engine because it would be easier to add on to the quiz module rather than creating an entirely new quiz module. However, since MOODLE is open source we can use the existing quiz engine and from it create a new quiz module that is our own, the problem with this is that it creates parallel development paths. Anytime MOODLE updates the quiz engine we would have to extract, modify, and re-release our own module in order to allow for the full functionality of the quiz engine that we are developing within our new functionality.

So what’s the moral of my little story? Essentially its this: when developing software that is designed to be modular/extendable make sure that you only develop the core code base, and don’t start adding new modules to the core code. Keep modular software modular. If MOODLE had left the quiz engine out of the core code base and marketed it as simply another module it would help but wouldn’t solve our problems. Doing this would however allow us to possibly work with developers on a smaller issue for development than have to look at an entire software package to be changed/modified. This is a hard thing to do though, especially for MOODLE, since you want all users to be able to do standard tasks, like take a quiz. But the key is to keep modular software modular.  At least as far I’m concerned.