CodeCleaningCompanyDiscussion

Context : CodeCleaningCompany

I just grabbed a dump of the discussion of my code-cleaning company idea from the Joel on Software, MicroISV forum :

IMO, the definition of "clean code" is quite dependent from the future development plans. As Joel is pointing out in his own article, dirty (but correct) code does not matter as long as you're not trying to change anything. Yet, future development plans are one of the most uncertain things in software business.

Then, good code cleaning takes good developers. Those people tends to be much more expensive than the ones who did produce the crappy code in the first place. If you can't afford talented people upfront, it seems unclear to me why you would be able to do so later on.

Just a guess though, Joannès

Saturday, September 15, 2007

How about going with the http://topcoders.com model? You have contests to refactor the code. Then other developers get to vote on whose code is the most maintainable/readable/etc. It could be a lot of fun, and if you had enough developers interested you'd guarantee a certain amount of quality.

E-Tech

> Could "code cleaning" be a small service business?

In order for there to be customers for such a business, a person with spending authority in an organization would have to:

• Be aware of source code
  • Decide that poorly factored source code is a problem
  • Decide that there is personal gain in having the code cleaned
  • Decide that cleaning the code provides the highest ROI of all the possible ways to spend money
  • Decide that the work should be done offsite by an outside firm

Brian/DC

Joannes : a lot of the things Joel talked about looked pretty mechanical to me. I agree that you can't separate coding from strategic design, but I think that there is some cleaning which could be distinguished. Certainly for a web-app. making sure the HTML is standards compliant. Or for any app, that all language texts have been extracted to a separate db.

Brian : Sadly, I think that's the main obstacle.

phil jones

>IMO, the definition of "clean code" is quite dependent from the future development plans.

+1

On top of that it seems inefficient to give a bunch of code to someone who has never seen it and expect them to create better code. They would have to dive in and become 100% familiar with it if the changes are to be bug-free. Now imagine they do that successfully and as Joel did they change each line in the code. Now it's returned to the original devs who have to dive in to this unknown code where everything has changed and get familiar with it 100% befire they can make useful changes again.

This doesn't sound like a very good deal.

I think scrubbing and tidying up and refactoring are an in-house thing. I do it once in a while when I feel a portion of my good has gotten out of hand and I know I will be working on it in the near future.

Oliver

Oliver [snip] If you start with the rule that you aren't making functional changes, just simple mechanical transformations that don't affect the semantics of the program, why should "clean" depend on the direction you intend to take future functionality?

phil jones

Hi,

It sounds very unlikely that someone would want to clean up old code that way. Even if they did, it's a business model that doesn't scale: as business grows, you need more and more bodies (developers).

And from a corporate point of view, touching legacy code is extremely dangerous. Even assuming you have unit tests, the risk of introducing a new bug is so high, that it's not worth the clean-up. The old code has been through years of production and still works. The cleaned-up code is brand new: what if it breaks during a live, critical application?

The FairSoftware Guy

Fairsoftware : I'm not thinking of really legacy code. I'm thinking of the sort of situation which a lot of developers get into : you have a huge code-base for your product, all of it a bit crufty, and a few modules under active development for the current customers. You know you really need to take some time to clean it all up, but I can't because your developers can't be spared.

OK, so if you were a good software company, you would find the time. But, as I'm sure you know, plenty don't.

phil jones

Phil Jones I definitely read Joel's article, and with great interest. About two thirds of the way down there is a bulleted list of the things he did. There are items in there that I agree could be taken care of by an external company, like extracting all language to a db, all styles to CSS, and making the HTML compliant. But there are much bigger things: he created new classes, moved the business rules out of the presentation, and restructured the ASP site altogether. He even says "The structure is completely different."

I would not make such changes without an eye to the future.

Besides, think of it this way: there is no need to clean the code if it works and you do not plan on adding any features to it, right? So the major motivation to clean the code is that new features are to be added very soon. It seems to me the most efficient way to do that is to get the programmers who are going to write the new features do the cleaning in preparation for writing the features. They know better than anybody what they are going to need.

Final thought: as you know this is predominantly a mISV forum, where 1 person writes code and sells a product. As a result I/we are much more likely to be control freaks wrt our code. You might be able to sell such a service to the kind of company that hired and Indian IT firm to crank out a bloated pig and promise to bring that code to a maintainable state.

Oliver

It's called "Employee #2"!!!

Bring in a person for trials. Make it explicit to her/him that you are not just interested in sharing the company culture but also very interested in what best practices she thinks is high-time after reading your crufty code. See if you can internalize what she has to say and own the change. After all, as a MicroISV, you know the code best–and it's clearly cheapest in person-hours for you to work on it yourself. Work with her to review your changes and see if she approves of it.

Li-fan Chen

Oliver :

OK, I'm going to agree with you to a certain extent. What interests me here is the role of code-cleaning and the possible space of ways you can share work between different organizations. I'm not going to advocate an excessive form of this, and your criticisms are well taken. Obviously the original developers have to be supervising the cleaning with an eye to the future.

OTOH, I think the whole point of what Joel is saying (and something I think is in the spirit of an agile technique like, for example, test-driven development) is that there are kinds of housekeeping and redundancy-elimination which can improve your code, but can be done purely based on the local information of the code you have now, and not trying to second-guess where you want to take it.

If you think you should never touch or refactor code without some further change in mind, that's tantamount to saying you're only going to work on it as part of adding new functionality.

Here's the interesting Joel quote on class design :

[quote] Removed all SQL statements from the presentation code and indeed all program logic (what the marketing types like to call "business rules"). This stuff went into classes which were not really designed – I simply added methods lazily as I discovered a need for them. (Somewhere, someone with a big stack of 4x6 cards is sharpening their pencil to poke my eyes out. What do you mean you didn't design your classes?) [/quote]

I read this as him saying he "clustered" his extracted methods in objects based more or less on where he found them, rather than stepping back and doing any serious design work to figure out what classes there should be and how they should relate.

This, obviously, doesn't give the best design, but already makes the code more amenable to someone else (one of the core designers) moving stuff around as part of the next development step.

Finally, yep, I can see that MicroISVs are unlikely to be customers for this kind of thing. OTOH, I can imagine, if you could work out how to market and sell it, it as a small consulting type business that could work for larger software companies. I'm assuming people here are interested in different business models for selling programming skills.

phil jones

"Besides, think of it this way: there is no need to clean the code if it works and you do not plan on adding any features to it, right? So the major motivation to clean the code is that new features are to be added very soon. It seems to me the most efficient way to do that is to get the programmers who are going to write the new features do the cleaning in preparation for writing the features. They know better than anybody what they are going to need."

And if they do not, they will find out. (Looking at it from the point of view of what they need the code like to work on it effectively.)

Sincerely,

Gene Wirchenko