Tobi + C# = T#

I just came across a pretty funny, or sad (?) post by Mike. Startups: Fire Your Dev Teams. Yeah, that’s what I thought.

To tell you the truth – he has some very valid points, indeed:

Seriously. The minute you’re successful, plan to rewrite your software from scratch.

That is a very good point. Even though, as the whole post does, even this quote does overshoot the target. There are EXTREMLY good points against rewriting from scratch. Nonono. Don’t. It should read: “Seriously. The minute you’re successful, plan to rewrite your software. FULL STOP”. Not from scratch, use refactoring techniques.

But the next sentence was the killer:

Plan to hire enterprise quality developers.

Now THAT’s a WTF. Hahaha. I laugh, because it is so tragic. “enterprise”-anything is a marketing term. enterprise != quality. I am seriously getting allergic to that word and the misconception it carries along. Buzzword bingo galore! Well, what did I expect on a blog called “agile thinking”. What is particularly funny is that he states “I’ve worked for two startups and consulted at several more.”. All while he is seriously bashing startup developer AND suggesting that he does indeed know better. Now that is tragically funny. Just my kind of humor.

The sad part is that most symptoms he describes are actually management related. Not developer related. No developer enjoys the death march before a presentation. Those death marches are usually managment induced. Lack of requirements, incomplete feature lists, last minute changes, lack of sticking to decisions, …

The requirements for developer don’t change that dramatically going from a startup to a enterprise. What does change dramatically are the requirements for management. Going from 10 developer to 20 is a huge step. Going to 100 is different world. All the while it is true, not all developer that “have been with us all the time” should get promoted. But even that is a management decision. It’s not the developer’s fault. Move them to those team that should open up new business areas. That’s where they belong and where they will most likely be most satisfied. And make a team of (newly hired!) quality asssurance professionals bundled with some (newly hired!) senior architects work on the legacy code base.

Good points:

• There is a difference in business goals between startups and enterprises.
• When you know you found your market, harden your business by hardening your codebase.
• Not all developers are bound to become lead-anything.

Ugly stuff:

• The title.
• Overuse of the buzz word “enterprise”.
• Blaming the developer for most of these flaws.
• Doing a complete rewrite without the old developers, that’s the evil himself.
• The three tests if you are “enterprise” or not are quite a lot of fun for all the wrong reasons.

I rarly look into the statistics ShortStats generates. But out of curiosity I klicked on it – and it promptly inspired a post. Because it showed me a very interesting search string somebody used:

“Refactoring AND Pros and cons”

Hmm, and it got me thinking. What ARE the disadvantages of refactoring. Or when is refactoring not the right way to go. Well, the pros are widly know and discussed. It helps make your code more readable and therefore helps keeping the knowledge about the code alive. Going back to your code and/or looking at unfamiliar code gets a lot easier. So this should actually speed up overall development since there won’t be to many “what is this routine doing” questions, which can take up many, many hours.

But are there situations where refactoring backfires? I really don’t know! I guess it (as always) depends. Coming from the CEO as a requirement “You have to refactor x hours a week, or loss of pay!” – well, I can see how that could backfire. Or even a “We have to refactor the next 2 weeks, because the code is FUBAR. Our code has to be 50% neater by then!” coming from the project manager or lead developer. But I don’t think that careful and small scale refactoring can hurt, ever. Just refactoring for the refactoring’s sake, that could be a problem.

I think it is even a problem of defining the term “refactoring”. What is refactoring, what is rewriting. Where do you draw the line? Hmm, I just wonder. Any comments? Who has a story, where refactoring has wreaked havoc?

I just found a book on Amazon that seems to be the database based equivalent to
Martin Fowler’s book. It is called Refactoring Databases : Evolutionary Database Design (Addison Wesley Signature Series) and I just can’t wait to get it. If it’s as well written as Fowler’s book, it will be a great source of information about database design. I don’t know about you, but I tend to learn more by reading and understanding bad examples and seeing how somebody fixes those examples.

You will definitifly hear more about it as soon as I’ve got it in my hands. But the comments on amazon are quite promising.

I bought Fowler’s Refactoring a couple of month back. And I just love going back to it and reading chapters again and again. One of the most interesting phrases used in the book is “Coding Smell”. And it is way easier to migrate legacy code, when your code is refactored and smells as little as possible.

Today I stumbled across an excellent post concerning Coding Smells at Coding Horror.

To give you a short overview of what Coding Smells are – here is a quote from wikipedia:

In the community of computer programming, code smell is a jargon term used among programmers to refer to a symptom that indicates something may be wrong. It generally indicates that the code should be refactored or the overall design should be reexamined. The term appears to have be coined by Kent Beck on WardsWiki. Usage of the term increased after it was featured in Refactoring. Improving the Design of Existing Code

Determining what is and is not a code smell is often a subject judgment, and will often vary by language, developer and development methodology.

Common Code Smells:

• Large method – a method, function, or procedure that has grown too large.
• Large class – a class that has grown too large.
• Feature envy – a class that uses methods of another class excessively.
• Inappropriate intimacy – a class that has dependencies on implementation details of another class.
• Refused bequeath – a class that overrides a method of a base class’ such that the contract of the base class is not honored by derived class. See Liskov substitution principle.
• Lazy class – a class that does too little.

Some links to articles about “Code Smell”:

• http://wiki.java.net/bin/view/People/SmellsToRefactorings an excellent article about Code Smell and the specific Refactorings per Smell that could help to make your code minty fresh.
• Coding Horror: Code Smells

There are a lot of problems converting a VB 6.0 app to .NET. So in a real life-time situation it is mostly not cost-effective to try and migrate everything in one step. Plus the programmers working on the project have to be trained in the new .NET language, C# or whatever. That calles for a slower approach. I call it Cross-Language Refactoring. The idea is to slowly replace performance critical or unmaintainable parts, while already implementing new features using the new language. Usually those new features interact with legacy code as well. So while the team is implementing a new feature, there is a chance to migrate those parts in the legacy code as well. This way the legacy code gets replaced bit by bit into the new object oriented world, while giving the team the time to get better at the new language.

I have a bit over 1 year experience in moving slowly from ASP to ASP.NET. There are a lot of problems there as well – but that would be a different article. Please feel free to contact me, if you need some pointers for that scenario. But this post will concentrate on moving a client app to .NET. Or at least start to do so.

There are two possible “slow” migration paths:

1. Building a .NET GUI and integrating the legacy VB 6.0 through dlls
2. Using the legacy interface and start replacing legacy modules by .NET modules

There are pros and cons to both approaches. The problem with the first migration path is, that it will use a lot of time to create a new GUI. On the other hand the second path will allow the user to still enjoy the old GUI and the old look-and-feel. But it is not an option when your GUI it too messed up, or is the reason why there is the need to migrate in the first place.

The MSDN-Magazin in May 2006 features an interesting article on how to make the second path possible:

Call Into The .NET Framework From Existing Visual Basic 6.0 Apps

Make sure to check it out before you are considering to migrate an application from VB 6.0 to .NET. Maybe a slow Cross-Language Refactoring approach is right for you as well.

On a different note: I would advise you to NOT move from VB 6.0 to VB.NET, but instead from VB 6.0 to C#. It turns out the programmers learning the new concept of object oriented programming, are way better at producing good code, when having a visual difference between the languages. When using VB.NET it is too tempting to use the old VB 6.0 “style” of programming and therefor neglecting patterns and oo design principles.