The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Looking for references on maintaining large code bases

I'm really having trouble finding some good reading material (books, blogs, etc.) on this topic. Could anybody help me out? The topics I am interested in include:

* Arguments for refactoring existing code to fit in your new code (difficult, because you don't understand the code written by others and it looks like a mess) as opposed to just adding your partly redundant code somewhere.

* What good is it if I spend a lot of time reading, understanding and refactoring existing code if everybody else keep pumping out unmaintainable code at an alarming rate?

* How to get a group of unorganized and unmotivated developers to produce a consistent code base (the consistency of the .NET Framework amaze me).
(anon)
Wednesday, September 20, 2006
 
 
Micha Send private email
Wednesday, September 20, 2006
 
 
Working Effectively with Legacy Code - Michael Feathers
Mike S Send private email
Wednesday, September 20, 2006
 
 
> Working Effectively with Legacy Code - Michael Feathers

What do you think was my link for?

:-)
Micha
Micha Send private email
Wednesday, September 20, 2006
 
 
I should mention that I have that book, and was in fact flipping through that as well as "Refactoring" just before writing the original post.

Those are indeed great books. Especially "Legacy" is great because it focuses directly on handling the real world mess that most of us are involved with.

However, both books are directed at the individual seeking to improve the code he works on. I would like to see a book, a blog or a forum where the topic is more about how to get the entire organization to think along these lines.

I can refactor code all day long, but the mess is still piling up as long as everybody else keeps producing crap.

The problem isn't solely about educating developers (though that may indeed be the major issue), but also with finding acceptance elsewhere in the organization about spending time on work that isn't fully aligned with meeting the current deadline with the least amount of work.
(anon)
Wednesday, September 20, 2006
 
 
As for getting developers to generate conformant code you can use fxcop for .Net stuff, it'll generate reports when people fail to meet the standards. There's also a .Net framework guidelines book, make 'em read it. It's not the silver bullet, but it can help.
Jason Moore Send private email
Wednesday, September 20, 2006
 
 
> but also with finding acceptance elsewhere in the organization about spending time on work

Personally, I never found it (with one exception) as a companies real policy. Some things might be different (because my market is Europe). But I'm in business for 10 years now from hands-on programming up to what could be called 'technical project management'.
No luck so far. In the moment your work begins to touch management, things change fundamentally. I don't think, that any systematic approach works very well in this case. It is simply ego jungle, so it's all psychology, networking etc..
One of the reasons, why I'm very happy with my contractor/consulting position - and perhaps a reason too for the missing of 'substantial' material in the sense, you are looking for.

Micha
Micha Send private email
Wednesday, September 20, 2006
 
 
Jason, yes FxCop will probably help with coding conventions and even design issues to some degree. What it cannot help with is getting developers to integrate their new logic into existing code, by reworking it as a consequence of changed requirements, as opposed to just patching on some new and partly redundant code somewhere because that is the easy way out (no need to understand the other code, and no fear of breaking anything).

I like to think that any software change should aim to fulfil the new requirements without adding more entropy than the inherent complexity of the new functionality dictates. That means constantly refactoring/redesigning as new design insight is gained. This reminds me of another GREAT book: Domain Driven Design. Such an approach unfortunately means a higher short-term development cost. The fact that this is regained many times in long-term cost doesn't seem to convince very many, not even developers.

Imagine if there was a way to measure the complexity of a requirement specification and then the complexity of the code base. Then we could simply reject all code submissions that added significantly more complexity than the change in requirements would indicate.
(anon)
Wednesday, September 20, 2006
 
 
By the way, I found a great reference further down:

http://discuss.joelonsoftware.com/default.asp?design.4.379733.26

Also, http://sel.gsfc.nasa.gov/website/welcome.htm is a gold mine!
(anon)
Wednesday, September 20, 2006
 
 
> and perhaps a reason too for the missing of 'substantial' material in the sense, you are looking for

Micha, I think you may be right. In that thread I pointed to above, about the space shuttle software, someone says that is a great victory for up-front design. And you couldn't hand the project to some kids and tell them to go agile. Makes perfect sense, of course. Problem is, this approach only seems to work when your budget is endless. Which may explain why only 4 companies are at CMM level 5.

Does this mean that, despite NASA's success, any real-world shop with a real-world budget will have to do things fundamentally differently? Maybe. And could the real-world solution be agile? Maybe. I certainly don't know.

I wish I knew, though. In fact, the one thing I would really, really like to have is detailed documentation of a process that works, like NASA's, except that it has to be successful for real-world software vendors with a budget. Is RUP the answer? MSF? Something else?
(anon)
Wednesday, September 20, 2006
 
 
I would like to point you to the following article from
IEEE Trans on Software Engineering:

http://doi.ieeecomputersociety.org/10.1109/TSE.2006.42

It relies on work in a special corporate environment with long software histories. Being technical, you will nevertheless almost immediately spot the authors emphasizing of soft factors. It shows that also very old-fashioned Fortran code can remain highly alive in a suiting culture.

Micha
Micha Send private email
Wednesday, September 20, 2006
 
 
> Such an approach unfortunately means a higher short-term development cost.

Perhaps that implies that the decision should be made at the management level: i.e. the managers need to tell the developers that they prefer the possibly-higher-short-term-cost solution.

After you have management buy-in, the only method I know of to try ensure/verify that new submissions also include any appropriate refactorings (if they're not already happening as a matter of course) would be peer design reviews / code inspections.
Christopher Wells Send private email
Wednesday, September 20, 2006
 
 
> How to get a group of unorganized and unmotivated developers

That's a people/management problem, isn't it, not a software problem.

> How to get a group of ... developers to produce a consistent code base (the consistency of the .NET Framework amaze me).

Perhaps there's literature about Microsoft's development process (I've heard that the software developed there is peer-reviewed).
Christopher Wells Send private email
Thursday, September 21, 2006
 
 
+1 (or more) for peer review
hobit Send private email
Saturday, September 23, 2006
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz