* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Code Cleaning Company?

Here's a thought.

I was re-reading this a couple of days ago :

http://www.joelonsoftware.com/articles/fog0000000348.html

as I'm trying to persuade the overworked developers in the place I work to take some time out for this kind of cleaning.

And it occurred to me that there could be a market for specialist code-cleaners. After all, you have specialist office cleaners instead of making the clerical staff take the Dyson around after work. Why not somewhere you can outsource legacy code to simply be carefully and lovingly refactored and polished without any claim that this company are doing new development?

Normally companies from rich countries imagine they can bang out a few UML diagrams, ship them off where labour is cheaper and have it coded up. We all know that this is a fallacy (coding and designing are too tightly entwined).

But could "take my OK but ugly code, with these existing unit tests, and return it with identical behaviour but all the HTML tags closed and the variable names consistent" be a more viable way of dividing labour?

Anyone know of anyone currently offering this? Could "code cleaning" be a small service business? Maybe even part-time for people who have a few hours free each day to work from home, know how to code, but can't commit to a full development job?
phil jones Send private email
Saturday, September 15, 2007
 
 
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
http://lokad.com demand forecasting
Joannes Vermorel Send private email
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
Saturday, September 15, 2007
 
 
Oops, URL should be http://topcoder.com ... although I've never seen such a bizarre disconnect between two similar URLs.
E-Tech
Saturday, September 15, 2007
 
 
>  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
Saturday, September 15, 2007
 
 
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 Send private email
Saturday, September 15, 2007
 
 
>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 Send private email
Saturday, September 15, 2007
 
 
Oliver : I don't think you read Joel's article.
phil jones Send private email
Saturday, September 15, 2007
 
 
Actually, sorry Oliver, that last message sounded snarkier than intended.

What I mean is, 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 Send private email
Saturday, September 15, 2007
 
 
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 Send private email
Saturday, September 15, 2007
 
 
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 Send private email
Saturday, September 15, 2007
 
 
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 Send private email
Saturday, September 15, 2007
 
 
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 Send private email
Saturday, September 15, 2007
 
 
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 Send private email
Sunday, September 16, 2007
 
 
"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
Gene Wirchenko Send private email
Sunday, September 16, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz