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.

Perfection - or the 80/20 rule...

Ok, so you need to write a really small app (lets say C# as that's what I'm doing). It's for ONE user (it's to run automatically overnight) - and it's an "in house" app so no deployment issues.

It needs to import 5 or so text files into a database.

As I see it I can write this in a very short time by doing it very procedurally :

GetFileName (from config file)
ParseFile (filename - with some logic in here to change parsing method depending on filename)
SaveFIle to database


I can write an abstract class which deals with a file, 5 child classes each of which knows about how to parse itself, then use reflection or something (based on config file into) to decide what class to create...

At the point we need another file I either amend the config file and the ParseFile method to deal with it, or create another class...

My feeling is that the first method (may not be pretty) will get the job done in about 20% of the time (no, I don't have code gen tools). Maybe I'm being unreasonable - maybe it's 50%.

So - do I feel bad for doing it the bad old procedural way - or good about getting it done quickly?

I suppose this is really a general question - given the choice between providing 80% (or all) of the functionality in a much shorter time by doing it "badly" do you do that? (by badly I mean code that works, has error handling etc but doesn't use the newest exciting objects/design patterns etc)

Another Contractor....
Wednesday, May 10, 2006
P.S. It's a rewrite of a system in VBA that already does this - hence why I'm looking at it procedurally in the first place!
Another Contractor....
Wednesday, May 10, 2006
Why's the VBA system being rewritten?
John Topley Send private email
Wednesday, May 10, 2006
So that it can be automated - I can't put a spreadsheet on the server and have it run from Autosys! (and because I'm bored so I am actually going to do it properly - but the question still stands)
Another Contractor....
Wednesday, May 10, 2006
I think you can make a distinction between an application and a script (even if both are in the same language).  This is a script.  There's much less need to worry about proper software architecture in a script.  The question, of course, is whether there's any likelihood that the scope will grow -- will it eventually be more files, multiple tables, etc.  The worst thing is building it as a script, and then finding out later it needs to be an application.
Jacob Send private email
Wednesday, May 10, 2006
Good definition - thanks!

That's about my feeling - there are apps which you know are apps, there are things that you are pretty sure are just scripts. I do quite like the YAGNI principle (you aren't going to need it) - i.e. write it as a script until it's obvious it's going to grow! At some point it may need to be refactored - but delay that time penalty until it is needed!
Another Contractor....
Wednesday, May 10, 2006
First you should waste 5 hours debating what to do and then introduce as many classes as possible, because that kind of flexibility is exactly what you need in literally every application ever.

You can't achieve perfection. So why not find the right balance between time and quality.

When you buy any product, the cheapest and the most expensive product may differ a factor 10 in price. Don't assume that the most expensive product is the best buy. Realize that you're buying the most expensive product for your company. So unless your company always buys the most expensive products you should shoot for best value for money.
L. Lort
Wednesday, May 10, 2006
I have done exactly what you are doing so many times... and I think you are right to go the procedural route.

My assumption is that you are making this a console app since it doesn't sound like a GUI is needed.  If this is the case, then you have cut out over half of the design considerations and are strickly looking at functionality.

If I was looking at this and wanting to break it down into classes, it would only be to isolate the database layer from the main control function.  This would still result in an extended procedural methodology but provide you limited reuse of the database code.

Really, it is all about re-use.
Jeremy Send private email
Wednesday, May 10, 2006
AC, reuse is totally overrated. You are right - you can write a program in 3 hrs, or you can go find some reusable libraries and architect it in some fancy OO way and take 16 hours. In this case, 'reuse' isn't saving any time and is making it LESS maintainable because now the program breaks everytime those other so-called encapsulated classes change their private implementation and now everything needs to be recompiled.
Art Wilkins
Wednesday, May 10, 2006
DTS is built into SQL Server 2000 and can handled just about any database and task.

In SQL Server 2005, there is Integration Services.

Either way, this is what those tools are designed to do best, and there are other similar tools.

Unless you need to link into existing business objects for logic during the load process, there shouldn't really be any need for anything more complex.
Cade Roux Send private email
Wednesday, May 10, 2006
I say follow K.I.S.S. 

To me, it doesn't matter what you are writing, whether a script or a full blown application.  I write each piece of code to be as simple as possible, without overdoing it.

I've found when I've hacked something together "because I'm never going to change it", I've had to change it.  Furthermore, I wind up either hacking in the change, or practically rewriting it to make it understandable.

So I would just follow good programming practices. Keep it simple, refactor as necessary.  Worst case, you never modify the code.  Best case, you don't have to rewrite it to change it
Another Anonymous Coward
Wednesday, May 10, 2006
"You are right - you can write a program in 3 hrs, or you can go find some reusable libraries and architect it in some fancy OO way and take 16 hours"

LOL - that describes some of the apps here perfectly. THey are so over architected with Factories here and Interfaces there that you can't actually work out which bit of code is going to run until you do it!! Plus there are multiple classes doing almost the same things...nightmare!!!
Another Contractor....
Wednesday, May 10, 2006
Another vote for procedural and K.I.S.S.... overengineering something is usually worse than underengineering it.
Joe Don
Wednesday, May 10, 2006
Have base class the you derive from to implement common parsing file handling functions.

Then create a class per different parsing/handling.

If they are all different you'll need 5. If some are the same then parameterize them with constructor arguments.

Then instantiate them by hand in your script. No need to reflect or anything magic.

This is both clear and allows for sharing what is common and factoring out what is different. You could do the same procedurely, but you probably wouldn't.
son of parnas
Wednesday, May 10, 2006

If it's only five types of files, I would just do five different scripts. I think it's only worth implementing the classes if...

a) You're going to use it again in the future, which seems not to be the case, or

b) You're going to be working with 20+ file types to the extent you'll spend a lot of time just cutting and pasting the code between files.
Wednesday, May 10, 2006
Son of Parnas - why do it as classes? Why not just have separate functions for the parts that are common (eg copying the file from FTP sites etc) and a whopping if statement for the bits that are different (you get the idea)...what do I gain by having a base class plus n child classes that I don't get from writing it procedurally?

with classes I have:
If filename = "abc" then obj = new abchandler (some long list of paramters)
else if filename = bcd then obj = new bcdhandler (more params)
else if....etc


Otherwise I have

openfile (filename)
if filename = "abc" then parseabc(filename)
else if filename = "bcd" then parsebcd(filename)
else if....etc

What am I missing?

(trying to understand here...not being rude!)
Another Contractor....
Thursday, May 11, 2006
having don almost exactly the same job (with dirrefent files naturally) i used to have a cludge in VBA (access), it worked, but was slow and lacked error handling.

Didn't matter on I ran it.

its since been replaced with a nice application to do exactly the same job, its a hell of a lot faster (i dare say the vba could have run faster too), but the main reason was to allow my manager to run it. now its a case of 'double click this icon, then press "import"', even he can do it. plus it can be run automatically via a task scheduler.

the basic application has a class for each file, since they are generally different and a basic class of common routines they all use. the gui simply triggers the various xx.import(filename) functions, and provides a status bar etc for some feed back.

I'm thinking of another re-write this time with threads, and a few gui improvements (like labeling the status bar...), not actually needed except the gui improvements, but what the hell I have the time and I'm justifing it as a 'learning process' (I'm not a coder by job title).

but as to the 80/20 bit, the vba cludge was written fast and ran slow, but it was needed 'yesterday' when it was written, I'm amazed it worked since the word 'design' didn't feature, it sort of grew.

unless what your doing involves a lot of files int he same basic format, i'd forget the common class method, and have one class per input file. changes are a lot easier that way. anything you find in more than one class can always be hived off elsewhere anyway.

rule i find tends to be:
step 1: get it working
step 2: improve the working model, if its worth it

plus its generally easier (i find) to get the time to do something right once the basics work, as people are going to add 'can we make it do "x"' anyway.
Claire Rand
Thursday, May 11, 2006
Can you move it from VBA to VBScript ?
John Griffiths Send private email
Thursday, May 11, 2006
There seems to be a certain minimum size below which OO is something of a waste of effort.

As I look at your app, the only thing that might be worth doing OO is encapsulating the parsing.
dot for this one
Tuesday, May 16, 2006

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

Other recent topics Other recent topics
Powered by FogBugz