So today I finally got my mobile phone service set up. And how mobile services are billed in the US is quite different than how it works in Sweden. The basic rule in Sweden is that if you do not make the call, you don't pay. That is, you pay nothing to receive calls and you pay nothing to receive text messages. The exception from the rule is if you're roaming outside Sweden. In that case you pay the costs for transferring the call/text to wherever you are.
This is not how things work in the US. Here you pay for incoming text messages as well as incoming calls... Always... So if I call/text my wife we have to pay for the communication twice... Actually that only applies to text messages since we have unlimited minutes because of the service plan we have but still... I don't get the logic behind this scheme. Maybe it's because I'm Swedish...
Getting a drivers license in the US is not the same thing as in Sweden. First of all the booklet you can read to study is much shorter. At least in state Washington. The written test is 25 multiple choice questions and you need 20 correct answers. Since the test is computerized you actually only have to answer 20 questions if you get them all correct. Another nice thing is that you can skip questions and answer them last. I wasn't sure on two questions so I skipped them and since I got the rest correct I never had to answer the skipped questions. That at least makes it feel easier.
The driving test it self took 15 minutes and included parallel parking, parking on a hillside and basically driving around a block with no traffic. Really easy if you've had a drivers license for some time. But to get top score remember to stop before any lines at stop signs (not even the front bumper may pass) and make sure you can parallel park with only three distinct turns on the steering wheel.
For the first time in my life I've bought a car without the feeling of getting ripped off by the car dealer. I'm not particulary interested in cars and especially not in how they work and what makes a car better than another. I select car purly on feeling. I also hate negotiating. So when I found out that there actually exists a person who finds the car you want, negotiate a good price and then delivers it to your door including taking care of all the paperwork I was surprised that this isn't more common. Now I only have to decide on what will be my second car so I ca order that too.
By now you've hopefully heard about craftsmanship over crap and the other day I heard about a research report where they concluded that university students majoring in engineering have problems translating theory into practice (article in Swedish). Education is not the key to becoming a good programmer. It is a catalyst that will help you get better faster. But it will always take time to become a good developer. But to become a great developer you must never stop learning. So why am I talking about this? Well, it's because something I read that made me real sad:
"Benefits: [...] Through less lines of code you can get more done."
And this is not the only example from the DBA world I've seen. First of all the statement is false. Through less lines of code you get the same work done. But less is not more. Just reducing the number of code lines for the sake of reducing lines generally result in code more difficult to understand and maintain. For some reason being a DBA and being a developer seams like a rare combination. I've worked with a few DBAs that worked like developers mainly because they were developers that had an interest in databases and then turned into DBAs. And what do I mean with "working as a developer"? Being lazy, i.e. automating as much as possible and making sure they can reuse stuff without duplicating code. Maybe even having a number of automated tests. And having at least basic understanding of what makes code easy to understand and easy to maintain.
I've been involved in several projects where almost everybody screamed "we need to rewrite everything" and actually taken part in a few projects where software was rewritten from scratch. And a few times it actually turned out fine. Which made me think since there are so many voices saying a complete rewrite always is a bad idea (Uncle Bob, Joel, Chad). So I just spent a few minutes thinking about my own experience since I was under the impression I actually had experience of a successful rewrite. But everyone is saying that is impossible.
So the first rewrite I've experienced was a two man project where we wrote a prototype/proof-of-concept, threw it away and then wrote a first version. That version was never used by the end users and we pretty soon found out that we've made a major design flaw so we rewrote it a second time. That version finally made it to the end users. I consider this a successful rewrite but was it? I'm a firm believer that you should not reuse code written for prototypes. So that is not a complete rewrite. And rewriting the second time could be done in a week since we noted the design fault pretty early. And even then we reused some code so the rewrite was actually a really large refactoring now when I look at it in hindsight. So that turned out to not really be a rewrite after all... Doh!
But in 1999 I was involved in a project where we rewrote a system that was not Y2K compliant. But then we did not just rewrite to have the same functionality. The rewrite included lots of new features and completely changed how the users worked with the application. So we did not really rewrite the system. We built a complete new, much improved application that was not only Y2K compliant, it was a much more efficient and powerful application than before. So when I look at it in hindsight... It wasn't a rewrite. It was a green field project.
So after thinking about it I must agree with all three articles linked above. Rewriting your application from scratch just because the design/code is a mess is seldom the best choice you can make. In stead the safest bet is to clean up your code. And this means refactoring your code. In the end you might have refactored everything but don't start from scratch. But still if you plan to completely change the way an application works and add a bunch of new features, then you might benefit from starting from scratch. But don't cal lit a complete rewrite. Because it's not.
The other day I learned a new word. I've heard about code owner ship and collective code ownership before but I've never heard of code stewardship before so I looked it up. At first glance I think code stewardship sounds very much like code ownership. The subtle difference that the ownership is collective but one person is responsible for a certain part sounds like code ownership in my ears. Searching for discussions on code stewardship I stumbled over this discussion. From that discussion I can only draw one conclusion; it depends on what you mean with code ownership and code stewardship if it is a bad thing or not.
However I do not share the opinion that stewardship pinpoints a fact that is bound to happen anyway i.e. that some developers will gravitate toward certain areas and that this is generally a good thing. Developers will probably gravitate toward certain areas if they're not careful, that is an undisputed fact. But that is generally a bad thing in my experience, not a good thing. Even if I accept the fact that stewardship have certain benefits over ownership I still don't see how it will beat the benefits of collective ownership. I'd rather say that code stewardship is a step on the way toward collective ownership and as such it is valuable.
In the talk against collective ownership I've heard arguments that teams delivering APIs can't have collective ownership because the API will be inconsistent. But this is just a sign that you look upon APIs differently than for example a GUI. You will use usability experts and end users to make sure a GUI is consistent and easy to work with. You should do the same thing with an API. So collective ownership does not allow you to make a bad interface regardless of what that interface is. Collective ownership means that everybody on the team is responsible and should be encouraged to make changes wherever is needed. It does not mean individuals can do whatever they want trashing your product.
Continuous integration (CI) is generally considered a good thing. And there are some hard facts out there. And I agree that it is hard to find a situation where CI does not add value. I guess the only case where you would opt to not use CI is when the cost outweighs the benefits. In my mind that is when the build time approaches hours. Because the classical CI scenario uses CI to verify check-ins and if your check-in breaks the build you get right back to fix it. But if the time between check-in and feed back is too long the developer will probably have lost focus since he (or she) has started to work on something new. Also in a large team (or several teams working on the same code base) a build failure might interrupt a number of developers since it might be unclear exactly what change broke the build.
Gated check-ins to the rescue. A gated check-in means that a build is performed with one set of changes from one developer and if that passes those changes are checked-in. This means that breaking changes never get it into the code base which I think is a good thing. Especially if it saves time as a whole. This is a feature that is available in Teamcity but does not exists in TFS 2008. Gated check-ins are however supported in TFS 2010. There is however a tool that adds gated check-ins to TFS 2008 - BuddyBuild.
So if you use gated check-ins I can no longer find a single scenario where CI does not improve your development process.