Some reasons to download and use Ubuntu:

1. You can’t afford (or refuse to pay for) Windows Vista or Mac OSX Leopard
2. You want to learn how computers work (Linux hides nothing from you — you can literally find out how everything works)
3. You’re a mad h@X0r and want to show off your sKI11z
4. You like to try new things, and aren’t afraid to reinstall your operating system a few times just to get the hang of it
5. You want to be part of a helpful community of computer geeks who enjoy tinkering as much as you do
6. You like the word “Ubuntocalypse”
7. You feel peer pressure from this blog post
8. You loathe M$ and wish IE would die a slow, painful digital death
9. You like pretty graphics, but really get excited when you see white text on a black background and a blinking cursor
10. You want to court the favor of the gods

After the code has been stabilized for a scheduled release, it is then branched. Branches are important because they allow the developers to continue adding improvements to the main body of code (often referred to as the trunk), while having an exact copy of the released version of the code to which they can make bug fixes while new features are developed independently. When the new enhancements are ready to be released, the bug fixes in the branch are merged into the trunk, and a new branch is created from the merged files. And the cycle continues.

The interesting thing about version control systems is how they handle differences, both between individual files and entire branches. If version control made a copy of a file every time it was changed in order to keep a history of all changes to that file, the repository would grow to an unmanageable size. Most small/medium size software projects are literally composed of thousands of files. Instead of making copies each time something is changed (or branched), version control simply catalogs the actual differences that are introduced with the change. So if I add a single line of code to a file and commit the change to the repository, version control notes the original state of the file, and then notes the one line difference in that file’s history.

I wonder if our minds work like version control. We experience an enormous amount of mental stimulation every day, though our raw sense experience, and through the activity of learning new things. Perhaps our brains take the new information we receive daily, compare it to the information we already know, and make note of only the difference in the information in order to conserve “space”. This would explain why, at times, we have problems recalling details for a specific experience — because our brains never recorded the details, only the unique elements the experience provided. Our memory then, would operate recursively, starting with a particular experience and moving backwards to reconstruct it based on the other memory references the brain has created.

In primary schools we are introduced to basic concepts like shape and color, and from that point our learning becomes ever more refined, until we can exercise the ability to think in abstractions. Perhaps abstractions are difficult for us precisely because the brain must perform so much recursion — it must constantly work “backwards” to find the concrete origins for each abstraction.

What do you think?

In the beginning, everyone is psyched. The client, developers, and managers all sit down at a meeting, draw up a solid spec, do some story-boarding, develop a data model and an architecture plan. They *know* that the system will work, and are confident that they can deliver on time and under budget. They have their “constitution”, and if adhered to, they will be successful.

As time goes on, the client begins to get antsy. They want to see something *now*. They come up with a bunch of “nice-to-haves” that weren’t in the original spec and begin to pressure management to give in to scope creep, oh, and to still deliver on time and under budget. If management had any balls, they would insist on a meeting with the developers to generate a revised spec and time and cost estimates. But management ignores best practice and gives in, a little at first (because, hey, it can’t hurt to bend the rules a little bit), a little more later, and so on. Eventually management begins writing change orders as fast as the customer demands them, throwing them to frightened developers who wonder who will bear the cost of catering to special interests. And of course, the developers end up paying the cost. They begin working longer hours, forfeiting their spouses and children, perhaps even loosing their marriages to the pressure. The bonuses that were promised never come, the vacations all get canceled, and benefits decrease… except, of course, for management, who have insulated themselves from the consequences of their own choices.

Eventually the software is delivered, most likely late and over-budget, but the developers suck it up and breathe a sigh of releif because at least it’s over now. Until the customer wants *more* enhancements and features, and now the developers have to plow back through the garbage heap of sloppy code, hacks, work-arounds, “cheats”, and other heinous aberrations that they dumped into the source because management decided that revising a spec and thinking about the legitimacy of each change request was too much work. In their infinite wisdom, management bends over and takes it from the client, yet again, and holds the whip over the developers who now go home and drink themselves to sleep at night because they have come to hate what they do, hate their managers, hate the client, and pretty much hate life in general. And they are reminded, when they complain to management about throwing process to the wind that, hey, “you chose this career…”.

Now, the moral of the story is pretty simple. If you compare the size and scope of our government operations today to the size and scope of the original government drafted in 1776, the growth magnitude is frightening. Instead of sticking to the plan, and modifying the Constitution legally if needed, our “leaders” decided to pander to special interests and increase the reach of the federal government in the name of meeting the “needs of the people”. And who ends up paying the price in the end? The hard-working citizens who produce the real wealth and value in our country. But the bigger tragedy is this — some of those hard-working people (developers) will begin to believe the lie that the “customer is always right”, and will themselves want to get their “share” — after all, if they are busting their nuts for every other parasite who wants something from Congress, then surely they should be entitled to the same treatment. And so the beast continues to grow, the “source code” becomes fragile and unstable until no one is happy. The clients are never satisfied, the developers begin leaving en masse, and management makes sure their resumes are up to date and they’ve cashed in whatever options they had before the company collapses under its own weight.

I don’t know if the comparison is a stretch — maybe so — but I *do* know that the problem can’t be corrected by hiring management with more charisma, talent, or charm. Instead, you need management who understands *how* processes work, and *why* they are important, and who will stand against the tide of angry customers who throw fits about their wants and needs and demand special treatment. You need management who will go back to the original spec and say, “no, this is what we agreed to. If you want to change it, we need compelling reasons. And just so you know, it will take longer than you’d like and cost more than you think, so be prepared to jettison the idea that you can have your cake and eat it too.”