Roy Schestowitz wrote:
> High Plains Thumper wrote:
>
>> When I worked in software development, when we fixed a
>> bug, we didn't introduce another. A bug fix was a bug
>> fix. What it sounds like to me here is someone doing a
>> bug fix plus adding code to "improve things". That is not
>> a bug fix.
>
> Your statement holds correct when the code is properly
> built. If it is modular, you can handle compartments in
> isolation. Windows and some of its software is monolithic,
> possibly due to scale and feature-driven, deadline-inclined
> design. This issue was discussed many times before.
> Imposition of deadlines has been a real poison in
> Microsoft. It leads to morbit software reaching the public
> semi-cooked.
Deadlines are good if they are realistic. Otherwise, there's
no target to shoot for. However, unrealistic deadlines lead
to errors.
Sometimes, monolithic software is written for example, where
real time data is being collected or during process control,
where one cannot afford excessive library calls. However,
that is where a macro compiler becomes useful.
A decent design requires modularity, it makes it easier to
follow the design. In reality, it doesn't create as much
overhead as people would like to believe. A proper design
and proper coding techniques are easier to troubleshoot.
Who remembers what he wrote three weeks later? A well
documented module makes it easier to pick up where one left
off, and makes it so much easier to maintain.
Seat-of-the-pants programming may seem productive, but proper
software design and coding practices make coding,
troubleshooting and modifying so much easier. However,
sometimes me thinks that looking busy in these days of cutbacks
seems so much more productive when they are lopping heads
(layoffs).
--
HPT
|
|
