Is there a place for well thought out, creative, clean, and tidy code in commercial software development?

Question

Let me set the scene.

The Scene

We're a web development company, and so we work within a highly distributed environment. DB Servers, Services, Web Services, Front-end, Back-end, etc etc. I'm not sure if that's relevant, but there it is.

Essentially though, at it's most basic, we develop custom web solutions, and maintain one large CMS application, which we use to leverage 80% of our projects.

The Problem

The CMS application works, kinda, but it has to be customized and changed almost all the time for each project. Every time I go in it, or fix the same problem over and over again, I want to cry.

It just could be so much better, and in it's current form, it's very inflexible, and rigid. For example:

• There's repeated code all over the place
• Global business logic is spread out all over different layers, multiple times, making it a dog to change, anytime anything has to be modified
• there's loads of god classes, and the structure doesn't make any sense
• etc etc.

Not only is this ugly, and annoying, but it makes it prone to bugs, and hard to extend. For example, it would be great if the CMS worked at an API level, but because there's business code all over the UI, it cannot.

The Question

I would love to discuss with my peers solutions for these problems, and fix/rewrite a lot of the issues in the application in a collaborative effort, because I believe it would have a lot of long-term benefits.

For example, it would make each individual project take less time, because there would less bugs to fix. It would make customizing easier, and it would make extending and building a better application simpler.

However, I realize this would be a relatively massive undertaking, and thus would cost a lot of money.

The alternative, which my seniors dictate, is to keep hacking the application each time with quick, non reusable "fixes", which I hate, but it does make it "work", doesn't take THAT long, and so perhaps makes more economic sense?

Who's right? Am I just an idealist fool?

The question is, should I approach my seniors and make a case for it, or not?

UPDATE:

Hey guys, I know my question gets a bit specific towards the end, but I'm really enjoying all your general feedback, and the experiences you've had, and how you dealt with it.

Thanks again, keep 'em coming!

Answer 1

I don't even have to read the rest of your question, only the title.

The answer is yes.

There is no place for carelessly thought out, un-creative, dirty, and unkemp code in commercial software development, Unless you're writing it once and are going to throw it away and never use it again or maintain it.

---

In a perfect world, we could spend all the time we wanted perfecting our code and giving it the polish you describe. Unfortunately there are many factors that conspire against that. Time, money, the pointy-haired boss, the clueless consultant, inexperienced programmers that were hired over the summer to save money, etc.

In the end, sometimes you just have to write code that works.

---

When you are building applications like yours, it pays to have some planning and foresight. The economic case for writing better code in a CMS is reuse: writing the code in such a way that that it can be reused over and over again, with customization relegated to configuration changes.

There might be an economic case for that if you can prove that the money spent to write the better code will be recouped over a period of time. Any savings over and above that would be pure profit.

Answer 2

It's tough, I think we all work on code like that at some point.

Some people are fine with it and can work on it happily. Others like myself can't and eventually get fed up and move on to a new job.

Eventually we realize that most code is like that and just do our best not to write our own code poorly.

Good luck!

Answer 3

Yes, but maybe not at your company. If your company doesn't prioritize things the way you think they should, you should think about moving.

If the market won't permit you to move, you'll just have to remind yourself that you're following in the footsteps of hundreds of generations of people not liking their jobs.

Answer 4

Frankly, your company is extremely badly managed for this situation to persist. It seems that management are not well versed in managing software projects. I left the last company I worked with for pretty much the same reasons that are making you cry. At my estimate, we could have lowered costs by around 20% per project with an outlay of a couple of dev months. Due to the perpetual fire-fighting, not seeing the wood for the trees, blah blah, the time was never allocated. The savings on a single project would have covered the cost. I only wish I'd left sooner.

Answer 5

You have to balance the risk of the work you want to do against the cost of doing it (and the ongoing cost savings). The immediate cost can be easily calculated, its the number of hours required to go through the codebase multiplied by the hourly rate of the developers.

The risk is a little harder to quantitize - what stops working if you screw things up? What is the cost in time/money/reputation if you have a screw up?

You should also expect some disagreement from your colleagues. Some of that is just the natural inertia to change that some people have. You have to also consider the job security they implicitly get because the codebase is so messed up. If you tidy it up, there will be less ongoing maintenance work, and possibly less developers required :)

Answer 6

I've been in almost this exact situation. The problem is that the CMS needs quick and dirty customisation for most projects, and the more different people work on it, the messier it becomes. Eventually you'll incur so much technical debt that it will be more efficient to start refactoring the system than continue using it.

You'll need to make a good business case for the refactoring, fixing and consolidation work, and convince the decision makers that, in the longer term, it will make development more productive and the product easier to customise in future.

Answer 7

You should probably start keeping a waste log for a while. Just one week, time everything you are doing what should have been refactored, and note down the time spend and a short description. From that, you can provide an estimate of design debt you're having. After a week, review your notes with your direct colleagues, and ask them if your results match their expectations. If not, ask why, and refine them (or even better, get some other developer to also keep a log).

Only then create a presentation for management on the costs of design debt. Also provide some sheets on possible solutions.[edit] For each solution, show business value, risk, and implementation costs (1 to 5 stars is good enough). Sort by business value. Then show a suggested approach. Go for early success, to validate your results. And present those results again.

[edit]You should be aware that from a management perspective, schedule reliability is seen as a very nice property. With a large design debt, all planning unreliability of new functionality is hidden. When the code is clean, your estimation precision will be a lot worse.

Answer 8

Yes. Anyone can bang out small applications in short time frames, and can get away with messy code and inefficient production practices, if they can throw it all away and start fresh on the next project. But this isn't scaleable.

The cheapest and most effective way to develop software in any ongoing sense is to put effort into your development environment (libraries, tools, practices) so that they are as foolproof as possible and provide robust and efficient workflows.

As you develop more warts as add-ons to any system, any legacy design flaws will be magnified, and the complexity/cost of resolving problems will increase. Ultimately, untidy code/practices are unscaleable and will reach a point where everything grinds to a halt (you'll spend all your time firefighting bugs instead of developing features).

The earlier the codebase/libraries/tools/documentation/practices are made reasonably tidy, foolproof and future-proof, the less effort it will take - so in every respect, the earlier you fix this the better. If you think "this will cost to much to do now. Let's do it later", when "later" arrives, it will cost twice as much to fix, and will therefore be four times harder to fit into your schedule.

A typical small example: Programmer manually builds an installer by copying files into a zip, which "only takes 5 minutes". But every release involves more work and after a while the programmer is spending several hours doing this manually every time, and making occasional mistakes that result in a broken installer. Alternative: Programmer spends two hours up front writing a batch script that automates the task. Every installer he builds then works perfectly and takes only 5 minutes of the programmer's time to build. After a few months, you hit break-even, and after that you start saving a lot of money with every release.

Answer 9

Some thoughts:

• Do you have a technical ally at your "superiors'" level? If so, convince that person and have him evangelize your stance to his peers. It will improve your credibility.

• Expect push back unless you have a solid financial case. From a management perspective it is very easy to dismiss a programmer's "idealistic" and seemingly subjective viewpoints. Back them up with hard numbers and you'll get the attention you desire.

• Consider in your proposal an intermediate, incremental option. Can you make some progress toward your goal by breaking it down into bite-sized chunks? It's easier to swallow a moderate refactoring exercise than it is a ground-up rewrite.

Remember that your company has a lot invested in the current product, and they want to see a return on that investment. Asking for a whole new investment, just because you don't like the results of the first one, is not sound. Be prepared to work hard on your proposal, to make it financially accurate, and to have it questioned extensively. Be prepared to show that you care about the business, and not just the code.

Best of luck to you!

Answer 10

First learn to write code which does not rot when the project is maintained, but instead gets better as time goes on (TDD/BDD, Clean Code, Boy Scout Rule, DRY, YAGNI, SOLID etc.). Learning is easiest done in small greenfield projects.

Then when you have the skills, apply them to the legacy projects and improve them gradually (Working Effectively with Legacy Code, short version also in PDF). Gradual improvement is easier to sell to the management than a big bang rewrite (not that a rewrite would even help in the long run, unless you know how to write code which does not rot, and in that case you would anyways be able to improve the legacy code without a rewrite).

Answer 11

It's the old saying of:

You can have the project quick, cheap or good.
Pick any two.

The problem is deadlines are usually the most pressing and driving concern in many real-world situations, and of course almost every client (project) - internal or external wants to keep costs as low as possible. So you've got your "two": quick and cheap. Which means you start sacrificing on good.

Quick and good sacrifices cheap.
Cheap and good sacrifices quick.
Quick and cheap sacrifices good.