Fog Creek Software
Discussion Board




Bridging gap b/t high and low level design

Howdy folks,

I'm redesigning a bunch of commercial shrink wrap  programs that I wrote over the last 9 years.

I wrote one program then stretched it to two and then to three, adding more functionality and twists, etc.

Now I'd like to rewrite them with a more logical architecture.

But...

I'm having a really difficult time thinking about this a the right design "level".  If I sit down and code in detail I'm fine.  If I spec out at a very high level, I'm fine.

But, it's coding at perhaps the procedure level that I'm having trouble with.  Can't seem to sink my teeth into it unless I get down to a low level of implementation.

Is this a common problem?
Any suggestions?

Mr. Analogy
Monday, June 14, 2004

Yes it is common. It's very hard to be able to
effortlessly go up and down the different
abstraction levels. But do you really need to?

Worry about the code when you get to the
code. Code always reveals holes, but that
will be the case regardless of your level
of effort. Decide what's important. Get the
big things right. Start coding with unit
testing. Repeat as necessary.

son of parnas
Monday, June 14, 2004

>Now I'd like to rewrite them with a more logical
>architecture.
>
>But...
>
>I'm having a really difficult time thinking about this a the
>right design "level". 

I assume that 'more logical architecture' means that instead of nine applications you want one.

Think about what is common between your nine applications (in terms of data, user interface elements).

you can make a host application that contains the other applications as plugins.
Now you have a problem when the plugins have to communicate.

So it's back to analysing what they have in common, what is separate, and how they have to interact.

Michael Moser
Tuesday, June 15, 2004

Do you really need to rewrite it all? Can you refactor piece by piece instead of ripping up everything at once?

I always find it painful to look back on code I wrote a few years back and think "Wow, I was such an idiot, I can't believe I did it *that* way"... but from a business perspective, if the thing works, I think you should really ask whether a rewrite is warranted. Will the benefits you gain in future extensibility, maintainability, etc. really make the effort worthwhile?

John C.
Tuesday, June 15, 2004

"I think you should really ask whether a rewrite is warranted. Will the benefits you gain in future extensibility, maintainability, etc. really make the effort worthwhile?
"

It's written in VB 3 (16 bit programming language).  Language hasn't been supported for over 5 years now.

Also, I can't make 32 bit API calls. 

And I suspect that the next version of Windows won't support 16 bit programs (at least not well).

So, I'm not just rewriting on a whim.  But, it's a good question nonetheless.

Mr. Analogy
Tuesday, June 15, 2004

So, I assume you are porting to VB6?

I recommend the Appelman book on the Win32 API -- it should help you translate some of those 16-bit API calls to 32-bit.

Also, "Hard Core Visual Basic" -- again, how to effectively use the API.

And to your original question:  I'm very fond of the 'Structured Analysis' -- Data Flow Diagram (DFD) to Structure Chart school of software design (though it's a little dated now).  Even there, converting from the High-Level DFD to a structure chart (where each subroutine was a box on the chart) was not straightforward.

DeMarco recommended the 'grab the central transform and shake' method -- where the central transform becomes your 'main()', or close to it.  In-flowing modules then get called first, and out-flowing modules last.

Of course, with VB and windows you also have the 'task-model' -- what tasks do I want to define, and what screens do I need to create to enable those tasks.

AllanL5
Tuesday, June 15, 2004

One other approach toward this is the Extreme Programming one.  Design the high-level, code the low level as seems appropriate.  When the low-level gets crufty, re-factor the low-level into less crufty subroutines.  Then update the design to reflect the low-level insights.

I find my insight into how the program can be effectively laid out is helped by actually trying to code it.

AllanL5
Tuesday, June 15, 2004

*  Recent Topics

*  Fog Creek Home