137

Possible Duplicates:
Prototyping vs. Clean Code at the early stages
Frankly, do you prefer Cowboy coding?

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.

But my dilemma remains - does craftsmanship pay off?

Improve this question
9
  • 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.
    – Jon
    Jun 7, 2011 at 10:24
  • 20
    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
    – Daveo
    Jun 7, 2011 at 13:01
  • 3
    Craftsmanship keeps me from having to buy shame curtains.
    – snakehiss
    Jun 7, 2011 at 15:39
  • 9
    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.
    – sourcenouveau
    Jun 7, 2011 at 19:21
  • 5
    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.
    – Steven Evers
    Jun 8, 2011 at 2:12

16 Answers 16

Reset to default
80

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.

Improve this answer
26
  • 20
    +! for "Whole team"
    – Sean McMillan
    Jun 7, 2011 at 15:58
  • 6
    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 Molina
    Jun 8, 2011 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 Molina
    Jun 8, 2011 at 12:47
  • 33
    Has anyone else slipped into mild depression after reading this and realizing it applies to them?
    – Mike Weller
    Feb 9, 2012 at 12:51
  • 6
    Never had that experience. Quite the contrary. Maybe something is wrong with yourself or you just had bad luck in choosing companies. My craftsmanship is welcomed anywhere. Because my coding is both FAST and GOOD quality. But if I inherit a mess of an application that has been maintained to death already I just say fuck it and don't care about craftsmanship, but focus on other things like customer statisfaction etc. pp. Truth be told, I even had a boss who told me: "Good good, the worse the code, the higher the maintenance costs...that's good for us!" I didn't like him.
    – Falcon
    Sep 9, 2013 at 15:10
63

Here are some numbers to think about:

  • 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.

Improve this answer
12
  • 35
    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.
    – wolfgangsz
    Jun 7, 2011 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.
    – HedgeMage
    Jun 7, 2011 at 16:33
  • 1
    Another interesting perspective to take on this is that the technical debt introduced with poor code does take on interest - and putting that $ perspective in front of managers as a choice between a fast, high interest solution or taking your time and not even taking on debt.
    – deterb
    Jun 7, 2011 at 16:58
  • 2
    @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.
    – deterb
    Jun 7, 2011 at 21:11
  • 1
    Link rot, unfortunately :-(
    – EBarr
    Mar 19, 2014 at 22:04
30

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.

Improve this answer
3
  • I'd love that but in my field (medical) there is so many regulations, certifications, audits etc that before a single sale can be made millions have already been engulfed... just simply cannot afford it !
    – Newtopian
    Jun 8, 2011 at 19:06
  • @Newtopian: Time to change the industry then?
    – user8685
    Jun 8, 2011 at 20:26
  • yes always a possibility, but since i'm not very well versed in the political field to lobby for regulation change i' think it would be easier to just change field and conquer another one !
    – Newtopian
    Jun 9, 2011 at 13:57
29

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.

Improve this answer
2
  • 6
    +1 for the distinction between "just good enough" and "low quality". Over-engineering is a rookie mistake. The good (IMHO) senior devs tend to minimize the amount of code because the more you have, the more costly it is to refactor, especially if you don't get much help from your IDE. I would think that the word "craftsmanship" implies continuous refinement of code, stripping out all the over-engineering until it is just good enough.
    – Steve
    Sep 4, 2015 at 9:46
  • I totally agree with this. I've seen one too many java developers strapping design patterns all over and getting simple stuff that you can do with 10 lines to take 6 times that time and -especially most irritating- hard to understand for new hires
    – Alvaro
    Jul 10, 2018 at 23:16
28

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.

Improve this answer
6
  • 14
    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 Molina
    Jun 8, 2011 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.
    – user1249
    Jun 8, 2011 at 19:21
  • 8
    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.
    – mattnz
    Jun 8, 2011 at 21:18
  • 4
    As someone else said somewhere "shipping is a feature".
    – TecBrat
    Apr 9, 2014 at 17:53
  • 2
    I have a mixed feeling reading this comment. On one hand, the outcome was great, so it's hard to argue with it. The bottom line beat the hell our of any best practice. However, your experience is anecdotal and has a confirmation bias. We don't know how many companies incurred more and more cost to support a code written in war mode which drove them out of the business.
    – Victor Ronin
    Mar 27, 2016 at 2:26
14

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.

Improve this answer
5
  • 9
    +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, 2011 at 11:17
  • I don't know where you are getting the idea that many products never reach that stage. Over $70 billion is spent on maintenance in the US alone every year. The number of lines of source code being maintained is approaching 300 billion. That's a lot of projects in maintenance phases.
    – Thomas Owens ♦
    Jun 7, 2011 at 11:37
  • @Thomas Owens. Those stats most probably don't include start-up projects and companies that didn't survive.
    – StuperUser
    Jun 7, 2011 at 14:30
  • 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.
    – deterb
    Jun 7, 2011 at 16:54
  • @Thomas: that just goes to show how large the sector as a whole is. Most products never see the light of day however. Projects are abandoned, products are replaced rather than maintained, etc. etc. but the total installed base is so large that there's still room for a massive maintenance effort (just think of all the 20-30 year old mainframe systems still in operation today, many of which have large expensive teams dedicated to their maintenance).
    – jwenting
    Jun 8, 2011 at 5:29
11

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.

Improve this answer
9

Short answer -

In big organizations - high chance that it won't.

In smaller organizations or if you go solo (offering your craftsmanship as a product or service) - high chance it will.

Improve this answer
7

Craftsmanship do pay off, but not until much later.

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.

Improve this answer
3
  • 2
    Unsatisfactory indeed. And management tends to be willing to pay more for the people on projects that write sloppy code quickly than on those that maintain it.
    – Bernard Dy
    Jun 7, 2011 at 11:57
  • 1
    Craftsmanship do pay off, but not until much later. - its a massive assumption there is a later in this industry.
    – mattnz
    Jun 8, 2011 at 21:11
  • @mattnz, code for non-Microsoft/Apple platforms tend to be usable for decades.
    – user1249
    Jun 8, 2011 at 21:51
6

Do you feel great shame when a bug is found in your software?

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.

Improve this answer
5

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.

Improve this answer
7
  • "Would a expert carpenter ask himself whether he really needed to carefully sand every part of a piece of furniture he's making?" He would. You shouldn't do things just because its what we do.
    – João Portela
    Jun 7, 2011 at 15:33
  • This answer effectively highlights the fallacy of the awful "craftsmanship" analogy. For a painter or carpenter, the craftsmanship is the product. For a developer, the code is not the product, it is a set of instructions addressed to a machine specifying how to build the product. This level of indirection is a crucial and sobering distinction; nobody is ever going to see what you call craftsmanship except another developer. Unless you're talking about UIs, documentation, etc., but the question really seems to be focused on code.
    – Aaronaught
    Jun 7, 2011 at 21:13
  • the code might not be the "product" from the consumer view but that doesn't mean programming isn't a craft rather than engineering, code is an artifact with inherent beauty and properties like conceptual integrity. It's pretty clear that in most cases more programmers doesn't equal better and faster code but similarly to that 10 painters can't make a better painting. The engineering analogy is a fallacy and treating programmers like bricklayers is one of the reasons most projects fails.
    – Homde
    Jun 8, 2011 at 0:53
  • I have no idea what you're on about. An engineering design also has conceptual integrity. Software is engineering, with the notable difference of having a lower barrier to entry and a frightening amount of narcissism. Most people who talk like this have never had any experience or even exposure to engineering. I'm sure it's very emotionally appealing for many programmers to liken themselves to artistes, but face the facts, code ain't sexy and it ain't beautiful. Clean, maintainable, well-organized, even brilliant, it may be - but it is not art.
    – Aaronaught
    Jun 8, 2011 at 1:52
  • Whether code is "art" can certainly be discussed, but it is, IMO a craft. Coding is "artistic" in that it requires a higher degree of right-brain thinking. It always hard to draw good analogies but I'd say the difference is akin to that between the builder and an architect. An architect needs to take human values, esthetic's etc into consideration. A builder needs to follow a blueprint. Code can have an intrinsic "trueness" to it's design similarly to that of a statue or painting. Sorry if this all sounds a bit lofty, I certainly don't see myself as an artist but I'm no engineer either.
    – Homde
    Jun 8, 2011 at 3:02
1

Some companies live off sucking customers into years of maintenance, so it's in their interest to deliver fast 1.0 products that does barely the minimum and take a very long time to maintain it.

Furthemore, it's easier for this type of bloodsuckers to justify maintenance costs when things break at the first interaction different from the demo script than when everything works fine.

Perhaps that's the sort of companies you ended up into, hence the corporate culture doesn't encourage craftsmanship indeed.

Improve this answer
1

Does craftsmanship pay off??

Yes, but it doesn't pay off for everyone equally.

  • It pays off for the lead developer or development manager who assumes ultimate responsibility over the code base.
  • It pays off for the developer who must make changes to his/her narrow swath of the codebase.
  • It pays off for the business when development needs to make or change or churn out a bug fixes.
  • However, it does not pay off for the developer, manager, or business who has to meet an aggressive, unyielding deadline.

Two Comments:

  • As a developer, you should heavily favor the "craftsmanship" path because you will invariably be asked to modify and support your code.
  • When choosing your next job, try to determine if the work environment supports the "craftsmanship" path.
    • If it doesn't, then you should be compensated for the trouble that will invariably arise from hacky code.
Improve this answer
1

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.

Improve this answer
1

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.

Improve this answer
0

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.