Re: Is well written code a rare species ?
- From: "David" <FlyLikeAnEagle@xxxxxxxxxx>
- Date: Sun, 28 Aug 2005 05:30:09 GMT
Hello George,
I've been away from the computer for a few days. I also read your
reply and had to change tasks before replying and it got lost in all
the stuff that has come in the last few days. <smile> At least I've
found it again. I hope you are doing well this weekend.
On Thu, 25 Aug 2005 21:20:18 UTC, Anonymous George <someone@xxxxxxxxxxxx> wrote:
> On Sun, 14 Aug 2005 13:16:53 +0000, David wrote:
>
> >> On Fri, 12 Aug 2005 17:56:51 UTC, Anonymous George
> >> <someone@xxxxxxxxxxxx> wrote: Most of those programs were badly written.
> >
> > Why did it take you 10 years to write this?
>
> This new job has more pressure and making changes *fast* with
> poorly structured code is really hard.
Yes it is. It is sad that some employers need/want fast fixes
to problems that are better solved with a little thought.
> > More importantly what did you _do_ when you found code
> > that could have been written better (in your opinion, anyway)?
>
> I usually only change the minimum necessary to fix a bug or to implement
> an enhancement. If the code is badly structured that takes a lot of time,
> because it's hard to find out where you have to make the changes and what
> the changes are. So in such case, I complain loudly and try to get more
> time to understand and restructure the code before making the requested
> changes. But there's a lot of pressure to deliver the fixes
> and enhancements and usually there's no time to fix the
> structural problems in the programs.
Trade-offs are part of the problems we must deal with. They may accept
a low cost of making a quick fix and not realize what could have happened
with a little more effort over time. Certainly you can see where certain
bugs will tend to repeat themselves. Sadly management often sees this as
productivity -- the ability to make fast changes with minimal cost. They
don't measure the fixes they have to fix again later or otherwise address
in other parts of the code.
It sounds like you are part of a team and the overall goals are basically
to make changes. A lack of ownership and responsibility can sometimes lead
to code that gets neglected. Perhaps you can suggest some smaller 'fixes'
or process improvements that will give them a nudge in the right direction.
For instance, if the problem was a misuse of some function (say a locking
feature) even when you have the fix for that problem at a specific point
in the code, perhaps suggesting a quick review of all such calls would
prevent similar problems that are not yet reported or experienced.
Sometimes we can improve the code and make the mistake harder to make
the next time around. Sometimes the manager doesn't understand that
improving the whole product can be worthwhile as part of the process.
There are companies that have fix-only processes that follow the path
you describe. I worked for several years at IBM and they had a team
that developed each new generation of products and kept moving on. I
was part of the maintenance crew and although we reported fixes up the
chain of command, no one thought the original programmers could make
the same mistake later on in another product. Our code base was also
quite large (then entire OS and application suite) and the team was
about 200 programmers with managers that expected multiple fixes per
day. The rules laid down expressly forbid improving the product at
all. Sometimes that is all the product creator wants and we have to
live with that burden.
> > Is that because the projects are structured so poorly, you
> > do not understand how they are put together, or perhaps you are being
> > asked to make significant changes and the changes should be rather
> > difficult to make?
>
> The changes are usually not so significant at all.
> But because of the poor structure of the code it's much
> more difficult than necessary to get a grasp of the base
> that I'm going to build upon / am going to fix.
I agree. Some changes, though seemingly simple, can be quite
complex or far reaching. I've had the misfortune of fixing the
same communications code many times over to prevent specific
problems only for everyone to find the underlying symptom grew
worse with each fix. It started with a minor problem and years
later resulted in some very unstable customers that did specific
things. Only when the real problem of understanding what the
original developers wanted to do and then correcting their logic
and the whole mess created since then were we able to actually
fix all the problems in that part of the system. The developers
looked productive, but management didn't like more severe bugs
and the (usually larger and influential) customers certainly
didn't like apparently more buggy fixes being issued. It is
important to understand when the problem is just a local fix
or needs a bit more exploration to prevent far reaching
implications.
> > I would hope that simple changes aren't that difficult to make.
>
> They are ! But perhaps it's also me. I hate making errors.
> It makes me feel embarrassed. I don't want to introduce
> new bugs when I'm fixing one and I don't want to introduce bugs
> when I'm enhancing some functionality.
I agree. I'm also a perfectionist of sorts. I'd rather have
people's view of my work be that I did good work rather than that
I usually did something useful and that others had to fix the messes
I'd created. I also like to help the team understand that and help
everyone improve. We are all learning ways to improve.
> Greetings,
>
> George
David
.
- References:
- Is well written code a rare species ?
- From: Anonymous George
- Re: Is well written code a rare species ?
- From: David
- Re: Is well written code a rare species ?
- From: Anonymous George
- Is well written code a rare species ?
- Prev by Date: Re: Expect/standards/lineItemBilling (was: How much should I charge...)
- Next by Date: Re: GNU Public Licences Revisited (again)
- Previous by thread: Re: Is well written code a rare species ?
- Next by thread: Re: Is well written code a rare species ?
- Index(es):
Relevant Pages
|
