The Zune Bug and the if/else Statement

For those that haven’t heard, the Microsoft Zune’s OS recently ran into trouble relating to 2008 being a leap year.  The Operating System got stuck and was unable to operate for an entire day due to a bug in the code, thankfully without a patch the Zune started right back up the next day happy as ever.

Over at “Freedom to Tinker” they wrote up a nice overview of the bug (including code):

On December 31, some models of the Zune, Microsoft’s portable music player, went dark. The devices were unusable until the following day. Failures like this are sometimes caused by complex chains of mishaps, but this particular one is due to a single programming error that is reasonably easy to understand. Let’s take a look.

Here is the offending code…

Read the full post here “Debugging the Zune Blackout“.  This particular bug represents the problem of not covering all of the cases involved in a particular if/else; in this case the else was left out.  The problem could have been solved by breaking out of the while when it was a leap year but not over 366 days.

This reminded me of the Gaurded Command Language(PDF) written by Dijkstra in 1975 (wikipedia article).  In this theoretical language Dijkstra presented the If statement with a unique twist.  The if statement consisted of several boolean conditions and their subsequent code to be executed.  So for a very simple example:

if
if A then AX
if B then BY
if C then CZ
fi

The twist comes on evaluation of the if statement, unlike most modern languages (I don’t know of any that aren’t like this) in which when none of the statements in an if/else are evaluated to true the program simply continues executing, Dijkstra’s Guarded Command Language was different.  Three basic rules existed for the if statement:

1. All of the boolean conditions are evaluated.
2. If one or more are true then one (and only one) is arbitrarily chosen to be executed.
3. If however, none of the boolean conditions are true the program aborts (crashes).

This is certainly much more strict than modern languages, thankfully, but it presents the nice idea that unless all of the cases of a given circumstance are covered then the program will not be capable of continuing.  Furthermore by preventing the continuation of the program when no true conditions exist the language makes it easier to debug because the problem does not cascade down into some other section of code but rather crashes exactly where the problem originates (the if).

On a more philosophical level the Guarded Command Language deals with if’s in this way:  When a child is asked by their mother if they want an ice cream cone and the mother only expects the answers ‘yes’ or ‘no’ then the mother is ill-equipped to deal with the scenario that the child may say ‘later’.  Granted we humans are smart and can on the fly deal with situations like this (ie. the mother wouldn’t “crash”) it presents the problem that when dealing with programming in a highly logical environment the fact that when not all possible answers to a problem exist it means that something is not being dealt with, which can cascade down into other problems.

The Zune bug presents a nice example of this, and while it is fairly small its an interesting and yet important issue involved in programming.

Senior Project Reflections 1: Following the Life Cycle

Chirp… Chirp… Welcome back everyone, it took me a bit longer than anticipated to write this but I am somewhat glad that I took the extended break.

If you like excuses then heres mine: I took an introduction to philosophy class because I somehow skipped a general credit elective in the process of earning my degree in Computer Science. The reasons behind taking a philosophy class instead of something else include the fact that philosophy is interesting to me (due in part to me being a Christian and growing up enjoying discussing theology) and also because I find the philosophy behind Artificial Intelligence(AI) research very intriguing but was somewhat ill-equipped as to how to approach it. I also enjoy hearing other peoples perspectives because it allows me to understand what I believe better and to better round out the sharp edges in my beliefs. At any rate It was a very interesting class and I am very glad I took it, I really enjoyed discussing metaphysics and the aspects of AI with my classmates (it was an online class so by “discussing” I mean online forum posting). So the excuse is that this class along with working full time took pretty much all of my time and I didn’t have much left for writing and “reflecting”.

However, now that I have had all of three months to think about software engineering I am finding that the break gave me a good opportunity to distance myself from the biases of the project and do a fairer analysis of my senior project. So hopefully you will enjoy it as well.

I’ve decided to post several reflections of different parts of my Senior Project. So here is the first part with an undetermined number to follow:

When beginning to reflect on my senior project a specific incident came to mind, I was sitting at a Starbucks listening to some marketers talk about their boss and clients and how they disliked them. The end result (from my perspective at least, since they never actually stated this) was that they didn’t enjoy working as a team since everyone had unreasonable and unachievable requests. I can and will discuss some other aspects that I found interesting about the marketers discussion, for now however, I am going to focus on the aspects of team building and one way that I found life-cycles can encourage quality team development. I realize I have discussed my teams life-cycle model before in my post “The Importance of Risk” but I hope I am bringing to light a different aspect of the model here.

One of the things that I found absolutely amazing about my senior project team was in the weekly meetings that we had together. We would usually get together on Saturday’s outside of class and work on our current and next iteration of our cycle (we were using the win-win spiral model), but in these meetings (and throughout the whole class) we never had a project manager, a project lead, or a born leader. Every meeting we would get together and discuss things and at some point someone would go up to the white board and begin facilitating and organizing the discussion. This facilitator would differ from week to week and they never lead the discussion but simply organize what we where all saying so that we could find the finishing point of that meeting.

The nice thing about doing things this way is that it avoided the standard “group project syndrome”, where one person would become a self assigned leader, and a couple of people would do all the work and couple of people would do virtually nothing. This type of group seemed pretty consistent in all of my previous projects and seems to be a natural way for groups to form because of the natural desire for a leader. One major problem with this “group project syndrome” type of group is that it results in very little team gelling and causes people to end up on very large critical paths by themselves. This results in a dangerous type of project that may never have an “end”.

However one of the beautiful things of software engineering is the invention of various types of life-cycle models, this makes working on projects so much easier because in “modern” life-cycle models the model itself can be the project lead, and the members of the team can simply be peers trying to work out problems and collaborate while following the model. If used effectively and actually followed life-cycle models can lead to wonderful end results with very gelled teams¹. To some extent this happened with our team on the CBAA project, we would get together let the life-cycle model be the leader and then collaborate on the discussion of what needed to happen next according to the life-cycle model. Not having a person as a leader was a very important aspect that allowed our team to gel really well, no one was distinct or “special” in relation to anyone else which allowed there to be very little conflict over ideas and design issues.

By using the life-cycle model as the leader and collaborating with a team to come to a conclusion I was suprised by how many meetings ended with everyone agreeing and verbally saying “well its going to be tough but I feel good about it and I think we can actually accomplish this” and every meeting I left feeling very in sync with everyone else. This helped us to all know the direction that not only others were going but also the direction that the team was going as a whole. We certainly had things we could have improved on, many things actually, but I think that for only having a single semester we were able to accomplish quite a bit of positive team gelling through this collaborative effort and treating the life-cycle model as the leader.

---

1 – Tom DeMarco in his book The Deadline points out that although it goes against common business practice it is actually quite beneficial to keep well gelled teams togethor rather than separate them. The benefit being that once they are gelled they are much more able to begin projects in a good way rather than a rocky way, since they are already gelled and comfortable with each other.

Where did it go…

Hello Everyone,

I haven’t posted in a while, I’ve been very busy with finishing my senior project and dealing with finals for my other classes. I have lots of things I want to post about that relate to my senior project, stuff I’ve read, and some other interesting things. So, as soon as I can find my mind…. I’ll post an overview and some final thoughts on my senior project.

In the mean time if you are interested in downloading the final (alpha phase) product that my team and I created for our senior project please visit: trimood.sourceforge.net

Hope everyone is having an excellent summer so far!

- Legit

My Thoughts on Modularity

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.

Low Hanging Fruits

Last semester I took Software Engineering Principles (the precursor to the senior experience class) in the middle of the semester my professor gave a mini lecture on low hanging fruits and how to accomplish things in projects.  One of the things he emphasized was that in the middle of projects it can seem that there isn’t much work to be done, of if there is it’s really lengthy work.  In theory the problem is that while working through projects things can come to a stand still because team members are afraid of doing duplicate work and so no one does any work.  The problem with this of course, is that then nothing gets done.  My professor described two ways of dealing with this, grabbing low hanging fruits, and just doing it.

Low hanging fruits are basically the easy to grab small(er) tasks that just need to be done, but aren’t necessarily the most important task.  The nice thing with low hanging fruits is that even though they may not be all that important they do need to get done and so they provide a lot of exposure.  Some examples might be putting the initial empty Documents in the repository just to get it up there, writing the simple interface prototype, and writing up meeting notes.  In my notes I wrote down that low hanging fruits are the parts of a project that are low risk, low energy, and high impact with the return of high visibility.  The low risk part means that the low hanging fruits are things that would eventually get done anyways, but its nice when other people do them (high exposure).

So while low hanging fruits are important they wont finish the project, what will finish the project is making sure that things get done.  Getting things done in a project means writing the same requirement as someone else, designing the same prototype, and essentially doing duplicate work from time to time.  But this is important because it allows for ambiguity to be rooted out.  So low hanging or not jumping into doing work that needs to be done is important to prevent a stand still, and you wont always be doing duplicate work.

One of the things that I’m finding in my senior project is that a lot of the low hanging fruits are also some of the most important parts of whats going on.  This may have something to do with the fact that we are following a risk based model, or not, but its nice to see that low hanging fruits are a very important part of it.  Another thing I’ve noticed is that low hanging fruits in our project seem to be the precursors for a lot of the high risk, high energy, high payout tasks.  So putting up the software requirement spec template and the vision statement template are the low hanging fruits, but they are important enough that without that initial step things would at the least be slowed down.

The Importance of Risk

    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

Managing Humans, A Review

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