Planetarion Forums - Software engineering

Structural Integrity · 9 Mar 2005, 15:37

Some of you might know already that I'm working on a spaghetti-software-package originally programmed by my boss and a previous programmer. I'm trying to track down a bug ATM that results in wrong numbers in some hour calculations. The algorithm goes through three functions (calling many more smaller functions throughout the execution path) with each about 250 lines of code (give or take a few) and I'm really lost. I can't possibly figure out what the hell is going on in these functions let alone find the bug.

This thread is not about my bug or the package, but about how software engineering could create code that is better understandable for a programmer. If this software would have been decently designed, I would have been able to track down the bug much more easilly.

I believe that if you design a system with a perfect static architecture, with a perfectly logical dynamic behaviour, you can let your 10 year old niece program it (assuming she has a basic knowledge of programming) and have her track down problems in the system if there would be any at all.
So why don't companies spend more attention to the design of a system if it can save so much time and resources in implementation and maintenance?

So the points are:
"Is software engineering a viable tool to get away with hiring stupid/cheap programmers?"
and also a bit:
"Are you a bad programmer for not being able to understand complex pieces of code?"

DISCUSS!!!

ceres · 9 Mar 2005, 17:21

Formal Methods solve all of these sort of problems.
________
Club Royal Condo Wong Amat

Tactitus · 9 Mar 2005, 22:08

Quote:

Originally Posted by Structural Integrity

So why don't companies spend more attention to the design of a system if it can save so much time and resources in implementation and maintenance?

Because implementation and maintenance costs are in the future.

Structural Integrity · 10 Mar 2005, 10:43

Quote:

Originally Posted by Tactitus

Because implementation and maintenance costs are in the future.

When I see what the maintenance of this package costs compared to the actual development, it would've been much wiser to design things properly.

I can very well understand that it's important to cut down on the time-to-market time and thus omitting an extensive development cycle and take the increased maintenance costs for granted. But with the increased customer demand for "working" software (what I'm noticing) and ever increasing competition in the same sector by the big players like Microsoft and SAP who are expanding their horizon, I believe it's business-wise unwise to bring architectural faulty implementations on the market. With this market you have to compete not only in TTM and price (which can be brought down with a decreased mainenance cost IMO), but also on reliability, servicability and expandability of your package. And you simply can not do that with a poorly designed system.

This is kind of off-topic compared to the original statement, I know, but I just wanted to comment on that.

Anyway, is software engineering a viable tool to cut down on implementation costs at all? It's obvious that it helps in improving servicability and expandability, but does the decreased time/costs in implementation justify the increased time/costs in design?

NEWSBOT3 · 10 Mar 2005, 10:45

Quote:

Originally Posted by ceres

Formal Methods solve all of these sort of problems.

ahaaha

hahaha

ahahahah

ahahaha

hahah

hehe

heh.

ah.

good one.

what are you a compsci 1st year ?

Raging.Retard · 10 Mar 2005, 11:55

Quote:

Originally Posted by Structural Integrity

So why don't companies spend more attention to the design of a system if it can save so much time and resources in implementation and maintenance?

Simply because .. upfront it will cost more. Sure maintenance costs may be saved 'down the line', but as has already been pointed out.. thats down the line. In a considerable number of real world projects by the time you get to this arbitrary point, the requirements for the system could have completely changed anyway. It may be the case that the whole thing is no longer needed or needs rebuilding.

Sure making a 'good future proof' system is what you should aim at... but getting the balance between the initial development time and future maintenance is an art. Even on the better designed systems, far more money ends up being pumped into maintenance anyway. I believe the figure is that 80% of the cost of a (generic) system comes after its implementation. This is simply because the goal posts move too often.

meglamaniac · 10 Mar 2005, 11:58

DON'T EVER MENTION FORMAL METHODS AGAIN!
EVER!

ARGH!

ceres · 10 Mar 2005, 14:23

Quote:

Originally Posted by NEWSBOT3

ahaaha

hahaha

ahahahah

ahahaha

hahah

hehe

heh.

ah.

good one.

what are you a compsci 1st year ?

Formal methods are logical prove your design before you move into development.

And no, i finished my computing degree over six years ago.

sonny.
________
Vaporizers Info

NEWSBOT3 · 10 Mar 2005, 16:08

Quote:

Originally Posted by ceres

Formal methods are logical prove your design before you move into development.

And no, i finished my computing degree over six years ago.

sonny.

shrug.

you imply that formal methods are some kind of miraculous solve-all solution, which they are not.

ceres · 10 Mar 2005, 16:31

Using formal specification early on in any project will solve a plethora of problems which would normally be encountered later on in the life cycle.

Every software project i have commissioned has made extensive use of formal methodology and every one of them has come back under or matching budget and met every requirement of the client.

I'm assuming by your initial reply to my post that logic isnt something you encounter very often.
________
xLIttleWetPussy cam

queball · 10 Mar 2005, 17:50

It's not relevant. Struct is happy with various tools being able to make code easier to deal with. The question is whether they just make up for incompetent programmers.

Struct, that's obviously not the case, but you have to accept that other, possibly more mathematically inclined, programmers are likely to write spaghetti code because they have different skills from you. Of course the ultimate programmer would be able to understand arbitrarily difficult code, and produce incredibly useful code. And the ultimate baseball player might make great throws and catch every pass.

I would consider it a failure if I was stumped by code I'm supposed to be able to understand, particularly since I pretend to be interested in reverse engineering. On the other hand, I generally don't worry too much about whether my code is readable, though I do appreciate simplicity. You'll know whether understanding difficult code is something you're interested in.

If you tell your boss "this code is unreasonably complex, it will take me a long time to understand it", then, well, he might understand, I dunno. If you really need to judge yourself, maybe you're more of a thrower than a catcher. "You are not expected to understand this"