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.

    One of the hardest parts of a project for me is at the very beginning, getting started.  The start of a project represents an awkward and yet immediate transition from what do I know about the project and, what do I need to know.  What you do know is generally what your client, customer, or manager just told you about the project: “I need a humdinger that will zoom, zip, and fly.”  This, however, is where the awkwardness comes in, you now know what they think they want, the difficulty comes in translating that into a final product down the line.  And so naturally as a software engineer you start to ask questions about the product.  This is the start of finding out what you need to know, what the client means by “humdinger” and how exactly “zooming” and “zipping” relate to it. 

    This transition is a hard one because you begin with, most likely, a very vague understanding of what the client wants and its your responsibility to take that understanding and materialize it while they watch.  But all you have is a vague statement, so what does the final product actually look like? what does it really do? who are all of the stakeholders?  This all translates into a simple question of the scope of the project, and more importantly of version 1.0. Tied neatly into this question of scope is the whole bundle of what you and your teammates are as software engineers going to be doing until that 1.0 arrives and the client signs off on it.

    Scope, to me, is a scary thing, it defines not only the final product but more than likely it heavily impacts the core of your technology.  If you decide that these certain features are not going to arrive until 2.0 then you have to make sure that 1.0 is going to fulfill the architectural qualifications of allowing those features to be built in later.  Scope represents what you need to consider along the way of getting to 2.0 while you’re really just working towards 1.0.  This is where risk comes in, in my opinion to save the day.

    So, as I sit there with my teammates questioning what it is exactly the client wants and what I need to know in order to deliver it, risk starts popping up.  What if I don’t understand the client, the product, my responsibility, and so on.  Then reason and “project” kicks in and you start to look at your life cycle options.  Risk based life cycle models like the spiral or more refined win win spiral are excellent at starting projects appropriately.  More than likely all projects will start with some sort of problem of scope, meaning “what exactly was the client talking about?”.  With other life cycle models you may start with feasibility (waterfall), or some other standard starting point, or some other general direction.  But with risk based life cycle models you are immediately addressing the concerns that you face with the product.  If you understand the product but have another risk, then you can gladly and rightly start with this.

     This is where solace enters into the start of a project, because with other models you may have a place to start, or not, with risk based models you can immediately start to deal with the things that make starting a project so difficult.  If the team says “what exactly is a humdinger?” and that’s the largest risk, that’s where you start.  If the team says “I understand the product, but the timeline is too short” then you can start with reasoning out version 1.0.  Of course working with other models will certainly work, I would say that time has proven that using any number of models, including risk based, will work.  But one of the nicer aspects of risk based models is that instead of concerns on the backburner until the model allows time for it, with risk based models it can be immediately addressed.  This allows for a nice amount of stress to be dropped at the beginning of a project.

    – Legit

Michael Lopp is a middle manager of software engineering teams, having worked at various companies in the Silicon Valley including startups from the age of the internet boom his experience is truly varied. He has worked from the standpoint of the software developer, QA engineer and naturally the software engineering manager. This broad experience in work is very apparent and adds greatly to his book, which in the first chapter he jokingly titles “Don’t Be A Prick”. The book is described by him as “insights, ideas, and opinions about how to manage people” and his emphasis on people is spread throughout the book. In fact the key to what this management book is truly about is Lopp’s emphasis on people.

Managing Humans is a collection of Lopp’s essays from his blog, edited and categorized into book form, which gives it a very loose and varied feel. Chapter topics range widely from dealing with freak outs in the office to the importance of CVS comments. Due to this widely varied nature of the book the actual content and impact of the book is far greater than just a management book. In fact, management in this book is taken less from the standpoint of corporate policies and politics and more from the perspective of how to dissect the various types of people and how to utilize those people effectively, and more importantly how to understand and communicate with those people.

In one chapter Lopp describes the various types of attendees at meetings, how they interact, and their meeting personality. In another chapter Lopp talks about the different people that are important in the interviewing process, and while he advocates that an entire team should be involved he discusses the different bellwethers that add the most valuable feedback on the potential employee. In a broader since, Lopp talks throughout the book (with a pecific chapter for each) about the two rare coders termed “the fez”, and “the free electron”, but as mentioned earlier he talks not only about how to utilize them, but also how to make them better (more in the case of “the fez” than the “free electron”).

However, while Lopp talks about the different people that may be managed and how to utilize them he also talks about a varying degree of other topics, as well as somewhat how to be managed. He talks about how to resign gracefully, how to pass the phone screen, how he does the interview process, and how to pass the 90-day interview. He also talks about how to keep 1.0 software development projects alive from a management perspective. The most valuable aspect of the book, I believe, is Lopps explanation of how to deal with different people in a productive way, instead of a contradicting way. Lopp even talks about how to deal with the different styles of managers and how to communicate effectively to them, while still maintaining your sanity.

Overall, this book is more a dissection of the common Software Development process within a company and how to work in this environment than it is a management book. However, it would do a lot of managers some good to read this book in order to understand what, and more importantly who they are managing. On top of this issue Lopp’s discussions of being managed adds an important aspect that the common software engineer can benefit from. I would suggest this book as default reading material for anyone that is in the technology industry, as well as anyone that wants a semi-comical look at the politics of the standard office place.

- Legit