Coding beauty vs business needs

Question

All programmers I have met, myself included, always want to start a project that touches old code by "Lets rewrite the framework for this thing. It's old, fugly and unmanageble"

On the other hand, all sales/business people I have met will say "You will do the things that add functionality that makes us money"

If the programmers get to do as they wish 100% of time, the company will most likely have a hard time making a profit. If the sales people get way they want all the time, the system will become a huge pile of crud within a few years. Quality will decrease, and employee retention will become an issue.

Are there any good "Solutions" to this dilemma?

Answer 1

I wrote a BLAG about this, wont self promote by linking, copy and pasting below (hope this doesn't display too long):

We as passionate developers (or managers, CTO’s, help desk jockeys…etc) have one thing in common, we are attracted like moths to a flame towards the latest and greatest. If something new is coming out we are all talking about it, reading up on it, we could probably tell you five things it lacks before it’s even released. That’s one of the main reasons we are in this, all the cool sh*t we get to play with. This trait comes with a dangerous side effect, which is getting lost in the bright flashy lights of new technology and forgetting what we are here to do in the first place: solve problems and make the user experience more pleasing.

I have heard stories, and have seen myself, situations where a system has a hodge-podge of very cool stuff, but isn’t usable. Also, there are applications that have been refactored to death, turned into a bloated barely functional mess. What it means when this happens is that someone couldn’t find the balance between what they think is neat, and what will benefit the business. I myself am coming up on a project I am very excited about. When I first started the planning process in my head I was going to use MVC for URL rewriting (ugly url’s are becoming inexcusable) and LINQ for my SQL and I was going to set up all the designers with the Expression Suite and it was going to be the pinnacle of forward development and everyone would be impressed with what I knew. However, after taking a step back, realizing that organizing a project like this is new for me, I decided to go with more familiar methods like active record sets and stored procedures. The new things I am going with are the 3.5 framework, and VS 2008 from 2005. Why? Well, they both cost me very little “learning overhead” time and the 3.5 Framework is better with paging than 2.0 and VS 2008 has better JavaScript debugging, two things that will save me a lot of time. (seriously, how did it take this long to get good JS debugging? It’s only been around as long as, I don’t know, the internet?).

So, how do we avoid this issue? What are some questions we can ask ourselves that will help us choose a good advancement over one that will spin our wheels but not benefit the application. Well, let’s start at the part where you find something exciting. The first thing you need to think of is your feature debt, what does it look like? How does adding this element to your existing application help to lower that debt? Will it save you time that you can use for development? If so, how much time? Will it eliminate some of that debt? Really? Will it, or are you just saying that so you can feel better about playing with it?

Another great way to tell if your investment is worth taking is to convince your end users or project owners that it is. Non intar-people don’t want to hear about refactoring, or code integrity, or WPF. They want to see bright shiny flashy things that look cool and make their lives easier. Convincing them that they need something they’ve never heard of and don’t care about will be a great barometer to see if this change is worth making.

Someone called the solution this quandary an Aristotelian Mean the other day. I had to look that up, but it basically means a perfect balance between two extremes, which is applicable only if you can attain it. Perfect code is beautiful, but if we keep going back and second guessing ourselves we aren’t always helping our users. All my advice is well and good, but while I have the knowledge I lack the experience of finding this Golden Mean between these development poles. I’m sure I’ll learn on my way.

Answer 2

find midle ground :) This is one of the issues discussed 20 years ago in Peopleware, and conclusion is basicly: you have to give programmer some liberty to make things right. On the other hand I acknowledge the fact that I would hardly get a job done, if always polishing things to a perfection...

Answer 3

At some time you have to pay your design debt. Business people understand credit and debt.

Some business people understand you cannot maintain constant high growth every single quarter.

Use their language :)

Answer 4

I think you're looking at it from the wrong angle. I like to look at software development as being 80% maintenance usually. This percentage could be greatly reduced with a well written code base. Usually that doesn't happen, so it becomes a requirement to upgrade the code to improve developer efficiency when it comes time to maintain the system.

Imagine how much more efficient development can be in the long run with "beautiful" code. This makes everyone happy because features eventually take less time, and developers require less work to get things done.

Also, consider bugs. Bugs can cost a business money. Maintenance could be spent to reduce bugs and thus save a business from potentially losing money from a major bug.

Answer 5

The first step would be for the programmers to take a deep, hard look at themselves and ask them if they really believe it is worth it. I think most (good) programmers just have that gene that makes them think "Gee, thats a mess, let me clean it up just because I can". Make them make a cost-benefit analysis and if that comes out positive then maybe it is a good idea. But maybe it would be even better to just rewrite a part of it to create a bridge between the old and the new system. Of cause it all depends on how much the nature of the old application affects the new one.

Joel Spolsky talked about this on one of their latest podcasts where some banks allowed their smart programmers to rewrite the code base every couple of years just too keep them from leaving for more exciting jobs.

Answer 6

Like most things in life, there really isn't a clear black-and-white answer here.

You're right that either extreme is going to hurt the business, so the key is to find a compromise. Developers need to realize that there is a time and place for overhauling the system architecture and a time when things need to just get done. Similarly, business people need to understand that developers are going to need time to restructure and regroup from time to time and that by not doing so they're only setting themselves up for less business down the line.

Answer 7

I think really beautiful code is the code that is elegant but functional and more than anything else maintainable, almost by definition. Writing really beautiful code is always worth it, but obviously there is a cost/benefit limit at which it becomes uneconomical to polish the last possible detail down to perfection.

I think the real difficulty in enforcing a good balance between code quality and timely project delivery is that those who are in control of the timetable often have no understanding of the technical implementation details the programmers are aware of, and vice-versa.

Though I've never experienced it personally I think that perhaps the key to attaining this balance is to try to cross-pollinate between the two departments; ensure the management have at least a working knowledge of programming and the programmers have at least a working knowledge of project scheduling and business needs, perhaps even getting both parties to do the other's job for a day or two each month perhaps. This way you can obtain perspective. That' probably a bit of a crazy idea, but I think the company should at least attempt to train both parties on the justifications for their approach.

Unfortunately getting real I think most places just 'don't get it' because half the programmers who want to 'improve' things aren't necessarily that good and most of the management simply don't have an inkling of the benefits of putting more effort upfront for better quality results in the long term. I guess that side of the problem will remain unsolved in all but the best companies.

Answer 8

Uncle Bob (Robert C. Martin) was writing about this not a long time ago. The essence is that instead of rewriting the system, it's better to improve it incrementally. You clean up parts of the code as you make changes to it, and keep the system running at all times.

The book Working Effectively with Legacy Code (I have it, but have not yet read it) explains some ways to work with legacy code so that you can improve it (by Michael Feathers' definition, legacy code == code without tests). There's also a short version of it available publicly.

Answer 9

If continuous refactoring is built into all processes in your company, then marketing is still getting their incremental value, only at a slower pace. However, since it is up to the technical management to determine schedules and process, it is up to them to make the tradeoff and time division. Marketing is usually more concerned with immediate sales, while the responsibility of engineering is to think about long term concerns.

Answer 10

Hello, Tnilsson, nice to meet you. I am a programmer who tends to start a project that touches old code by saying "This thing is old, fugly and unmanageble. How can I clean up the parts that I need to touch?" I then go in and change as few sections as possible to complete the work that I've been hired to do.

In the process, I will refactor to improve those sections, but always with an eye towards keeping the style similar enough to that of the existing code (horrid though it may be) so that I can expect the original programmer to be able to understand what I've done. (Unless the situation is such that I expect to be the primary maintainer from that point forward, in which case I will make the revised version as good as I am able.)

Every line of code I change is another opportunity for me to introduce a bug, so, in most cases, it is best to leave the working portions of the code alone as much as possible.