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.

Programmer behavior observed

I've noticed that the programmers in my shop have a strong tendency to rewrite everything rather than learn someone else's code.  At first I believed that it was because the existing code base needed to be rewritten.  Now I'm not so sure; it happens way too often.

It goes to motivational behavior.  If they have to extend or work within existing work, they drag their feet.  However if they (re)design something from scratch, they jump to it.  There is no financial incentive either way, just an aversion to groking someone else's code.

Just an observation, albeit an annoying one.
Wednesday, January 10, 2007
Oh, in my experience this is totally, 100%, absolutely true and I myself am strongly that way. I have an inherent mistrust of anything I didn't write and will only use someone else's stuff if that is the only option. If I had enough time, I'd probably write my own Windows.
Greg Send private email
Wednesday, January 10, 2007
> rewrite everything rather than learn someone else's

On a different topic, I frequently rewrite (or more accurately, "refactor") even my own code as part of extending it: less so when I'm "designing something from scratch" (in which case I'm usually just adding code), but more so when I'm subsequently adding a new feature which wasn't a part of the original design, which it often wasn't due to
Christopher Wells Send private email
Wednesday, January 10, 2007
"work within existing work"

This means the code violates the Open-Closed Principle. Which is why it's prone to being rewritten.
Wednesday, January 10, 2007
I believe this is pandemic, for better or worse.  I think it's mostly because no two people would write the same thing the same way, so everything seems to foreign when another person wrote it.

Ideally, there would be more refactoring-whats-there-in-order-to-learn-and-extend, rather than throw-it-out-and-start-from-uninformed-scratch.
Notorius L
Wednesday, January 10, 2007
==>I've noticed that the programmers in my shop have a strong tendency to rewrite everything rather than learn someone else's code. 

Fortunately, we don't have that issue in my shop. If we did, I'd be "this close" (for sufficient values of "close") to considering it a firing offense. Good, working code is *expensive* to rewrite and pulling something like this would seriously effect profitability.

Luckily, we've staffed with a bunch a GoodGuys who understand this, and it ain't a problem.
Wednesday, January 10, 2007
Yep.  Open source software drives me nuts.  Not seeing the source code might be more relaxing actually.
Wednesday, January 10, 2007
I don't have a problem using open-source libraries that have been well-tested by the community. But I confess I have the same urge to rewrite other people's code in other situations. Part of it is just the fact that when I use someone else's code, I don't understand it completely. I may have a good idea of how it works, but I'm there's always some subtlety that I'll miss. With my own code, I know as much as anyone can know about how it works.
Wednesday, January 10, 2007
IMHO, it has to do with whether someone is motivated to accomplish the stated goals of the "project" or not.  Those who are so motivated will not waste time on things that don't directly contribute to the end result.  Those who are not will establish their own goals, and work towards fulfilling them, regardless of whether they advance the "greater" goal.

This can be due to either (a) not understanding or believing in the greater goal, or (b) not believing that one can actually contribute to the greater goal.

In either case, you have a problem.  Either figure out how to communicate the greater goal better in order to generate buy-in, or make it clear how an individual can contribute to the greater goal.

Of course, some people are just wankers ;-)
BillT Send private email
Wednesday, January 10, 2007
It might also have to do with whether you are a rocket scientist surrounded by morons, or whether your co-workers are all of similar capability as yourself.
Greg Send private email
Wednesday, January 10, 2007
You rewrite so you understand because that is in essence what a program is: understanding. It doesn't really matter how well the program was written because it was written in the mindset of other people which you are unlikely to ever understand. So you rewrite.

You can think this is wrong but when the responsibility to make something work is yours rewriting is often the most rational approach because it gives you back complete control.
son of parnas
Wednesday, January 10, 2007
I believe this is largely dependent upon the quality of the written code.

When I work on projects written in spaghetti code then yes I do have the urge to rewrite sections of it as I go.  This makes it both easier for me as well as the person who comes after me to maintain.

Curiously, when I have worked on code that is well designed and adheres to a good set of coding standards the urge to rewrite seems to fade.

Half the time code becomes spaghetti is because many developers do the minimum rewriting possible, often using a fudge (or building another fudge into an existing fudge) and so the code becomes even more error prone.
Wednesday, January 10, 2007
Rewriting definitely improves understanding, but that doesn't mean you should keep what you've rewritten.  One good way to get familiar with code is to go through and rewrite a whole bunch of it, but then throw away your work at the end.  You gain the benefit of understanding without the risk of breaking working code.  (Some books call this a "scratch refactoring.")

One point worth considering by those who've overloaded on TDD reading materials, as I tend to, is that automated testing isn't the only way to test code when you're refactoring it.  It's probably the best way, but it's better to have *any* kind of test, even a "run it and look at the screen" test, then to change code with no test at all.

In other words, don't let your inability to write an automated test make you think you may as well change the code with no test.  There must be *some* way to test it (otherwise, how was it ever known to be working?), so find that way and use it as a check as you refactor.  (Otherwise, you _will_ break working code.  Go ahead, ask me how I know.)
Kyralessa Send private email
Wednesday, January 10, 2007
Like Sgt.Sausage, luckily, we don't have this problem either. Actually the idea that some programmers might habitually do this horrifies me!

Obviously there are times when the code is so bad that you have to rewrite it. However IMHO you should never rewrite unless you are 100% certain that doing so will save time in the long run -- and that include testing and comebacks. As a programmer coming into a piece of code to enhance or fix it, you never have as full an understanding of the original brief as the person who wrote it, and consequently you're are much more likely to break it by rewriting it than if you just took the trouble to understand it and then modify it.

If you have a good bunch of programmers, good coding standards, a clear spec and a good manager to make sure things happen when they're supposed to happen, it's not a problem.

I am, of course, speaking from a commercial point of view ...
Miranda Send private email
Thursday, January 11, 2007
It's easier to write an incorrect program than understand a correct one.

Seriously, as another poster stated, this might be about goal-setting. At some point you need to set precise goals and commitments. Then you should let competent developers loose on those goals. If they want to do a rewrite, that's fine - as long as they meet their goals.

I find that when I set precise goals and commitments, 80% of the rewriting stops dead in its tracks. The other 20% is justified for various reasons.
Mark Pearce Send private email
Thursday, January 11, 2007
People re-write because its an easier way to get a sense of accomplishment then solving the problem or need that is causing the code to be revisited.

Its an easy  trap to allow yourself to feel good about re-writing when you are really just re-wording someone elses solution and not adding any value.

Then when it comes down to adding new stuff its usually at best no better then the original code.
IT Manager
Thursday, January 11, 2007
>If you have a good bunch of programmers, good coding >standards, a clear spec and a good manager to make sure >things happen when they're supposed to happen, it's not a >problem.

I would add unit tests to this list.  Modifying someone else's code is far easier when you have a decent set of unit tests on the code.  You can code "offensively" rather than "defensively".  You can try something to see if it works, rather than having to fully understand how everything works before you change anything for fear of breaking something.

Additionally, unit tests also act as a sort of spec - they can help improve your understanding of what the interfaces do even if you don't fully understand the internals. 

In other words, unit tests simultaneously increase understanding (marginally, but it's there) and reduce the need to completely understand the code.
coderprof Send private email
Thursday, January 11, 2007
> Additionally, unit tests also act as a sort of spec -

I agree completely that unit tests help verify changes but just as strongly disagree they act as a spec. Unit test code is just more code you didn't write, don't understand, and don't know what it really does.
son of parnas
Thursday, January 11, 2007
I agree with ChrisB.

We maintain a lot of legacy code here. Quite often that code relies on assumptions and external dependencies that no longer exist. In fact, our management is now pushing us to deliberately rewrite code to make it more modular and future proof.

Err... we have some code that was written in the mid-90s and contain hard coded references to files and network resources. (Imaging compiling the network address of a printer into your application.) We also have code that use variable names inconsistently, solve the same problem three different ways, etc etc.

For us, the deciding factor was that our maintenance costs are simply too high; we were at a point where we couldn't produce anything new because we were too busy running around slapping bandages on everything.

I'm not opposed to programmers who rewrite code as long as the system is in better shape afterwards.
Thursday, January 11, 2007
I think programmers are highly creative people, and part of the creative process is actually owning what we create, by designing it and building it ourselves from concept to reality.

Can you imagine asking an artist to touch up or finish the work of another artist, whilst enforcing the fact that he can't add any new colours, or restore the faded corners, or fix the torn canvas? But that's basically what programmers have to do on a daily basis, and I think it can be deeply frustrating to a skilled, experienced developer.

I've been doing this schtick for 10 years now and it frustrates me more than ever!

I do think, however, that the urge to rewrite needs to be tempered with the realities of writing commercial software - I think it is unprofessional to rewrite code without a proper business case and sponsorship from the appropriate stakeholders.

Just my 20 cents.
Sam Piper Send private email
Thursday, January 11, 2007
I recently offered to help someone with their site, which is PHP.

When I got home with the CD, I looked at what he already did with it, and a lot of it didn't work because of mismatching braces or other reasons ( I have the php plugin for JEdit that instantly points you to problems ).

And he created the few pages he did, using a file include methodology that came straight from a single book. 

I didn't want to rewrite it because I wasn't "owning" his stuff at all. I was going to charge about $200 for some unspecified few hours, or a day, just to make certain pages work. 

But I was so flustered with trying to figure out exaclty what the $%#&# his intentions were, and matching that up with how he wanted his site to work (he showed me the general flow at a coffee shop).

And I realized, dang.. i need to be spending this time I'm spending, reading my programmer interview book (the popular one, not the microsoft one though ), and reading some core php, mysql stuff to refresh for any upcoming  job interviews  (plus C# in csae something like that opened up)

So I told him I can't take his money, but I did email a list of corrections to his existing files that were found by JEdit.

The lesson I learned, is that for me take a casual project on, well, it' can't be casual. I will have to have permission to hand him back files that I wrote from scratch.

This is kind of a moot point now, since I'm in the process of entering the fulltime job world anyway, and then on weekends, I will work on a microISV project.
Thursday, January 11, 2007
This is (once again) a management and people issue.

Three things have to be in-place in order for significant code re-use to happen:

1) Existing code has to be good and general enough to be practical to be considered for re-use.

2) Management has to put in place a culture of the programmers trusting each other enough to WANT to re-use code.

3) Management has to support a "technocracy" that is strong enough and has enough continuity and coherency that it is possible to KNOW that suitable existing code is available.

#1 may not be the case, and it may not be so because your peers are morons and write bad code. Much commercial code is maintained to the point that core functions lose so much generality that it is cheaper to rewrite than learn and refactor existing code.

Lack of collegial trust is about as common, though (#2). If you don't respect the guy who wrote a body of code you are unlikely to even want to learn how their stuff works. Re: "don't flip the bozo bit".

Lastly, #3 - creating the right environment for code-sharing - is QUITE rare. In general it requires a large, well funded company on the scale of a Microsoft in order to create the conditions that allow code to be understood, documented, and re-used. In general, many things can sabotage this: firing key people or attrition and lousy planning as examples. It's difficult and expensive to get things "right" enough that it happens.

Smaller companies tend to have planning horizons of days or weeks. There is so much chaos associated with developing code in a small company hack shop environment (unless you're the owner and therefore calling the shots) that the developers working there would laugh in your face at proposing any effort that isn't survival related.

I have had the "pleasure" of working with a few smaller companies that would have some arbitrary initiative put in place by management that code re-use would be "required". What tends to happen when it is mandated is ... you guessed it.. the wrong stuff is re-used, and the mandates become a set of handcuffs.

Frankly, code re-use is the exception, except occasionally at the component and external interface level.
Bored Bystander Send private email
Monday, January 15, 2007
I've made my living for the last decade or so offering tools that help software developers maintain legacy code.  I notice a subset of our sales is helping engineers decide what to do about source, and even if re-writing, to make sure they know everything that implies.  That warms my heart, as I think re-writing to important a decision to go about on "gut feel".

I certainly agree that is uncomfortable to maintain somebody else's monstrosity.  We regularly hear that pain from our customers.

The decision to maintain, re-factor or re-implement decision should not be left to a programmer new to the software as they probably do not have all the information needed to intelligently make such a decision.

It is hard to think of any decent size body of source code that doesn't represent hundreds of thousands of dollars (or more). Even for large companies, what to do with assets of that size is a management call.

In our own shop... we regularly re-write parts of our products. But only when we have new needs for performance or when existing software implementation prevents new features we really want.

In practice, about 1/4 to 1/5th (depending on how you measure in size vs investment) of our source code is being re-written at any given time.

Right now it is a bit more as we are replacing our GUI toolkit with a newer supported one. That was definitely a management decision. At the highest level and with due and diligent consideration.

Good luck - remember that software engineers are creative but should be expected to do what is best for the organization.
Ken Nelson Send private email
Tuesday, January 16, 2007
You can get away with murder wasting hundreds of hours by just calling it "refactoring" instead of rewriting.
La la la la la
Wednesday, January 17, 2007
The tendancy of hackers to want to rewrite everything can be somewhat controlled by encouraging them to write highly modular code & encapsulate it in a library with a well-documented, small-surface-area interface. Then subsequent hackers are more likely to just use the library and not look inside it. Also, the discipline of providing code as a library forces you to sever any tentacles to the surrounding code, resulting in cleaner & more elegant code.
Johnny the Geek
Thursday, January 25, 2007

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

Other recent topics Other recent topics
Powered by FogBugz