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.

compelling reasons for modular designs

I'm a statistician working at a new company. Statisticians are not really taught anything about software design, just syntax. Also, the most popular statistical software doesn't promote good design…

I've inherited a software project that is a bit of a mess, but is functional most of the time. It is in a semi-production environment (nothing having to do with clinical trials). The software is written in R, which is a great language and supports good software design (e.g. it has testing frameworks, good scoping, libraries and lots of other things that most java or python people take for granted). None of the team supporting it have ever worked in a commercial production environment and tend to use the bar of "it worked for me" for a lot of things.

The problem is that the code consists of a bunch of functions that are essentially long scripts with very wide scope. I'm convinced that it needs refactoring (mostly modularization and scope reduction), which would be pretty straightforward, but take up a good amount of time. I'm having a hard time coming up with a compelling reason that will convince them that it is a good thing to do proactively.

Does anyone have advice on convincing people who code a lot (but don't think about good design) *why* the extra time would be worth it? I've looked thru my editions of Code Complete (especially the chapters about modules and routines), but haven't gotten much on why it's a good idea sitting in their shoes ("It works right now, what will I get out of it?")


Max Send private email
Thursday, September 01, 2005
Generally, if code is working fine even though it's ugly, and if I don't *need* to change it, then I don't change it: i.e. I don't refactor code merely in order to refactor it.

I am more willing to refactor it, if it's not well-factored AND if I need to change it for any other reason, e.g. to fix a bug or to implement a new feature.

I don't usually expect an employer to pay me when my *only* output is better-factored code: they pay me to implement new features or to fix bugs (and to leave well-factored code behind me) ... in other words, I bury the cost/effort of any refactoring within the cost of fixing the bug or implementing the feature.

Oh, the compelling reasons for 'modular designs' are possibly:

* Easier (quicker, cheaper) to add new features and/or to fix bugs
* Easier (quicker, cheaper, more thorough) to test
Christopher Wells Send private email
Thursday, September 01, 2005
* Easier (quicker, cheaper) to be learned by the new guy / old guy who's been far from the code some time
Ross Sampere Send private email
Thursday, September 01, 2005
It's easier to figure out if small chunks are doing the right thing than if great big chunks are. (If it's already doing the right thing, though, I'd be scared to touch it.)
dwayne Send private email
Thursday, September 01, 2005
Ask for a bunch of changes. Let them estimate the time and do the work. When they say it will take a long time because of X or it has a lot of bugs then that's your If neither of those things happen then they are probably right.
son of parnas
Thursday, September 01, 2005
For me, it's often boiled down to The Pragmatic Programmer book's DRY Principle:


That's really the goal.  And modularity facilitates that.

If the same code appears in N places, it takes N+1 times the effort to test, debug, fix, and document. Example: We have 20 programs. If each program had it's OWN splash screen, about screen, etc. it would be 20 times the work and one more unit of effort to make sure it's all in sync. Every change to the Splash screen would be 20 changes to code, 20 testing iterations, 20 changes to manual (b/c if each program has a unique ui, it needs a unique manual)

And coding is really only 30% or so of development time.  So, by making coding a little harder, you dramatically reduce the effort in the other 70% of the project tasks.

But this goes unrealized. Why?

Because most companies don't test (much) and throw the product over the wall to poorly paid tech writers. So the costs of duplicated features is hidden.
Mr. Analogy {uISV} Send private email
Thursday, September 01, 2005
Another reason for modular design is human comprehension. It's a lot easier to wrap my head around ten 10-line functions than one 100-line function, especially when looping or conditions are involved.

That's true when I examine my own code, and it's even more apparent when I examine someone's else's code. Code that's easier to understand generally requires less effort to maintain and has fewer bugs.
Friday, September 02, 2005

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

Other recent topics Other recent topics
Powered by FogBugz