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.

Swirling in a sea of disbelief

I need some advice from anyone willing to give it. I work for a certain package delivery company and a certain group within this company has developed a client application that interfaces with software that the company I work for has developed. This software is typically ran from a server and uses coded transaction strings over TCP/IP to interface with its client systems.

This client application that has been developed by my peers is some of the most abhorrent code (VB6) ever written. It violates every rule of good software design, has no forethought of code reuse, would make any seasoned programmer worth their salt (no pun intended) cringe, and is just an absolute eyesore to look at (the code anyway).

A couple of weeks ago I approached my manager with the aforementioned "qualities" and told him I wanted to get involved because I could lend a great hand. In waiting for my request to go up the food chain a very sobering thought has hit me. Just this evening, I found a spreadsheet that lists all of the companies presently employing this application. With it, the daily total volumes are listed as well. There are approximately 60 placements (with some of those running multiple clients) that collectively ship around 1 million packages daily.

For as horrid as the code and architecture are of this application, how can I possibly argue with those numbers? I know the code is bad but if it is churning through that kind of volume, it must not be that bad.

I know there is always the chance that some major flaw will be found, but in the world of high-volume shipping, it is very repetitive and extremely invariable.

Am I barking up the wrong tree or is there a case to be made here?

Thanks in advance for any insight you may have.
DazedAndConfused Send private email
Wednesday, August 17, 2005
I would argue that modifications and enhancements are more expensive because of the muddled code and with every addition the code becomes more convoluted and more expensive.

Refactoring around a solid, extensible model will make it cheaper to modify & support in the future. This argument has the added benefit of being true.

Shane Harter Send private email
Wednesday, August 17, 2005
You're on dangerous ground here.  The application may be a horrid mess...but obviously it works.  An ugly application that works is better than an application with beautiful innards that crashes or otherwise doesn't work.

Of course "beautiful" and "working" don't have to be mutually exclusive.  The trick is to keep the application working while you refactor it.  The way to do it is to have tests in place for anything you intend to change.

I'd put the tests at the most atomic level you can: if you have a tiny function that just concatenates a customer's first and last name, write tests for it, both for normal operation and for weird cases (a customer with no first name, or whatever).  These tests serve to document its present behavior (even if it's buggy), and ensure that when you make changes, you don't change the way the application acts.

I have no idea what sort of xUnit-type or other testing programs are available for VB6, but you might have a look here:

Based on experience I can tell you that if you don't have tests in place, you _will_ screw something up.  If you're lucky it'll just be a few little things.  Don't count on being lucky.  And realize that if you get the code looking beautiful but it doesn't work well anymore, you'll face a complete loss of credibility.

You might want to check out this book, which I've been reading lately and have profited from:
Kyralessa Send private email
Wednesday, August 17, 2005
That is kinda what I was thinking. It isn't so much about making the code beautiful as it is making it better. For instance, the (yes, THE) author of the code has functions written that duplicate inherrent functionality to VB. He has written a function that formats a number to a given number of decimal places, doing EXACTLY what the FormatNumber function does. Additionally, the number being formatted is actually a string variable so he can use string manipulation functions to add (i.e. concatenate) the required number of decimal places.

It is obvious that the author/developer does not have a real strong understanding of VB or even software design in general. As with most people in this company, he was in the right place at the right time so he was allowed to spawn this 'piece' of work.

The hard part is that the people that need to be convinced of its dark side are people who will focus on the numbers and its immediate impact vs. having the foresight to see what could potentially happen.

I am afraid the only way I will get someone on my side is to find a very terrible flaw (such as reporting incorrect freight charges or something) that no one is aware of, but I don't think there are any. I have found NUMEROUS spots that would improve processing time (little things, not function rewrites or anything) but again, with some of these systems processing up 6-7000 packages a day, that again, is a hard point to argue.

Thanks again for the insight, I am still curious what anyone else thinks.

Tobey Send private email
Wednesday, August 17, 2005
Unless your manager is developer there's little room to argue for technical improvement of the code. It works. That's what matters.

But you CAN make business case out of it. Refactoring will save money. It will shorten the development cycle and make it cheaper to respond to customer requests. When the customer shipping 100,000 packages a day asks for changes you say "yes" and not have to break the budget to do it.

This is language an MBA can understand.
Shane Harter Send private email
Wednesday, August 17, 2005
> Am I barking up the wrong tree or is there a case to be made here?

Why not move on to something new that doesn't work?
son of parnas
Thursday, August 18, 2005
I once refactored some hugely horrible working code and it turned into a nightmare I'd rather not repeat.  It's very hard to refactor something that sucks really bad (In my case: excessive global variables, few functions, 5 level deep nested if's that went on for screens and screens). 

It seemed like a simple task (haha) when I started but it took me a very long time (under deadline) to get it working right again.

Of course, the resulting code was much easier to modify but I never really had much need to modify it after that.
Almost H. Anonymous Send private email
Thursday, August 18, 2005
Why do it?
Is there a religious aspect of it?
What's your gain, except sleeping better at night??
Mikael Bergkvist Send private email
Thursday, August 18, 2005
> I have found NUMEROUS spots that would improve
> processing time (little things, not function rewrites or
> anything) but again, with some of these systems
> processing up 6-7000 packages a day, that again, is a
> hard point to argue.

It aint broke, so don't fix it. You can only lose in a situation where you offer to rewrite or refactor a mission critical application purely on aesthetics.
Sheldon Lavine
Thursday, August 18, 2005
The companies business is delivering packages not making pretty software.

Rather then "Being in the right place at the right time" I'd say the author came through in the clutch. He's helped the company make money that pays salaries. What have you done to earn your keep. Moaning about some trivial nonsense just places you among the dead weight that successful companies pick up as they grow.

Oh and if your boss is actually taking this up the food chain he's about to get his butt reamed. I'm sure he'll really appreciate that.

Thursday, August 18, 2005
Wow, mom. Trolls really do exist!

Tobey Send private email
Thursday, August 18, 2005
> Why do it?
> Is there a religious aspect of it?
> What's your gain, except sleeping better at night??

Many reasons. 1) I have to implement and support this product. To implement this product, we are given the source code so it can modified and adapted to the particular location we are installing it to. 2) Every team has a go-to person for this product. I am that person. 3) Company loyalty. I have the ability and the knowledge to make it better. I would not be doing my part if I did nothing.

> It aint broke, so don't fix it.

That is such a cop out.

> You can only lose in a situation where you offer to
> rewrite or refactor a mission critical application
> purely on aesthetics.

1) I am not wanting to redesign the GUI I am wanting to convince the powers-that-be that the architechture is fundamentally flawed and that while it isn't broke now, as others have stated, it will be very costly in the future to maintain and add new features. 2) Wouldn't you want a mission critical application to be bullet-proof?
Tobey Send private email
Thursday, August 18, 2005
Troll? I guess you only want everyone's opinion when it agrees with your own.

Thursday, August 18, 2005
Welcome to the real world. I've seen it many times before. Heed the other's advice on this one. Let it go. It works.

I worked for a company that decided to resell another vendor's system while we worked dilligently to build our own. The other vendor's software was very popular. However, it was a huge mess and was very buggy. We spent countless hours fixing it and supporting it. Our product on the other hand was very easy to work with and had very few bugs (no critical bugs). However, we never sold a single copy of our product... so which product was actually "better"?
Thursday, August 18, 2005
Consider the flipside. I have to look after a horrid mess that I'm not allowed to rebuild (re-write, re-factor, whatever).
  Management thinks it works. But those who use it complain about the data that gets lost, pieces which just don't work, inconsistent data in the database.
  But I'm having a hard time making the case for change even after showing management the duplicate and missing data.
captain damage
Thursday, August 18, 2005
>> It aint broke, so don't fix it.

>That is such a cop out.

I used to think the same thing, now I realize that it is the voice of experience and wisdom. 

All the crufty code is the result of endless bug tweaks, in essence, it is the culmination of a lot of real world testing.  Why would you want to throw all that out and start out at version 0.1 again?  Crufy systems rarely make for good prototypes since there are hidden dependencies in the code.

Besides, its usually not a good idea to tell management that their prior decisions and/or oversight has resulted in a bad product.  Not a good career move.
Consultant to the Evil Empire
Thursday, August 18, 2005
meaning...I've tried, let it go?
Tobey Send private email
Thursday, August 18, 2005
>  I am wanting to convince the powers-that-be that the architechture is fundamentally flawed

If it were actually fundamentally flawed, it would not work! It's entirely possible for ugly code to work - I don't mean to sound patronising when I say that it sounds like this is the first time you have encountered such a phenomenon. Consider the possible results should you attempt a full-scale rewrite. What is the best case? The worst? Note that the worst is very very bad while the best looks to your users like *no change at all*.

Look, if you don't want to take it from us, maye you will take it from Joel:

"...the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch."

Go read that whole article. Then realise the best thing you can do is leave the working-but-ugly stuff alone, and make sure that all the changes YOU build on are working-and-pretty.
Larry Lard
Thursday, August 18, 2005
+1 Kyralessa.
Regression testing is going to be your biggest headache. For desktop applications, Visual Test (now sold by IBM) used to be reasonably priced, but I think it is now over $2k.

It is *possible* that this legacy app predates some of the functions that are now built-in.
Thursday, August 18, 2005
whoops, that came out quick. the "I've tried, let it go" remark was in regards to captain damage's post.

Regarding your comments, CEE, I am not asking for a complete rewrite, specifically for the reasons you mentioned, testing, tweaking, etc. I am trying to make a case for controlled refactoring, basically. Also, I am not saying the product is bad, from a concept perspective. I completely agree with its purpose and intent. What I am arguing is that it is a horrid mess that potentially a hundred or so people will have to support (from a source-code level).

Keep in mind, this software is not sold. It is installed at customer sites on OUR hardware and is maintained by us. If this was shrinkwrap software that was selling like hotcakes, I wouldn't even bother.

This is a perfect example of Joel's article:

The fact is, this is a tool that I have to integrate and support with source code in hand. If this was a compiled application that was released to us on CD (as is other software we produce) then this would not be an issue. I would only have its quirkiness to go off of plus it would be in an environment that I could not be a part of. However, since this is software that I am required to alter AND compile for each customer I place it at, I have a hard time promoting it when I can see its soul.

I am not trying to put a positive spin on this to convince myself to keep forging ahead, I just wanted relevant opinions.
Tobey Send private email
Thursday, August 18, 2005
"and the hits just keep on comin..."

Larry, I have read that article and I agree with some of it's points. But, again, I am not asking for a rewrite.

Peter, this application was written late last year. No chance of it predating built-in functions.

The simple fact is, the guy who is writing this really doesn't know VB that well and judging from the architecture, he is not well versed in software design (plus I know the guy). The reason this bad code works, is not a testament to him or his abilities, it is a flat-out testament to Microsoft's brilliant implementation of Visual Basic. If this application was written in any other language, it wouldn't even start.
Tobey Send private email
Thursday, August 18, 2005
"I am afraid the only way I will get someone on my side is to find a very terrible flaw (such as reporting incorrect freight charges or something) that no one is aware of, but I don't think there are any. "

That about says it all, right?
What again would be the business case for rewriting the code to use the build in format function?
Just me (Sir to you) Send private email
Thursday, August 18, 2005
Let me add one more link to the chain.

Larry [Lard] said:
> Note that the worst is very very bad while the best
> looks to your users like *no change at all*

Yes, that's true, but this isn't really about the user because, as I mentioned earlier, this is software that is owned and maintained by us. I am responsible for any bug fixes, alterations, improvements, etc. for any site I install it at. This is software that any one of 300 people can request and end up with the same resposibilities. Let me make it very clear that there is a high majority of these 300 people who could not and should not be making code changes yet they have to in order to implement it.

So, in regards to the "rewrite" philosophy for the sake of code-beauty, it is more to make the software more supportable.
Tobey Send private email
Thursday, August 18, 2005
How many support requests you have completed using the messy code base? How many of them were bug fixes, how many of them were feature requests?

Numbers, numbers and numbers.
You got to show them advantage in form of numbers for them to buy your argument.

If you get very low number of support requests then I would doubt if management will ever let you rewrite, no matter what.

If you get high number of bug reports and if you can prove that fixing these bugs is taking 3 to 4 times the time it should take because of code design, then you might have case.

If you get feature request which you are unable to implement or if the request will take a longgggggggg time to complete because of the code design, you again have a case for yourself.

If I were you, I would pull up the old support requests database, show them numbers and tell them that you will save X number of hours in bug fixing in future if you do rewrite and you will also make it possible to add whole lot of new features, management will listen up. Even after that, you will need to come up with strong rewrite plan which doesn't put business at risk.

Business people don't give a rat's ass to the messy code. They want it to just work or work better. Prove it that you will make it better (in terms of numbers) and you will get the permission.

Good luck,
JD Send private email
Thursday, August 18, 2005
You need to talk to those 60 placements and gauge the "dammit factor".. "what do you have to work around to get this thing to work?"
Michael Johnson Send private email
Thursday, August 18, 2005
As your post title reflects, you are emotionally involved. This is not a bad thing, but your responses to the advice here seem a bit inconsistent. You are on the fence about whether you are talking about a rewrite ("controlled refactoring" of a "fundamentally flawed architecture": seems to be splitting hairs to say that is not a rewrite). If you don't want to do a major overhaul, then you should recast your request to management as simply another way of doing your current job with a little more refactoring in the areas where you work on maintenance issues. If you want to do a major overhaul, then stop denying it and use all the advice you can get to put forward your case and to plan your attack. It failed with Netscape, and it probably doesn't make sense for your business, but you are passionate about it and will enjoy it, so go for it.
Anon and anon
Thursday, August 18, 2005
"This client application that has been developed by my peers is some of the most abhorrent code (VB6) ever written. It violates every rule of good software design, has no forethought of code reuse, "

VB 6 is a deadend.  Thinking towards re-useability has no upside. 

Using good software design is great for maintenance, but productivity is non-measurable for code maintenance, therefore "improving" is also non-measurable.  If it doesn't fit on the spreadsheet, it doesn't exist.

If there is a big market for the software, then present the idea to an outside party.  Let them create and market it.  If your companies version is junk, then it can be replaced.
Thursday, August 18, 2005

You don't need to talk to your boss right now about rewriting, or even refactoring.  What you do need to get permission to do (maybe) is integrate automated testing.  Research xUnit-type tools for VB6.  Then set up a testing framework.  Make sure that it works, it doesn't change your app's behavior, and it's reasonably easy to use.  And then, every time you get a bug report, write a test to isolate the bug.

This is what I'm doing in my company's product, which is hairy and ugly ("Why use ten or twelve functions when one will do?") and was totally without automated unit tests before I arrived and agitated for them.

They won't give me time to write tests for the whole app...and frankly, it would be terminally boring to do so anyway.  But every time I go in to fix a bug, I look for places I can put in NUnit tests that expose the bug.  Once the bug is fixed, NUnit shows green instead of red.  Then if later on a new bug fix breaks an old bug fix, I'll have a test to prove it.  In this way you build up a set of tests on your app that gradually make it less of a pain to maintain.

This is something you can do right now, without getting anyone's permission for anything, except maybe for integrating with the testing framework.  And the fact is that running an xUnit app and looking for a red or green bar is much faster than having to run the actual app you're working on and type in a lot of input just to get to a certain screen to see if something works.  It's even faster than manually inspecting Debug.Print statements.

So I think you can make an excellent business case for this much.  Then once you've shown your boss how much automated tests help with debugging, you can talk him into letting you put tests in place and refactor a few problematic areas.

No manager is going to approve a large-scale nothing-but-refactor task, because there's no clear business case for it; money's going out (to you) but no new revenue is coming in.  But by introducing it in this gradual way, you can make the long-term benefits clear, and also make it clear that you're competent to do it.
Kyralessa Send private email
Thursday, August 18, 2005
What Kyralessa said. Build regression tests way out the wazoo before you touch a line of that beautiful, functional, mission critical app that you have been assigned to support. One, just one, incident down to you and you won't be there.

Support <> write.

Write something beautiful when you are asked to write something new. Meanwhile, you're in maintenance mode - remove only sufficient cruft to fix the task at hand and be prepared to DEFEND every change as being ESSENTIAL.
Thursday, August 18, 2005
Choose your battles.

First off, make a point of not making things any worse, to start with. If you hack an already hacked system, it just moves you further and further away from where you need to be.

Every time a problem arises with the system, make a note of the root causes of time spent in the problem-solution cycle in terms of bad code/ bad interfaces/ inadequate logging/ whatever. This will enable you to build a business case for larger refactoring jobs.

Don't underestimate the impact of lots of small changes. Have a number of smaller refactoring things that you do constantly as you visit parts of the application. For instance, you might systematically clean up interfaces, tighten up those VB types, etc, in one area after another. After six months you will have something more pleasant to work with. Often you need to clean up lots of little things to be able to deal with the bigger things anyway.

At least your manager is not setting his face against time spent on re-engineering: that's definitely a good thing.
Matthew Morris
Tuesday, August 23, 2005
A huge problem is made out of lots of small & simple problems.

Solve the small and simple problems one by one. Once you're done with everything that's simple an easy look again at your initial huge problem - chances are it no longer exists.

This approach may actually fly with your boss.
Dino Send private email
Tuesday, August 23, 2005
Can I suggest something? Have you sat down and traced through the whole program, line by line, to see just how crufty the program really is?
Have you modeled it (flowcharts etc) and developed a good sense of the actual program flow.
If you have a really good friend at work who is like-minded, you could have her rewrite modules and see if you come up with similar rewrites which replace the same bits of code.
Before doing these things, the whole discussion might be academic.

How about going ahead with UNIMPLEMENTED rewrites in your spare time, especially for modules which would benefit the most from improved maintainability. So that by the time you get a request which translates to "We have to be able to enter codes on the fly through an interface instead of being hardcoded, OR, we need to read the city-names from a database instead of a text file" by that time your replacement code is tested and you've worked out most of the integration bugs. Any hiccups in integrating the code at that time is perfectly justified, because it had to be done, but you look like superman because you were 95% ready with the fix. How cool is that?

Anyway, how sophisticated is the average programmer in the department? Will they understand elegantly written code. Remember that mathematically elegant code is harder to understand than crufty code. Normally crufyty code sounds like bad english while some bits of elegant code can only be understood if you did calculus!

Another question to throw out generally is, how does migration to VB.NET affect the whole thing?

But don't fool yourself for a second. You could kill your career over it. If I was your boss and you messed this up after I got the permission for you to do it, I would personally make up a story saying "He told me it was a bug fix, not a rewrite". Then I would get rid of you real quick before they fired both of us. You have to be careful.

All of that said, I think the track you are on is very important and you could turn out to be the hero. It is much more than academic/emotional/aesthetic because there is inherent value in elegance, rewritability, maintenability, understandability etc.

Things can be perfectly fine for decades, then in 2 days all the paradigms that you held to be true can be shattered. And all the fears you thought were unfounded could come crashing in.

And I hate to sound insensitive just to make a point, but if you doubt this is true, think about New Orleans or the Titanic.

But again be careful. You can steer the ship out of an iceberg and straight into another ship. So don't throw away your career over the desire to produce code that would make your software engineering lecturer proud. Because at the end of the day it's about making the business sustainably profitable. Not about aesthetics.
David Send private email
Friday, September 09, 2005

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

Other recent topics Other recent topics
Powered by FogBugz