The Next Holy War: Distributed VCS versus Centralized VCS

I often find myself being an advocate for something specific in the technology field. And, many times this relates to the common “holy wars” that most of us are familiar with. I sit on the emacs side of one, and the open source side of another. You can immediately understand what I’m referring to when I say “emacs”. The next topic for war I believe is going to come down to version control. If you want more proof, take a look at Derek Slager’s DVCS Myths post.
Currently there are two main types of version control and source management, centralized and distributed. I’ve used centralized systems for quite some time and although they have served a purpose…I find them to be outdated. Now, hear me out before getting frantic. The software industry is changing. We are in the midst of evolving the way we work. We want to work bigger, faster, better, stronger, right? There has been a push over the last 10-15 years to revamp our development methods. What I’m referring to here is the waterfall to agile approach of things.

The waterfall approach is about building very hard speced systems over the course of “x” to completion. Once the system is complete, you test, debug, etc. This is often very clunky, doesn’t describe the entire system, and takes an extremely long time to obtain any tangible assets. By this I mean that nobody can see a working system part of the way through. Thus, expectations are usually high leading let-downs as a result. The agile approach, in many ways, was created as a way to attack the problems at the core of the waterfall approach. Also, certain agile approaches can help do more such as improved development efficiency. With this in mind, and understanding that I sit on the agile side of that fence lets talk about source code management (SCM).

Centralized version control was fantastic. It provided the foundation for storing code in one place such that developers could work on code and then push it back into that one location. Not only was this able to happen, but we could lock, merge and tag. These are all good things by the way. What good would any SCM be without them. The lacking areas are the repository and the workflow.

Since we talked a bit about workflow above as it pertains to development, lets talk about how it relates to source management. In the likeness of the Pragmatic Programmers we know a few things to be good. That we want to refactor early and often. And, we do not ever want to settle with broken windows. These few things being said, lets discuss them as they pertain to workflow. In any SCM we can accomplish each, right? We checkout code, modify it, and commit new code. Centralized or decentralized. But, I’ve found it easier to manage the above “good things” within distributed version control system (DVCS). When I am working on refactoring code, I want to have an experimental branch. This allows me to create features, change API, and muck with the general internals of a codebase without destroying the greater good. That brings me to broken windows. If all developers commit to a central repository, then all code is based on said repository. Thus, if you have a team of n (including yourself), you can stop n-1 people from working for h number of hours in a day by commiting some code that you thought worked.

With a DVCS, you are commiting your code to a branch. This means that you are not commiting to the central repository. Sure you have to deliver your changes at some point, but you are more likely to have your code in working order. Also, it allows for easier testing of your code, since your code will be a subset of all new features and changes. So, when we refactor our code or write new features we are setting ourselves up better by having the DVCS.

Now that I’ve touched a bit on the workflow we can talk about the repository. Distributed version control systems are just that, distributed. The point is to make it easy for developers to make changes while being anywhere. The way this works is with distributed repositories. Distributed systems work by branching. Although the notion of branching is built into SVN and other centralized systems, they don’t work the same.

Distributed systems, as seen in the image, mean that everyone is a node, or using our terminology, a repository. Rather than just feeding off one main location, I can pull from my friends repository, push code changes up there or to a different repository. Branching allows for this sort of behavior.

So, when I modify code on my system and then commit it to my local repository, I can push those changes along to whomever or they can pull them down from me, and everyone has my latest changes.

So, I believe the thought going through your mind at this point is, wait…You’re contradicting yourself. If I want to commit often and refactor even more often then I’ll likely break something. Thats not good. The point here is that you shouldn’t work directly in your local repository. You should branch the repository and do work within the branch. For instance, say you are working on an OS. You can have a branch for networking. I can then grab that branch but if I have to implement some experimental IPV6 functionality, I’m not going to do so such that everyone gets those changes. I’ll branch the code base and do it there rather than expose that code to everyone. With a centralized system, you can branch the code…but merging the modifications back would be complicated and cumbersome, and in some cases not possible. If you need more proof take a look at Griddle Noise: What a DVCS gives me.
This being said, the industry uses centralized version control for most work currently. I feel that the change to agile programming should be accompanied by a SCM system that easily supports agile processes. A DVCS goes hand in hand with a distributed source management system.

There, I’ve stated my thoughts on the point. Flame away.

Yahoo! Recreating the Wheel Yet Again…Or Are They?

So today I saw an article titled “Building a Social Network from Within: Yahoo!“. This interested me as it is one of the things I’m involved with on a day-to-day basis. So I started reading the article and I saw this:

“Basically, “Y!Open” will allow users to have a social profile page and integrate all Yahoo! services as well as customize the page by adding applications, thus giving users an experience similar to social networking sites like Facebook and MySpace. It will enable users to find and interact with each other in an easier manner.”

Why Yahoo! feels this is a good idea is beyond me. They are in essence taking parts of Facebook, MySpace, and Okurt, and combining them while then calling it something fresh and new. I understand that they have many applications and users. But social networking is not just about having applications. If you look at the top used social networking sites, the thing that sets them apart is their ease of use and ease of connection. Meaning, the user experience is top notch. The reason facebook is so popular is because you connect with friends and then you have a feed of information streaming to you about all of your friends. This provides some basic instant updates about your friends so that individuals feel as though they are staying in touch with what is going on in their friends lives. Yahoo! does not feel that they are recreating the wheel. This gem comes from one of their architects.

“There’s a massive, latent social network within Yahoo!, and we’re going to bring it to the surface. We’re making Yahoo! more social, but we’re not building yet another social network. We already have an incredible social network… we just need to unlock it.”

I’m hardpressed to see how this makes any difference in whether they are recreating the wheel.

The thing that comes to my mind immediately is that they are looking for any way to keep users on their site; using it longer and exposing them to more content…and by content I of course mean advertising. What I see happening from this is that Yahoo! will gain from this move. While it’s generally really bad practice to recreate the wheel and go over everything once more, have to regenerate lists of friends and put up pictures, bio information, etc., I think that Yahoo! stands to gain a good deal of popularity from this.

The reason Yahoo! stands to gain is because they already have a very large user base. They have the branding done and using the Microsoft bid to buy Yahoo! they are leveraging the press the take the mass media for a ride. Now Yahoo! has become a front runner. Not only that, but their ad reach is second only to AOL. Plus, the promise coming from Yahoo! is that they are going to redevelop the back-end and front-end code so that it works better together. To me this sounds like a big plus for the user. The user should see some speed increases and experience changes. Hopefully, Yahoo will take a hard look at it’s UI libraries and revamp the code therein. Plus it appears that they are going to look at the little developers too, but I’ll have to see this to believe it. So far Google is the only company that really does that with Facebook and MySpace being somewhere behind them.
I guess that this is really only something that time will be able to tell but I believe that Yahoo! may be able to pull something off and it could kick Google’s attempt to the curb.

Good Engineers…Where?

Today I decided to take a stroll through some of the blogs I like to read up on and saw “Undergraduate Programming” on joelponsoftware.com. Joel’s post was to discuss “Computer Science Education: Where Are the Software Engineers of Tomorrow?”. I decided I wanted to comment on this as it’s been a recent topic of discussion with some friends and myself. The real question is, “Where have all the good engineers gone”?

Computer Science Education

While I can certainly say I was satisfied with my undergrad in Computer Science, I do wish I had more training in theory and algorithms. To be perfectly honest, these are the elements that are crucial to a true CS understanding. I’ve also seen a number of people both in jobs and looking for jobs, in school and graduating, who are supposed to be the Stallman’s and Torvalds’s and it seems to me that people just don’t have the same understanding that people who were educated in this field had a few years ago. I think the article makes an excellent stab at trying to pinpoint the reasons.
Computer Science programs all over are dumbing down the curriculum’s to attract students. The problem with this is self evident. If you’re program doesn’t teach as much and isn’t teaching the theory then how do we expect the students to really provide the innovation and software of tomorrow? In fact, the article points to this quite well.

The resulting set of skills is insufficient for today’s software industry (in particular for safety and security purposes) and, unfortunately, matches well what the outsourcing industry can offer. We are training easily replaceable professionals.

However, I don’t think the introduction of Java is to blame for this. The reason being that the same theories and algorithms can be taught in Java based courses. The issue is that the programs are not challenging the students enough. The courses don’t push students to the edge of their mind. Also, students aren’t pushing themselves (we’ll come back to this trend). A number of courses I’ve seen consist of the code being spoonfed. By holding the students hands through wading in the kiddie pool we are really just setting those students up for failure when they are tossed into the shark infested lake and expected to be able to walk on water.

Now, back to students and lethargy. When has it ever been acceptable for people to expect that they will be coddled? What kind of future will the field really have if people don’t discover on their own, try new methods, read new and old theories to better their abilities as developers, innovate, or think critically? People seem to be extremely apathetic towards bettering themselves. I don’t know that this is distinctly seen in the software engineering field or if it can be seen elsewhere as well. But it seems to be a major problem. Unfortunately I don’t know that there is a fix. People do not simply change how much they care about something overnight. Thoughts? I feel that this trend has and will continue to lead to the decline in truly competitive software engineering.
To get back on point; there are issues with both the education system and the people attending these systems. But I think that the guys in the article are on the right path in that, we can’t dumb down the courses taught. In the courses I took at college we were expected to write the libraries ourselves _before_ we could utilize the ones provided, all in Java too. Java should not be taught starting with a GUI, this is not Visual Basic folks. Instead teaching OOP constructs, which helped me to fully grok pointers and other C constructs, teaching the threading model, etc. are incredibly useful tools for developers.

A language is a tool in the toolbox of a developer. My friends and I have this conversation consistently, no developer should be so keenly attached to a language that “that is how I program”. Instead they should see where a language provides the best solution for the problem they need to solve, and then use that language to solve that problem. And, to be fair, the authors make this argument as well.

Real programmers can write Fortran in any language

The point I’m trying to drive home is that while these guys make some great observations, they are misplacing the blame. The blame is on the departments and the students, not a language. The professors should be trying to push their students above and beyond what the student believes they are capable of, and the students should be begging the professors to get a better understanding. This leads into another discussion that seems to be coming up a lot that I may talk about at some point which is the 80/20 percentage break for programmers.

Joel on Undergraduate Programming

Ahh, back to where this post really got started. Joel, taking the thoughts of the authors from the article above provided some thoughts on a possible solution. To an extent I agree with Joel. A Computer Science degree should consist of a rigorous set of CS courses in theory, algorithms, systems, languages, etc. How can the slack be picked up? Is creating a new school the place to start?
I disagree with Joel in that I think math really provides a foundation for critical thought. With math things are black and white, right or wrong. There is no middle ground. While software problems can have many solutions, just as math, there are always better and faster ways. We too often think that the first solution is the most accurate. This is usually incorrect. In fact, whenever I or my coworkers are developing something my boss tends to ask, “You’ve reworked it about three times right? It should be pretty good then right?”. Mathematics helped me to learn to think in new/different ways about problems. Going from basic arithmetic to find the slope of a line to calculus and integration showed me that while there are many ways to skin a cat, getting a chainsaw might be overkill. Learning proofs and theorems helped me to realize this. Seeing the ways in which mathematicians approach problems gave me a foundation for my approach to software.

I can’t give math all the credit there. I attended a liberal arts college for the intent purpose of getting a well rounded education. It’s important to be able to understand other things, interact with others, and to be able to examine other methods.

Also, Joel makes mention of starting up a new school with the expressed desire of building a software development factory where you’re education is essentially an internship on roids, thats right 50 Cent…I went there. I actually like the idea. While I do not think that all of the school should be coop/internship, I do believe that you learn more from working with others. Hell, if anything else, you learn that you may be the only thing that saves a project from failure. But more seriously, real projects, with real deadlines provides a foundation for some of what I discussed above. Students aren’t pushed…well, push them. Right on Joel.

Conclusion

Keep in mind that I’m not trying to say that everyone is lazy, careless, and stupid. Nor am I trying to convince anybody that I’m right. I’m only just point out observations that I or friends of mine have made. Also, we’ve obviously seen the opposite where people really amaze you with their level of understanding, ability, and desire to better their craft.

Normally I wouldn’t be so explicit about this whole topic but it seems to be very habitual which is disconcerting. And, it seems that others are seeing this trend too. If the issues can be addressed, awesome. I’m sure there are some more intelligent people than myself mulling this issue around and working on a fix or some fixes. To them I say, “I salute you”.