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.

Design in regard to Write-Once Applications

Often in this Industry we find ourselves in the unenviable position of having to write something 'thats maintainable'.

Which means, dont confuse management with a proper OO design, just do it all like a VB6 application so we can feel confident our guys can support it. It will never need major changes so keep it simple (ie dumb).

Pragmatically speaking this should be ok, but it feels soo wrong. Is it really that short-sighted? Should ALL software be well designed?

Thoughts?
Lyndon Send private email
Thursday, March 16, 2006
 
 
> Which means, dont confuse management with a proper OO design, just do it all like a VB6 application so we can feel confident our guys can support it.

Why does a well designed application imply 'proper OO design'. You CAN have a well designed VB application. Just because it cannot comply with all the theoretical requirements for proper OO, does not make it a bad design.

> Pragmatically speaking this should be ok, but it feels soo wrong. Is it really that short-sighted? Should ALL software be well designed?

It is comercially short-sighted to try and enforce an over-designed application onto a scenario that does not call for it.
Adrian
Thursday, March 16, 2006
 
 
Who says that's "bad design"?

One of the biggest factors after "does it work?" is that the software be maintainable by someone.

Beautiful skyscrapers of code are often not the right solution. They are, if they work well, if not, they can be terrible requiring people to have to dig deep into the problem (read Joel's piece on leaky abstraction).
Tim Almond Send private email
Thursday, March 16, 2006
 
 
One of the skills in software design is coming up with solutions that are just flexible and open enough for the future, but not too complex or over-burdened.

You should design for the task at hand.  Some problems require large-scale (perhaps OO) architectures, some don't.

If I get a request to write a script to flip the last-name and first-name in a text file because some supplier put them in backwards, I don't spend days of effort on it.  I'll code it nicely, maybe make it flexible enough so that you can specify the column where the name occurs, check it into our SCM, and then move on.
Perl Solution
Thursday, March 16, 2006
 
 
"Is it really that short-sighted? Should ALL software be well designed?"

I lean this way most of the time for the simple reason that if the tool(s) work, someone will want to use them again.

I can't even count the number of times I've heard "Oh, this will be a one-time conversion/project/etc only to get 80% complete and find out that either a) this is going to happen multiple times with slight variations or b) the tool makes sense to another customer's project".
KC Send private email
Friday, March 17, 2006
 
 
I wonder if you are being facetious.

I cannot recall one thing I've ever done that wasn't extended at some point.

I prefer OO for webapps but that is no promise all is well.  The odds are better though.

For shell scripts I simply use modular code. I use Perl so I use CPAN extensively and use modules but the core of the shell script is a simple main with a limited set of functions  using modules whenever possible. The core is not OO.

In all cases I expect the code to be extended so in PHP I use error_reporting(E_ALL) and in Perl I use taint,warnings, strict. Those simple things go a long way. If I were really good I'd write unit tests.

Friday, March 17, 2006
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz