Is good code design sometimes a professional vanity ?

Question

I had this discussion with a manager in my company. I tried to explain to him the difference between simply writing code that solves a problem and doing actual engineering work where a modification is thought over in the context of a bigger picture. Now this manager has a BA in CS under his belt, so I was very surprised to encounter such a strong opposition to my explanation. The way he described it, it is up to management to decide whether to invest company resources in better design now or in code maintenance later.
to put it in his own words "you will have this release delayed just for the sake of your software engineering principles"

I was left speechless and more then a little insulted, is that what software engineering boils down to? is all the stuff I learned at school just some sort of ideals only applicable in an ideal (none existent) world?

I am now adding a few more nested if-else to a function over 1000 lines long and who knows how many if-else . I have never felt less certain about my decision to be a professional in this area. Is my current company, the exception or the rule? What is the point of spending 4 years in college when a simple programming course can achieve the same results?

Answer 1

Hes being a bit silly and most likely lacks experience with software development with multiple releases, and changing demands. Good design is a requirement if a piece of software is expected to be adaptable.

Answer 2

It is management's decision on whether to spend time in design now, or in debugging time later. But it's almost never the right decision to rush code.

Fixes made at design time are easier to catch, and less costly to fix, than fixes made in the final stages.

If you're being pressured so strongly to push code out, then do so... and be sure to push out your resume to other companies.

Answer 3

"you will have this release delayed just for the sake of your software engineering principles"

Shipping is a feature, sometimes it's one of the most important features.

Yes, some of the theory you learnt in university isn't applicable in the real world. One of the sticking points I've had when working with recent graduates is that they are taught there is one way to do things and that's the only way. "Breaking" them so they're open to other ideas takes time. Really, trying to tell someone you know the right thing to do for them when you're fresh out of college and a junior on the ladder may well be a career limiting move. The amount of investment put into design, development, maintenance, features, whatever is always going to be limited - by money, by demand for shipping, by users, by management, and as a junior developer you are not going to see any of that, if you're very lucky.

Is my current company, the exception or the rule?

I'm afraid to say it, but welcome to the real world.

Answer 4

Your manager should read Robert Martin's excellent "A Mess Is Not Technical Debt". It explains why the "just-get-it-done" approach is not always the best one. In some cases the apparent tradeoff between a well-designed solution which takes longer and the quick solution which takes less time is not actually a tradeoff at all -- the quick solution ultimately winds up costing the project more.

The way he described it, it is up to management to decide whether to invest company resources in better design now or in code maintenance later.

Your manager is right, but only in the most superficial sense. By analogy, it is also up to the management of aircraft companies whether they will invest company resources in rigorous safety practices now or set aside money for litigation defense later.

Ultimately, he must trust his team and technical leads enough to get the job done, and certainly to know when to spend more time designing and thinking through solutions.

Answer 5

Let me talk about the part on spending 4 years in college vs simple programming course.

A little background about me, I started programming when I was age of 12 (not boosting, but life experience, so read on). Back then I had no clue about what MVC, OOP, and all that other design architecture are all about.

I was just a chap who wrote procedural scripts that execute and I was happy about it.

Then when I came to polytechnic (currently pursuing Diploma in IT), I realized there there are more to what's programming. All these that I am currently learning can never be understood from a simple programming course.

Everyone can program, but the level of proficiency, ease of code maintenance, and so on are all different. Some can code pretty well, but can't really maintain code. Some can read and understand code written by others and maintain it, but not really coding from scratch.

I admit that some good designs are not actually taught in college or polytechnics. Only studying them on the free time will help to understand. For example, in school I was never taught the use of MVC, at least not yet. I went on to build websites in PHP in order to understand what's really behind MVC.

Having studied 4 years in college and a certificate in hand helps you to better get a job. But again, the certificate can only get you the job. It's actually you that maintains that job! Same rationale as the design vs deadline isn't it?

Answer 6

The term coined by Martin Fowler to describe what your boss is referring to is Technical Debt, the build up of crufty code hat has to be "paid back" (i.e. refactored properly) at some point.

Real-life software development is about balancing good engineering practice with quick-n-dirty. It's about managing the technical debt to ensure the business gets the maximum (business) value from the software in a timely fashion vs. the long-term total cost of maintaining that software.

Ultimately the business has the call on whether to get it done quickly or get it done right, don't take it as a personal affront on your credentials - in fact, kudos for caring about writing decent software. I've worked with enough people that don't to know it's a truly valuable thing.

My advice to you is to get some evidence of the benefits of rewriting the particularly smelly bits - number of bugs they've caused (and the time spent) vs. the time required to rewrite properly for example - and present these to your boss. He may still ignore your request of course, but at least you can feel you've done the right thing.

Another thing you could point him at is the evidence presented in Code Complete which says that the later you find bugs, the more costly they are to fix. Finding a bug in system test vs design is something like 25x more expensive to resolve.

Answer 7

Whether we like it or not, the one who pays the bills sets the rules. That is the way of things.

Answer 8

There are genuine technical points here but the real calling is for non-technical skills (mainly communication) which is often glossed over during technical education. Not all people are reasonable at first and your ability to phrase your question, lean on him, show him the advantages of doing it right and the disadvantages of doing it wrong all are factors that finally decide whether you can actually put the skills you gained during your education to actual use.

That being said, it is sometimes the case that developers use "we need time to come up with a good design" as an excuse to procrastinate. That might itself be because they were put off by earlier management practices and don't care or just because they're sloppy programmers so the demand for good design is sometimes a negative.

The world is a lot more complex than just good algorithms and coding practices. Welcome. :)

Answer 9

Technical debt is double edged, and I actually support the manager's position. It is their call where resources are spent. Essentially, choosing to accrue technical debt now (but ship sooner) may:

• get to market first - this is often very important
• allow the product to start gaining revenue, or see if it has a market
• allow the team to balance their resources between different projects, each with different timescales

Even if it costs more later, deferring the work can be the right decision.

What it looks like under the bonnet doesn't matter at all to the customer if it works. If it is a bad concept, it won't sell, and the manager made the right call not adding extra cost. If it is a good concept and gets to market first, you can "pay" for the debt with revenue from the first customers.

Professional perfectionism isn't always about doing the best thing - it can be recognising when you are taking a shortcut, and logging it so that it can be addressed at an appropriate (perhaps less critical) time (perhaps when you get an intern).

Answer 10

It depends how close to a release you are. The risk of a regression from refactoring might outweigh the cost of doing it the ugly way, if it is close to release time. Leave a 'refactor me' comment so after the release you can go back and fix it... but tell said manager you are going to do that, because next time it's going to be harder. And point out that eventually, if he won't let you refactor, something is going to come along that will force the refactoring, and that feature will take forever to do because there will be layers of refactoring on refactoring necessary before you can get there.

I've been in the manager's position, and I understand where he may have been coming from... but at the same time, as a manager you don't lay yourself a minefield for future work unless you understand the consequences and are prepared to accept them. So it's your responsibility to get into the manager's head and see if he understands what the consequences of his decision will be, and teach him what they are if he doesn't understand. That will help him do his job right.

Answer 11

A tale of two teams:

Team "Sloppy" cranks out code, features, and releases at a fast pace. Nominally, they are successful. Sloppy's manager now has a defensible track record of accomplishments. Product has shipped. Revenue has been earned. Users have new functionality to chew on. But over time, technical debt and complacency accrue. New features can't be easily added. Old ones keep breaking. The software's latency increases. Suddenly, one day the overall company wakes up to find itself no longer competitive. Somebody else is eating their lunch! Everyone had become too myopic, too focused on the short-term. But Sloppy's manager has since been promoted and moved on to another company. So have the engineers, who grew tired of being technical janitors and maintainers of the status quo. If only the company had taken more time to invest in their foundation and their future. But now they are behind in the marketplace, having been weighed down by the legacy monkey on their backs.

Then there's Team "Purist", who is obsessed with writing Great Software. They truly care about the quality of their work. They are willing to take their time and refine their designs, write and throw away prototypes, and refactor their code. When their software is finalized, it will endure for 10+ years. Users will love it. Future engineers will be grateful for it. And this software will be an indomitable part of the company's overall intellectual property. So, Purist is given a large budget and a wide schedule. Months turn into years. They keep making progress, learning new things. Yet it never seems they get closer to being done. Eventually, they become mocked by competitors for seeking infinitely generalizable, configurable designs that effortlessly map into larger problem spaces yet forseen. "Just think of all the time we might save ourselves in the future!" But that future never comes. One day, the company wakes up to find itself out of money and time.

Both teams strive to be relevant. Ironically, both fail in their own way.

Answer 12

Maybe it is a bit drastic, but in your case I would do:

• try your best to convince him (real world examples, success stories, articles etc.). If he tends to like shiny slides prepare a nice power point presentation. If there is budget for it get a consultant (weirdly enough managers often trust consultants much more as their own employees).
• if he doesn't get it, just don't tell him that you are refactoring or improving software quality. Include the efforts to the normal estimations.
• if he is still opposing you and you can't do the work, find another job. I know this is a hard one, but it makes you much more happy in the long run.

Even if people have university degrees, they could end up in thinking/acting too theoretically (they aren't able to realize projects and have hardly hands-on experience). Don't get me wrong, university degrees are a good thing (I got one myself), but it doesn't make you necessarily a good software engineer.