Coding Notes

A few months ago I was working on some code that someone else had written. I was trying to add a feature into a class and couldn’t seem to figure out how the class worked, and thus couldn’t figure out where or how to implement my addition. After reviewing the code for a while I started to understand what was going on in the code and had a good enough understanding of it to then implement my new feature. The problem was since I then understood what the code was doing and how it worked I also felt compelled to restructure it, perhaps in a more logical order, or just change it so that it would be easier to understand later on. My problem was that after thinking about a new way to structure that class I wasn’t really certain about why that would be a better alternative, it just seemed better. So after wondering why it seemed like a good idea I decided to do some research into how to write “better” code, and why “better” code is “better”. My research ended pretty quickly as I remembered a few of my workmates talking about the book “Clean Code” a while back and how it discussed what makes “better” code. So I went to my local bookstore, picked up a copy, and started reading it.

Clean Code: A Handbook of Agile Software Craftsmanship was written by Robert C. Martin who has previously published books (which I have not read) on software engineering. He opens up Clean Code with the classic “WTF” comic of software quality, you know, the one that describes good code as code that produces the least “WTF’s per minute”. This is a really good example, since, that is exactly the kind of experience that got me to pick up the book. Martins purpose for the book is to present ideas on how to clean up code, and reduce the “WTF’s/Minute”, and make it easier for others and you to understand and modify later on. The first thing that Martin discusses is the problem of bad code, what it is, how it happens, and what the long term results are (maintenance, lots of maintenance). He then quickly transitions into a discussion of what clean code is, he asked several senior and well recognized software engineers what clean code is, and then lists their responses to get things started. After a brief overview of what clean code is, its off to the races, in depth analysis of clean code techniques and plenty of code examples to go along with it.

By far this book is not a quick read, or at least it shouldn’t be, most of the code examples that Martin gives are given first in the difficult code to understand context and then cleaned up into a clean code example. This method of actually showing the before and after code samples, if actually read and understood, gives immense meaning to the ideas that Martin gives on how to produce clean code. That being said, it is because of these code samples that this book is a bit of a slower read. Martin also encourages his readers to take the time to understand the code changes, warning that by not doing so you will miss out on the real understanding of why these code changes are occurring.

Martin begins the clean code concepts with fairly cosmetic issues, naming conventions, class and method sizes, comments, and formatting. These issues are fairly light on the technical scale (with class and method sizes being a bit more difficult) however, Martin does a good job of showing the benefits of implementing these clean code concepts. Then Martin goes into a discussion of more technical issues, error handling, objects and data structures, crosscutting concerns, system wide organization, testing, and even some discussion of concurrent programming. All the while he discusses not only good principles but why they are good principles, and gives examples of how to apply them. On some issues Martin admits controversy surrounding issues and clarifies why he came to his conclusion, as well as what others think. Martin then finishes the book with three chapters which take entire classes from well know API’s and dissects them into better, cleaner code, using the principles previously discussed in the book. These sections, as Martin states, are necessarily slower to read, given the large amounts of code and the complex changes. However, by slowly reading through them and understanding the changes being made it helps to bring together all the concepts of the book and shows how large sections of code can be understood and cleaned.

In the end of the book are several appendices, one is an in depth chapter long analysis of some concurrent clean code concepts, which an excellent discussion of what makes concurrent code difficult to debug and how to clean it up. There is also an appendix that cross references the principles of clean coding with the code transformations made in the last three chapters of the book. This appendix makes the book a great reference to keep on the shelf after reading it.

Overall the book is incredibly helpful, especially to software engineers who are earlier in their career (such as I). Held within the book are many useful techniques that senior engineers have taken a long time to hone, and if you read and absorb the concepts I think everyone can learn something from the book. That being said, several of the concepts that Martin discusses are controversial. His opinion that comments are unnecessary if the code is well organized and named, and in general clean, is definitely something that could be hard to swallow (depending on your stance with commenting). Martin isn’t completely against comments though, just unnecessary comments (he still supports comments in API’s). One of Martins main arguments against comments is that they simply produce one more thing that has to be maintained later on, a valid point. But despite the few controversial ideas that Martin discusses, none of which does he force on you, the book is filled with many highly useful concepts and excellent descriptions of why they are good ideas.

In the end I really only had one major complaint about the book, which is the subtitle “A Handbook of Agile Software Craftsmanship”. It is my opinion that clean code can and should be produced in non-agile environments as well, which I don’t think Martin would disagree with. Clean code is by far easier to modify than unclean code, and so its applicability may be higher within an agile environment, but it is certainly still applicable in non-agile environments (where the requirements are more static). My favorite concept of the book is also in the title, the idea of software engineering as a craft, too much of the time it seems that software engineering is seen as “coding”. The idea that software engineering is just hacking up something that does what your manager asked for is outdated and I think this book gives a nice introduction to software engineering as a true craft that should be treated with care and responsibility. Instead of just writing code, we as software engineers should write code that is of high quality, something that is truly well-crafted.

After reading the book my coding style has changed, I try to write clean code the first time, instead of just getting it to work. I also have a better understanding of why certain coding changes are better than others, which is why I picked up the book in the first place, so it fulfilled my needs and then some. I highly recommend it for anyone that is doing any programming.

Next on the bookshelf is “Data Visualization: Principles and Practice” by Alexandru C. Telea.

In the June 2009 issue of WIRED a group of three articles called “Our New New Economy” discusses the United States current economic climate and how it impacts three issues. While these articles don’t discuss specifically how our current economy impacts the three issues directly, they do discuss the importance of these three issues in shaping our new economy. The first article talks about the American car industry and how it must accept outside innovation in order to recover. The second article is about Google’s AdWord’s advertising service and how it can teach us something about auctions. The third article, the one I am going to talk about, is about how the internet is a socialistic entity and how that may encourage people to accept socialism in our real lives via the government. I disagree with Kevin Kelly’s, the writer behind “The New Socialism”, idea that socialism online can translate into the off line world and so I wanted to discuss why the internet is such a perfect platform for an idealistic socialism in the first place. First off though let me point out that I am not a political scientist, as regular readers should know, I am a computer scientist interested in philosophy and so my perception of Socialism may be slightly askew therefore, if I misunderstand something please correct me in the comments.

In order to discuss socialism appropriately we should first define what we are discussing, Kelly addresses the voodoo of the word socialism by defining it as such:

“When masses of people who own the means of production work toward a common goal and share their products in common, when they contribute labor without wages and enjoy the fruits free of charge, it’s not unreasonable to call that socialism.” – Kevin Kelly, “The New Socialism”, WIRED June 2009

Using one of the definitions in dictionary.com we can support that definition:

“A theory or system of social organization that advocates the vesting of the ownership and control of the means of production and distribution, of capital, land, etc., in the community as a whole.”  – Dictionary.com

By synthesizing these definitions I will define socialism, for the purposes of this blog post, to be defined simply as:

Internet Socialism: A society that is community run, owned, and consumed without a governing body.

I don’t have any problems with Kelly or anyone else defining the internet in this way because it fits, as Kelly’s article points out there are many online services that are community run, owned, and consumed. Services like Twitter, Digg, Open Source Software, Facebook, Wikipedia, Blogs and the World Wide Web itself all fit this model, they are run by the community generating content, then that content is released to the community for it to own (do with as it pleases, rate it, modify, etc.), and for the community to then consume by deciding what to do with the content that it creates. Therefore, it is rather easy to see how the internet functions within a socialist type of facility however, Kelly’s closing words in his article scare me; he says:

“The force of online socialism is growing. Its dynamic is spreading beyond electrons — perhaps into elections.” – Kevin Kelly, “The New Socialism”, WIRED June 2009

Kelly poses the question that translates between internet socialism and physical world socialism within his article:

“How close to a noncapitalistic, open source, peer-production society can this movement take us? Every time that question has been asked, the answer has been: closer than we thought.” – Kevin Kelly, “The New Socialism”, WIRED June 2009

When Kelly poses this question I am assuming that by using words like “society” and “noncapitalistic” that he is referring to the real world that we (or atleast capitalist country’s) exist in, the non-internet physical world. The problem with making this comparison is that the internet provides an ideal context for socialism and community that doesn’t translate to the real world. It is in the differences between the internet and the real physical world that we can see how socialism wont translate. So what does the internet provide that the physical world doesn’t? Socialism cannot translate from the internet to the physical world because of three issues: the internet produces “soft” goods, the internet provides anonymity, and the internet is not itself owned by anyone.

Lets start with the first attribute, that the internet produces “soft” goods, or more specifically it provides digital goods. The property that the internet and its socialism produces are stored in binary electronic form, they are 1’s and 0’s on a hard disk. This attribute of the internet’s product is also at the core of the DRM debate, I was once told by someone that the reason that the music and movie industries don’t care about you taping TV or taping the songs from a movie onto a cassette is that it produces an imperfect copy. The internet and computers prevent this problem, digital content can be copied millions of times and still be exactly the same as the original copy, the 1’s will still be in the same places, and the 0’s will still be in the same places. This perfect copying ability of the internet means that the same property that I get, you also get. So on the internet the ideal is that the “products” are able to be copied perfectly and as many times as you want, creating a perfect distribution system within a community, no one has any need for greed because everyone gets exactly the same product, and if someone doesn’t have that product then someone can give you a perfect copy of it. This obviously doesn’t translate to the real world, in the real world we have issues of supply and demand, imperfections in manufacturing, and the inability to simply copy something as a distribution method. I cannot simply copy my land and house so you can have one as well, it’s impossible within our physical world, and this creates greed or want in people which prevents the internet’s ideal socialism from occurring in the physical world.

The second attribute, and I think the most important, is the issue of anonymity within the internet. The internet is accessed by billions of people, and all of those billions of people can sign up for a free e-mail account, sign up for a free twitter account, and their account will be just as capable as everyone else’s account. Furthermore, everyone that signs up for one of those accounts can put in fake data if they want and the power to detect whether that data is fake is limited because of the flexibility of IP addresses, cyber cafe’s and coffee shops as well as other issues. Essentially people can be whoever they want online, they can change their age, race, country, language, etc. this issue has been known for years. So how does this impact socialism on the internet? If you study any amount of history you will quickly notice the ideas in the physical world of classes, every society has classes, sometimes the differences between classes are small and sometimes they are large, but no matter what you will always have classes. Classes can be determined by social perceptions, by wealth, by land ownership, or any other physical means. The internet transcends the idea of a class society by allowing people to all have the same kind of account, my twitter account doesn’t do anything more or less than your’s does, I can customize it, but you can customize your account to be exactly the same as mine. This lack of uniqueness within online community prevents the idea of classes from rising up (for the most part) furthermore, if they did everyone could simply change their identity and suddenly be in a different class. This anonymity that the internet provides cannot translate to the physical world because you cannot change your identity, it takes work to create a physical brand for yourself and to attain belongings, this means that some will have and some will not have, creating classes. Thus in the physical world this class system prevents everyone from being on a level playing field, further preventing the idealistic socialism on the internet from translating to the physical world.

Continuing the discussion of classes I should point out that if net neutrality is lost then classes will rise up online. As soon as you have to pay for more bandwidth, or pay to access certain areas of the internet a class system will arise on the internet. This class system may not be exactly the same as the physical world but it will destroy some of the ideal that allows the internet to be an ideal socialistic community. The reason for this is that some will have more bandwidth, some will have less bandwidth, or something similar, and thus the classes of “lots of bandwidth” (we’ll call them the nobility) and the “not much bandwidth” (we’ll call them the peasants) will be created. This will destroy the community of the internet. So for all of you that had no other reason to like or dislike net neutrality there is another reason for you to consider.

The last attribute of the internet that prevents the socialistic ideal on the internet from translating to the physical world is that the internet is not owned. The internet is set up via routers, switches, hubs, etc., which are really just specialized computers, it consists of these specialized computers dealing within layers of open protocols and software to communicate. The internet could be set up via other computers (wireless networking makes this much easier via mesh networking). Furthermore, the Internet does not all disappear if one site goes off line. Because the internet is built around open and easily accessible technology, and because all of that technology is not owned by any one entity it is completely feasible for one section of the internet to be inaccessible all of a sudden and the internet would still exist. In fact if the entire internet died off a new internet could be set up among a group of friends; really its all just a collection of connections, when one connection is removed there are still other connections. This is perfect for socialism to thrive online because there is no one governing body, it all exists outside of extensive regulation or ownership. Yes, individual sites are owned by companies but the important thing is that all of the sites are not owned by the same company and they are not all subject to the same laws or rules.

So why can’t the non-ownership of the internet translate to the real world? To be short: because of government. Socialism is defined in the American Heritage Dictionary (according to dictionary.com) as:

“Any of various theories or systems of social organization in which the means of producing and distributing goods is owned collectively or by a centralized government that often plans and controls the economy.” – Dictionary.com (American Heritage Dictionary definition)

I know that people may argue with me on this point but lets face it, we need a government. Unless you create a country of five people you are most likely going to need some form of leadership to prevent complete chaos and moral disregard. The form that this government or leadership takes may be different but it suffices to say that it must exist. You cannot create the socialistic ideal of the internet within the physical world because the internet does not allow for physical crimes, someone cannot be physically murdered, assaulted, or otherwise impacted via the internet (ignoring the physical technologies that are controlled via the internet). This means that laws and protections don’t need to exist on the internet to prevent these crimes, in other words, the internet by its definition as an electronic medium regulates and prevents certain crimes simply by being that electrical medium. This does not translate to the real world, because in the real world we have greed (see point one) and we have classes (see point two) this creates conflict, which requires resolution, and this means that the idea of socialism must be regulated if it exists within the physical world. This regulation would most likely be manifested through some form of leadership or government. Many examples exist that show how government regulation of socialism in the physical world are negative (China is a very good example given its regulation of the internet). This regulation then prevents the ability for the community to run, own, and consume its own goods independent of some authority that regulates. This means that it is impossible for the idealistic notion of socialism that exists on the internet to translate to the physical world, because the “government class” must be created to essentially “own” everything.

To present an overview, the internet is a perfect platform for socialism because it produces “soft” or digital goods that can be infinitely and perfectly copied for “free”, the internet provides anonymity which allows for a classless society, and the internet is not dependent on a single governing authority either for its existence or for its regulation because through its electrical medium it is capable of preventing violent physical crimes. This ideal platform online doesn’t translate to the real world because physical good cannot be reproduced perfectly and indefinitely without significant cost to the consumer, the physical world does not allow for significant anonymity and so it creates classes which create conflict in the physical world, this conflict requires regulation and oversight which means that a government or some form of leader entity must exist to regulate and manage the physical community. The big problem with having a leader over a socialistic society is that they essentially manage everything, from the community and crime within it to the economy which gives it immense power which can create a very dangerous situation for the people under that government. When that government decides that it wants to exist to protect itself rather than the people you have what most socialistic countries are, which is a totalitarian government that regulates everything and prevents a society that is community run, owned, and consumed. Thus it is important to realize the differences between online and off line and why the “perfect” socialism on the internet cannot and should not be translated to the physical world.

For those of you that don’t know me personally (or haven’t read my about me page at alephcipher.com) you may not know that I am a Christian.  My faith in God consistently impacts the way I live my life, and while I am far from perfect Christ still saved me and I try to live my life for him.  However, throughout my education and work experiences in software engineering I have felt that there was a lack of Christian candor within the greater engineering community.

As a result I recently started a new site: engineersforchrist.org

For any of you engineers that are also Christian’s I would really appreciate your input on what you would like to see it turn into.

- Daniel

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

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.

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.

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

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.

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.