After working in a number of companies, I am starting to realize that my commitment to writing high quality, well tested software, does not necessarily lead to career advancement, especially when managers with non-technical backgrounds do not see the benefits of maintainable code, and prefer developers who have a semblance of high productivity, while racking up mountains of technical debt.

That said I tend to stick to well written code to because I find it intrinsically rewarding - that feeling you get when you know you have done a job well, even though you know you won't get credited for it.

In part I can close the productivity gap by adopting different technologies and approaches while still writing clean code - solutions include dynamic languages, polyglot programming, and convention over configuration.

This question came from our site for professional and enthusiast programmers.

marked as duplicate by Mark Trapp Aug 11 '11 at 1:30

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

9

For the most part, yes. But as you said, the higher-ups look at results more than maintainability. Craftmanship starts paying off when you start working in companies that use Agile development methods where there are peer code reviews and such. That's when managers can see outside of the "what works" area.
–
JonJun 7 '11 at 10:24

12

For career advancement it does NOT pay off as much as schmoozing with the boss does. But for your sanity when you have to maintain the code it does pay off
–
DaveoJun 7 '11 at 13:01

Sometimes it's OK to buy plastic furniture from WalMart that lasts a year, other times you want to invest in furniture from Stickley that last generations.
–
M. DudleyJun 7 '11 at 19:21

3

When you're looking for a new job... every dev that you've worked with that has had to work with your code will likely be pleased to give a good reference... that's a big pay off in my books.
–
Steve EversJun 8 '11 at 2:12

16 Answers
16

In my experience, the answer is sadly no. I've lost many jobs due to my wanting to push a culture of craftsmanship over sloppy hacks, design patterns over procedural code written as object-oriented, and embracing new technology over staying with obsolete legacy tech. Note that I don't regret those choices, but the reality is that very few of our developer brethren know or care about craftsmanship; I dare say that there are many more of us who could care less about the "right" way to write software, or are even completely ignorant that there are better ways than the way they've done it for years. Of course, I try to write my own code with craftsmanship in mind but it's largely a futile effort, and often when you have code that follows no craftsmanship whatsoever trying to add even a little bit is painful. Even the jobs I have kept, I've been relegated to minor bug fixes instead of working on new things (because were I assigned to new development, I would try to introduce my "radical ideas" i.e. craftsmanship), to the point where I eventually get fed up/bored and look for another company in the hopes of finding one that understands craftsmanship.

I look at and envy the people who have gotten into environments where they aren't the only person who knows about software craftsmanship, or the SOLID principles, or ORMS/IoC/SOC/etc, because they don't have to fight uphill battles trying to tell people that no, it's bad to lump all your functions in one gigantic class that might as well be a VB6 Module; it's bad to have a code file that has a method that goes on for a thousand lines; it's bad to put all your logic in the event handler of a button. They don't have to risk getting fired because you keep trying to educate your team about new and better ways of doing things; ways that will improve the longevity and maintainability of the codebase, only to be met with confused looks or dismissal because you're the only person who even knows why that is a good thing, or you are the only person who subscribes to technical blogs/podcasts to improve yourself.

In six years working as a software developer, I've had exactly one job out of six or so companies that actually cared about craftsmanship. Every other place didn't know or even understand the benefits - trying to explain things to the others on the team got this strange "Wha...?" kind of look, as though they didn't understand anything I was saying. The companies would rather have kept the slothful developers that didn't improve anything and refused to even be aware in passing of anything new, than encourage proper development techniques that would facilitate maintenance long-term, instead they are all too willing to sacrifice long-term for the short-term. Every single time.

To summarize: Craftsmanship will only pay off if the whole team embraces it. If one person embraces craftsmanship and the others don't know what it entails, it won't pay off at all and will probably hurt you.

ADDENDUM

Just to prove my point, I wrote this in June 2011. I was let go as a developer at the company I was working at in July '12 for exactly the reasons stated here: Over that 13 month period, I was trying to push us towards using some semblance of craftsmanship instead of hacking out crap that was unmaintainable (to give an example we were trying to sell our internal CRM software to other companies, when it could barely support the 70 or so users we had internally and had to be restarted several times per day due to crashing). A "senior" dev thwarted my efforts each and every step of the way and the non-technical CTO always sided with him despite telling me in person that good quality was a goal, and it culminated with me being brought into the conference room with the CTO and HR to be told that my development skills were "not [my] strong point" and the company wanted to go in a different direction than the one I was trying to push (i.e. an environment with things such as code reviews and code conventions and craftsmanship), and that my services there were no longer required.

It took me nearly 5 months to find another job, and that job doesn't do any development at all beyond some SQL; I work with proprietary applications all day long, and my will and desire to ever do development again is all but gone because I'm tired of scenarios like the above all the time. I recently had two job interviews where I wasn't considered for the position afterwards (the old "We've gone with another candidate" excuse) because, I think, the companies felt that I wouldn't be on board with "their vision of the software" largely, in part, to my enthusiasm in wanting to follow good design principles and adhere to software craftsmanship.

So to reiterate what I stated over two years ago: In most cases, at least from my experience, craftsmanship will get you fired or disqualified from being hired if nobody else gives a damn about it, and most companies don't give a damn about it; most companies don't even know what it is. Every time I've mentioned good design or things like ORMs or the SOLID principles or anything like that, I'm used to seeing blank stares and this sinking feeling that I've just shot myself in the foot because the guy interviewing me has zero clue what these things are. Sadly, that sinking feeling has proved to be correct each and every time.

Perhaps, but most of these changes are things that should have been in place in the first place if the team had any real competency and knowledge. I'm sorry but I don't ever see a situation where choosing the wrong way is better than the right way; if the codebase is already done that way then it's a serious issues that needs to be recognized and addressed, not just ignored. And sadly I seem to be the only one who recognizes the issues.
–
Wayne MJun 8 '11 at 12:06

3

Okay, I can agree with that. But would you not agree that in most cases it's better to do that from the start, and have the "core architectural parts of the codebase" done properly to begin with? That is the major problem I run into - I'm often the only person on my entire team, if not the whole company, who even knows proper software engineering concepts in the first place!
–
Wayne MJun 8 '11 at 12:47

2

Also, the thing I've noticed is that good developers can write good code quickly, probably quicker than the bad developers can hack together stuff. It is possible to write well-architectured, maintainable code without it taking an insane amount of time, and doing that sets a proper foundation for the future.
–
Wayne MJun 9 '11 at 12:18

11

Has anyone else slipped into mild depression after reading this and realizing it applies to them?
–
Mike WellerFeb 9 '12 at 12:51

In 2000, research found that up to 90% of the total cost of software systems was spent on maintenance and evolution. Overall, research has found that at least 50% of the cost of a software system is in maintenance.

In the US alone, annual maintenance costs are approaching $70 billion.

By spending the time to follow good engineering principles from the inception of the project through the time the system reaches end-of-life, these numbers can be cut down, which is good for your organization's bottom line. There are many facets here, ranging from producing effective technical documentation for future developers to shipping well-written code and tests. You might spent a little extra time making it better now, but it will pay off in maintenance phases down the road.

Very good answer, but missing the boat. Clearly, none of the above matters to a non-technical typical business manager, since their focus is not on long term cost savings, but on short term output. Sad, but the truth.
–
wolfgangszJun 7 '11 at 15:17

3

There are companies that can be convinced of the impact of code smell, and those that can't be made to believe it, let alone care. Do your best to find the former -- they are out there.
–
HedgeMageJun 7 '11 at 16:33

1

@Thomas Owens Take a look at codesqueeze.com/…, it proveds a bit more context. That perspective provides a nice way to "translate" between technical speak and money speak, and allows developers a better way to provide input to management on time vs. money type decisions.
–
deterbJun 7 '11 at 21:11

Does craftsmanship pay off? It does, but you need to take it to the next level.

Start your own company and offer a product which beats competition. Then you will yield all of the results of your good work along with your own customers.

In most employed jobs people strive for recognition and never find it. In many cases when this recognition comes it does but much later when the person has already moved on to the next place. Then you will be remembered with good words, but effectively postmortem.

Here is a choice my team had once. The company I worked for turned over 10million/annum. The division I joined was loosing 500K/Month, the business was financed by a security on the bosses house.

Choice 1. Best practice. The whole lot..... would have bankrupted the owner.

Choice 2. Major trade show in 10 weeks. 8 developers, war mode. No design, no docs, no tests. The owner sold 3 years later and put 50 Million into his personal bank account, with the division turning over 200 million. (what an exciting ride that was)

The code was, by any software standards and putting it bluntly, crap, undocumented, unmaintainable and unreadable. It was however ( surprisingly even to me), reliable.
By any business standards, the code was beyond reproach.

The highlight of my career to date, "writing crappy code that made bucket loads of money, and proud of it, because I did exactly what I got paid to do."

(I am playing devils advocate just a little here):
Too many software devs forget who pays the bills, and what they are being paid to do, and use "craftsmanship" and "best practice" as an excuse to over engineer.

Every proponent of BP I have seen is a) A Vendor, or b) an Academic. You rarely see an accountants view on BP published, and rarely see full cost analysis including Capital cost, cost of time, opportunity cost etc factored into the BP benefits.

You're forgetting one valuable point: Applying best practices may not be a 100% sound business decision now, but it is a 100% sound business decision later because it ensures the code can survive and be maintainable down the road without being a total pile of garbage that should be thrown away and rewritten from scratch. Yet you also illustrate a fundamental issue with modern businesses: They are insanely short-sighted and don't care about the long term solutions, only the short term ones.
–
Wayne MJun 8 '11 at 13:01

1

Would you expect your "make trade show"-code to live for decades? If not, then the maintenance fee difference will not apply.
–
user1249Jun 8 '11 at 19:21

3

I am absolutely not forgetting "one valuable point", I am arguing that "Craftsmanship does not pay off" in most situations. The problems with SW engineers is that Craftsmanship is synonymous with "Over engineering". True craftsmanship is not only perfection, and minimizing total cost, it's paying the weekly bills on time every time.
–
mattnzJun 8 '11 at 21:18

In my experience, when most programmers talk about "craftmanship", they usually mean over-engineered code often pre-designed to handle future features. The concept of "just good enough" is often confused with low quality, and considered the opposite of "craftmanship".

On the contrary, the most well-crafted programs are simple and direct, contain barely enough code to do what they are supposed to do and are easier and faster to write and test than sloppy programs. It's the clever tricks and planning for a future that might never come that take up the craftsman's time and make him slower than the sloppy programmer.

Craftmanship pays off when you're in maintenance mode rather than trying to get a new product out the door quickly.
As many products never reach that stage, or if they do the maintenance contract is awarded to a different company from the one that originally created it, you might never reap the benefits of your own craftmanship directly, but others might well remember your name on a particularly hideous construction when and if they ever meet you during a job interview years later and hold it against you.

+1 On name recognition! This is especially true if you live in a smaller city like I do. If you plan on settling in a smaller city area for a long time you may end up working with certain people again sometime in your career as there is a limited number of large employers in the region. At one place, one name came to notoriety amongst me and my peers, someone who used to work at the company who wrote the legendary 15 level nested loop. Later in my career his resume came to my inbox, which I recognized immediately and tossed.
–
maple_shaft♦Jun 7 '11 at 11:17

1

While maintenance mode may never be reached, if you ever do get to that point and you don't have at least decent code, dragging the code out of that pit is a long, hard, process.
–
deterbJun 7 '11 at 16:54

I'm going to agree with some of the answers and slightly disagree with some. I love @Thomas Owens link to the numerical data on maintenance. It really drives home the point of how much maintenance is out there and how much time/money you can save yourself with a little bit of craftsmanship.

Several people have said that craftsmanship pays off later, but only later. It definitely pays off later. Either you end up maintaining good code yourself and save yourself time/money, or you pass that code on to someone else who sends out warm fuzzy heart-shaped happy thoughts every time they see your code and see how easy it is to keep it up.

Some have said that it doesn't pay off now. I highly disagree with this statement. I have worked in several environments where change happens rapidly. In some cases (to quote a movie) "it catches you right between mouthfuls". If you have well-crafted, readable, structured code within a solid framework, when these changes come they are much easier to deal with. I have found personally that having a good back-bone structure for any project helps to mitigate requirements changes either because the business is indecisive or the customer's needs evolve rapidly.

On the same token, I have recently witnessed a situation with a co-worker who did not have a good back-bone to his project and writes lamentably unmaintainable code on a regular basis. When the requirements changed on him, he was forced to take much of his work "back to formula" and start again at the beginning.

The problem is that most IT-related organisations are young and have not yet had time to realize that regardless of scope software is expected to live for long, and it needs to be built well to be able to do so properly without hideous expenses when changes are needed.

This implies that you need to find a job in an organization where this realization has been done and the way of working adapted accordingly. If not, your efforts will not be appreciated which is very unsatisfactory.

It's not about the technique's of being a craftsman, but about being a craftsman. Would Leonardo ask himself whether it was worth the trouble painting in oil? Would a expert carpenter ask himself whether he really needed to carefully sand every part of a piece of furniture he's making?

No, we're craftsmen and that's what we do. Doing things differently would be going against our nature and when you start going down the path of "minimal effort required" you loose pride in work and the drive for continuous improvement.

That being said, there are practical things you have to take into consideration but never do anything you would be ashamed to show someone else.

Do you want to be returning to your old projects to fix bugs all the time rather than working on your current project?

Do you want developers of the future to rewrite your code rather than fix a bug?

Most managers see over time who the good developers are. Those developers tend to get the more visible project and often the more interesting ones as well. Career advancement tends to be more about professional development than actual work done. If you want career advancement get certs, go to business classes, look for opportunities to get involved with projects outside your normal scope. When you do your job you get rewarded with a paycheck. When you beyond then you start seeing advancement.

As a software engineer working on shipping product, you have several contributions to the company:

Make the company more money than you cost them this year.

Make the company more money than you cost them next year.

Writing code fast is how you achieve the first; writing code maintainably is how you achieve the second. You and your business representative (manager other individual representing the business interests) must collaborate to prioritize what gets done.

My experience is that code never dies, and writing well-commented and modular code pays off in time very quickly.

It's the merchants who are payed off better. The most important thing is to get work done. The user doesn't care for technical details that do not affect their user experience.

When writing code, it's sometimes that artist is better than craftsman. Craftsman just do his work as it is described in books while artists just sits down and invents the solution to the problem.

Note also that doing thing 'as it should be done' you usually write code that requires higher technical skills to maintain. When the company is based on the 'cheap labour force' writing good code by good (and therefore expensive) programmer, that requires something more than basics to understand, isn't the optimal solution.

I'm going to assume the developer is capable of writing good code and therefore has a choice between writing maintainable code and not.

Are you on a tight deadline?

Yes - just get it done. You don't want to be the one who delays launch.

If no: are you a selfish or self centred person?

No - write good code, it is good for everyone who comes into contact with it.

If yes: are you in a situation where code review occurs?

Yes - then write maintainable code, otherwise what your peers and boss see of your work is that it is poor quality.

No - it's up to you, but the quicker you get to a solution the more time you have to do other things.

If No then are you in a situation where you will be the one maintaining the code that you write?

Yes - write poor code. Then you get the chance to fix it and look like a hero. People will be happy because you keep making their lives easier over a period of time. If you do it all at once then they might forget you. This will increase your chances of bonuses and promotion.

If No then will you be working with the maintainers, or in the same dept.?

Yes - probably best to write good code, as they will become a source of praise for your work, or at worst silence.

No - Write your code and move on. It doesn't matter how bad it is, someone else can fix it.