Some good advice and thoughts about programming in general

[Isaac]

Inspired from @NauticalGent 's excellent article links from here, I read an article which I felt had a LOT of really good advice in it. Some challenged me, some was relatable, some was just funny.

I'm starting this somewhat random-seeming post with a few smaller quotes, and then, if you have more time and feel like reading it, a longer one.

The technology churn from Microsoft is impossible to match in the real world. As Joel Spolsky said, there's 2 camps at Microsoft - the "Raymond Chen camp" (which wants to maintain backward compatibility at just about all costs) and the "MSDN Magazine camp", which "wants to keep churning out huge pieces of technology that no one can keep up with. Inside the halls of Microsoft, the MSDN Magazine camp has won."

"We’re programmers. Programmers are, in their hearts, architects, and
the first thing they want to do when they get to a site is to bulldoze
the place flat and build something grand. We’re not excited by
incremental renovation: tinkering, improving, planting flower beds.
There’s a subtle reason that programmers always want to throw away
the code and start over. The reason is that they think the old code is a
mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It’s harder to read code than to write it.
This is why code reuse is so hard. This is why everybody on your team
has a different function they like to use for splitting strings into
arrays of strings. They write their own function because it’s easier and
more fun than figuring out how the old function works.

These problems can be solved, one at a time, by carefully moving code,
refactoring, changing interfaces. They can be done by one programmer
working carefully and checking in his changes all at once, so that
nobody else is disrupted

In any shop I know, it's "do more with less" and no one has time to get around to all the legacy constructs, I can promise that. The technology churn from Microsoft is impossible to match in the real world. As Joel Spolsky said, there's 2 camps at Microsoft - the "Raymond Chen camp" (which wants to maintain backward compatibility at just about all costs) and the "MSDN Magazine camp", which "wants to keep churning out huge pieces of technology that no one can keep up with. Inside the halls of Microsoft, the MSDN Magazine camp has won."

I'm not black and white on the "don't fix it if it ain't broke" rule, but am in most circumstances.

From a Joel Spolsky interview:

"We’re programmers. Programmers are, in their hearts, architects, and
the first thing they want to do when they get to a site is to bulldoze
the place flat and build something grand. We’re not excited by
incremental renovation: tinkering, improving, planting flower beds.

There’s a subtle reason that programmers always want to throw away
the code and start over. The reason is that they think the old code is a
mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It’s harder to read code than to write it.

This is why code reuse is so hard. This is why everybody on your team
has a different function they like to use for splitting strings into
arrays of strings. They write their own function because it’s easier and
more fun than figuring out how the old function works.

As
a corollary of this axiom, you can ask almost any programmer today
about the code they are working on. “It’s a big hairy mess,” they will
tell you. “I’d like nothing better than to throw it out and start over.”

Why is it a mess?

“Well,” they say, “look at this function. It is two pages long! None
of this stuff belongs in there! I don’t know what half of these API
calls are for.”

Before Borland’s new spreadsheet for Windows shipped, Philippe Kahn,
the colorful founder of Borland, was quoted a lot in the press bragging
about how Quattro Pro would be much better than Microsoft Excel, because
it was written from scratch. All new source code! As if source code rusted.

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed.
There’s nothing wrong with it. It doesn’t acquire bugs just by sitting
around on your hard drive. Au contraire, baby! Is software supposed to
be like an old Dodge Dart, that rusts just sitting in the garage? Is
software like a teddy bear that’s kind of gross if it’s not made out of all new material?

Back to that two page function. Yes, I know, it’s just a
simple function to display a window, but it has grown little hairs and
stuff on it and nobody knows why. Well, I’ll tell you why: those are bug
fixes. One of them fixes that bug that Nancy had when she tried to
install the thing on a computer that didn’t have Internet Explorer.
Another one fixes that bug that occurs in low memory conditions. Another
one fixes that bug that occurred when the file is on a floppy disk and
the user yanks out the disk in the middle. That LoadLibrary call is ugly
but it makes the code work on old versions of Windows 95.

Each of these bugs took weeks of real-world usage before they were
found. The programmer might have spent a couple of days reproducing the
bug in the lab and fixing it. If it’s like a lot of bugs, the fix might
be one line of code, or it might even be a couple of characters, but a
lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing
away all that knowledge. All those collected bug fixes. Years of
programming work.

You are throwing away your market leadership. You are giving a gift
of two or three years to your competitors, and believe me, that is a long time in software years.

You are putting yourself in an extremely dangerous position where you
will be shipping an old version of the code for several years,
completely unable to make any strategic changes or react to new features
that the market demands, because you don’t have shippable code. You
might as well just close for business for the duration.

You are wasting an outlandish amount of money writing code that already exists.

Is there an alternative? The consensus seems to be that the old Netscape code base was really bad.
Well, it might have been bad, but, you know what? It worked pretty darn
well on an awful lot of real world computer systems.

When programmers say that their code is a holy mess (as they always do), there are three kinds of things that are wrong with it.

First, there are architectural problems. The code is not factored
correctly. The networking code is popping up its own dialog boxes from
the middle of nowhere; this should have been handled in the UI code.
These problems can be solved, one at a time, by carefully moving code,
refactoring, changing interfaces. They can be done by one programmer
working carefully and checking in his changes all at once, so that
nobody else is disrupted. Even fairly major architectural changes can be
done without throwing away the code. On the Juno project we
spent several months rearchitecting at one point: just moving things
around, cleaning them up, creating base classes that made sense, and
creating sharp interfaces between the modules. But we did it carefully,
with our existing code base, and we didn’t introduce new bugs or throw
away working code.

A second reason programmers think that their code is a mess is that
it is inefficient. The rendering code in Netscape was rumored to be
slow. But this only affects a small part of the project, which you can
optimize or even rewrite. You don’t have to rewrite the whole thing.
When optimizing for speed, 1% of the work gets you 99% of the bang.

Third, the code may be doggone ugly. One project I worked on actually
had a data type called a FuckedString. Another project had started out
using the convention of starting member variables with an underscore,
but later switched to the more standard “m_”. So half the functions
started with “_” and half with “m_”, which looked ugly. Frankly, this is
the kind of thing you solve in five minutes with a macro in Emacs, not
by starting from scratch.

It’s important to remember that when you start from scratch there is absolutely no reason
to believe that you are going to do a better job than you did the first
time. First of all, you probably don’t even have the same programming
team that worked on version one, so you don’t actually have “more
experience”. You’re just going to make most of the old mistakes again,
and introduce some new problems that weren’t in the original version."

 

[NauticalGent]

I have read that article and it really strikes a chord with me. Twice I have fallen into the "scorched earth" trap and spent more time trying to reinvent the wheel than if I had just taken some time to figure out my predecessor's code.

Take time to do it right, or make time to do it over...

 

[gemma-the-husky]

Sometimes the fundamental design approach of the first solution wasn't correct. Then it does become very difficult to fix, and it's easier to change.

I re-developed an app that originally needed a substantial rewrite each year. The app produced a multi-year history and every year, the subforms/subqueries needed changing to represent the active financial years. I changed that so it knew how to build each old year based on the reporting date, and then needed no further rewriting. This app also had some fundamental data analysis flaws.

I still kept what I could from the original. There was a lot of good stuff in there.

I think the article does explain in a roundabout way, why you can spend and waste a lot of time trying to improve code that works.

 

[The_Doc_Man]

This is perhaps an opinionated statement and we all KNOW that I don't make those.... <<cough cough>>

Sometimes that "discard the old code, reinvent the wheel" cycle occurs because of incomplete original design that looked to what would make a particular routine re-usable. I'll even grant that the first cycle might be rocky enough that the code MIGHT need rewriting. However, if the same person is in a continuous cycle of "scrap and redesign" then that person is one of a few things (and here is where "opinionated" comes into play).

1. The person is incompetent to be a programmer, because the person doesn't have what it takes to become experienced. You DO know the definition of "experienced" don't you? Experienced = able to recognize your mistakes when you make them again.

2. The person is a perfect low-level civil servant or other person is paid by the hour, a person who doesn't care how long it takes to do the job and isn't afraid of getting fired for some reason.

3. The person is unaware / ignorant of / uninterested in the concept of designing for re-use as a way minimize future costs, perhaps because that person cannot see the forest for the trees. Such a person will always be a coder, NEVER a systems designer, because the latter must be able to alternate attention from system to components. Being unaware of an overarching system doesn't completely excuse the person but DOES implicate poor management.

4. The person doesn't understand how to use that which already exists because the person who wrote it didn't leave good documentation.

5. The person, for personal or political reasons, wants to be seen as doing something useful for someone even though a perfectly good routine already exists with good documentation, something that was written by an employee who has since left the company.

The latter actually occurred for me when I worked for a small company in the oil & gas exploration industry. We made navigational systems for oceanic "seismic surveys" doing echo mapping of the bottom of the Gulf of Mexico. Everyone knows about the maps you see in geography class in grade school, high school, and (sometimes) college. They involve either the Mercator projection or the Lambert projection, right? Mercator maps exaggerate the poles. Lambert projection exaggerate one hemisphere vs. the other. But turns out there are a few places in the world where they use the third-most common project - Cassini-Soldner, also called the "pincusion" projection, which exaggerates corners. Used mostly for very small geographic areas like islands or small provinces in the Caribbean or the Mediterranean seas. I wrote a REALLY tight bit of code to compute the projection and its inverse function. Wrote it in assembly language. Included comments along the way so that you could tell which part of the formula was being computed. Wrote a "user's guide" to calling it. Worked fine for over a year. Then I got my Navy job, said my goodbyes (amicably), and left the place. About four years later, met someone whom I had known before who took over my job at the small navigational company. He eventually left (again, better job with more money) and our paths crossed. He told me he had totally rewritten the routine, scrapped the old one. So I asked him if it had broken. "No, I just needed to do something to prove I could do the work." I wanted to punch out his lights, but that would have been unproductive. Back then, I still had a touch of "pride of composition" and he had trashed my baby.

But I have digressed with a relevant but long-winded story. I'll let this sit and get on with other articles.

 

[Pat Hartman]

Programmers are just people and people are easily transfixed by bright, shiny, new objects. The conflict between programmers and management is that management is paying the bills and they have an aversion to the bleeding edge. They don't feel the need to delve into new technology just because it is there whereas programmers are all about new stuff. Sometimes a project actually needs new technology. Most just don't. Things will go quickly and smoothly without blood on the floor if we just use the technology we have to the best of our (and its) capabilities. Access is a prime example of this. Access is ancient and yet here we are still using it. Why, because even after all these years and with all its flaws, there is still nothing better. It doesn't do everything but it does what it does and it does it well.

A good programmer knows his tools and uses the right tool for the right job. He doesn't get out the lawn mower to trim the bushes although some have tried. That is why the Darwin Awards exist.

Learn new stuff because learning is always good and you might actually find something better but do it on your own time unless you get lucky and find an employer to pay you to learn something new.

 

[Isaac]

Yeah these are some of the reasons why I found the article thought provoking. On the one hand, I have definitely experienced and I enjoyed reading someone validate my actual experience that, in SO many cases, it is literally easier to write something new than it is understand - and ponder/test, until you feel you even agree with - the old code. I've sometimes struggled to explain this to other people, who thought they were doing me a favor by giving me "something to start with", and couldn't understand why I always wanted to just get the logical requirements and then write the query, especially in SQL.

On the other hand, I can see the author's point about not necessarily thinking new code is better - and how some companies just want to re-write everything with the latest and greatest components, but the days/weeks/months/years of actual, encountered & fixed, BUGS (that the old code can boast of) are very valuable, and not to be discarded lightly.

Of course, I totally agree with what several have said on this thread, which is that we also often come across predecessor design that we simply feel is quite poor, and must be redesigned if progress is going to be continued in general - and that's legit, too.

I was just happy to see someone finally say out loud "it is easier to write new code than understand someone else's code".
All these years, I thought maybe it was just me........

One thing I have learned for sure, though. If I'm in a sql server developer role, for example, and surrounded on my same team with very experienced developers (usually includes at least some way better than me), I DO need to remember to take 2 minutes to ask someone else "Do you already have such-and-such function?" rather than following my (in this case) foolish instinct, and start typing away......

Also, a Stack Overflow response with 300 thumbs up and 50 detailed agreeing responses will work too (from people who have written books on the subject!). Gotta love the Internet and how we can stand on the shoulders of giants with a few seconds' search....

 

[gemma-the-husky]

It's actually sometimes easier to rewrite code or queries when you forgot where you put the original. It's easier to do it again, than search for the code, within a stack of modules, or search for the particular query within hundreds of other queries, or even within query definitions stored in the form. Time is generally more valuable than application size, which really didn't always used to be the case

 

[Pat Hartman]

When I was managing programmers, they weren't allowed to just rewrite code because they didn't like it. In fact, I used to give them "demerits" if I could tell their code from the original programmer's code because when they used different naming standards or other techniques, that didn't make the program better. It just made it more difficult for the next poor schmuck who had to modify it. Consistency is paramount to the point where I would prefer consistent bad code to inconsistent good code but I think that must be an oxymoron. Good code would never be inconsistent.