136

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?

Community
  • 1
murungu
  • 389
  • 1
  • 4
  • 6
  • 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. –  Jun 07 '11 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 07 '11 at 13:01
  • 3
    Craftsmanship keeps me from having to buy shame curtains. – dietbuddha Jun 07 '11 at 15:39
  • (+1) For mentiong "craftmanship", instead of "Software Factory", because real world software development, behaves more like a workshop than a factory, even that many non technical managers, don't think so... – umlcat Jun 07 '11 at 18:16
  • 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 07 '11 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 08 '11 at 02:12
  • 1
    Write reliable, compact, easily readable and stable code. Don't add features, languages and patterns only to shine, and because you've read about them in academic literature or marketing materials. – Coder Jun 08 '11 at 12:04
  • I wrote http://coteyr.net/articles/57-Clean-Code-and-Metrics because of this article. It's my own site, and my own ideas but it's true. The basic is that aiming for 100% is silly, but achieving 90% is totally worth it. The real mistake with code cleaning is trying to get metrics to 100% but the ideals behind those metrics are totally worth doing. Measure ROI, do it right from the start, and it should be "easy". Doing it wrong makes things hard. You *should* be more productive with clean code then with dirty code, unless your aiming for 100% clean. Balance is the key. – coteyr Jun 15 '15 at 01:51
  • Re, "my dilemma remains" And it always _will_ remain so long as there's bills to be paid. Craftsmanship usually pays off in the long run, but sometimes you (or your employer) can't (or won't) afford to wait that long. – Solomon Slow Aug 27 '16 at 19:43

16 Answers16

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.

Wayne Molina
  • 15,644
  • 10
  • 56
  • 87
  • 20
    +! for "Whole team" – Sean McMillan Jun 07 '11 at 15:58
  • 2
    "I've lost many jobs due to my wanting to push a culture of craftsmanship over sloppy hacks..". If you were aggressive about it, then IMHO, it was the right decision. You should NEVER start adding patterns, new technologies or heavy OOP for working system in an aggressive way. You don't know the system, others don't know your style, the whole software turns into mess of different patterns and anti-patterns, and in a big ball of mud. If you want to push new things, do that during planning stages of new projects. Once the codebase is alive, you should not apply huge changes to it. – Coder Jun 08 '11 at 11:47
  • 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 08 '11 at 12:06
  • Solid codebase is well tested, the team has a good understanding on how it works, and it doesn't leak. Even if it's not written against patterns by the book, it's easily maintainable by people who work with it. You can add smart pointers, RAII, you can clean some structs and classes here and there, but adding new dependencies, or architectures is not what should be considered easily. Sometimes design decisions during the initial development have forced a bad approach. But changing wheels of the car to tracks while on highway is very risky. – Coder Jun 08 '11 at 12:27
  • The only way I would accept architectural change is either during project planning or early protototyping stage. Or if the architectural shift can be done on the whole existing product at once, and cleanly, which is never the case. A colleague of mine, coming from a Java background, forced some architectural novities in one of the codebases which I warily accepted. The whole thing added more headaches than necessary. Part of the code base that differs in conventions, it had to go through extensive debugging, and even now it still leaks, although most defects are fixed. – Coder Jun 08 '11 at 12:33
  • Also, it was the minor change that I accepted. I didn't agreed with the idea to change the core architectural parts of the codebase. That would have been a year long project at minimum. – Coder Jun 08 '11 at 12:37
  • 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 08 '11 at 12:47
  • Yes, that is correct. Good framework, pattern or general architecture is the best thing you can for the whole project if you get it right at the design phase. Although sometimes patterns are newer than the project, or changing business decisions can cause incompatibilities during product cycles anyway. And then, few years later, you're stuck with suboptimal design anyway. – Coder Jun 08 '11 at 12:59
  • 1
    +1 "They don't have to risk getting fired because you keep trying to educate your team about new and better ways of doing things..." – Amy Patterson Jun 08 '11 at 18:08
  • 1
    same here, well mostly !!... Dream of the day where SOLID no longer refer to assessing one's [regularity](http://www.all-bran.com). This said I have a friend that works in the gaming industry where there was a culture of shortcuts and quick fixes, yet, slowly his ideas come into code, code come into systems, systems are integrated in a larger system and now, after a few years of trying to preach good practices he is now in a position where he can demonstrate the direct effects of such practices. they are starting to notice and take note, this gives me hope ! – Newtopian Jun 08 '11 at 19:01
  • @Newtopian I think that can give all of us hope, if we can put up with the bad stuff for long enough to (hopefully!) get into a position where we **can** demonstrate the benefits. – Wayne Molina Jun 08 '11 at 19:21
  • If you are in a startup trying to launch a new product fast (and survive), you have to build things fast. This speed is often touted as the enemy of quality. But it's only true if you have people who don't appreciate good code. If your team members are people who strongly understand these practices, know exactly how much technical debt to incur and make the right tradeoffs, then you have a chance of building a stable, 'good' codebase even while trying to ship fast. If they are not, you cannot teach them and launch a startup at the same time. Sad, but true. – talonx Jun 09 '11 at 05:41
  • 1
    Exactly. I find it's worse in existing companies because they think so short-term they're loathe to even be aware of technical debt until they have so much they go "technically bankrupt", as it were. In my six years in IT I've worked at exactly **one** company that was aware of this; every other place has ignored or even dismissed craftsmanship as wastes of time (hence my being terminated due to wanting to make it more visible). – Wayne Molina Jun 09 '11 at 12:09
  • 3
    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 Molina Jun 09 '11 at 12:18
  • 32
    Has anyone else slipped into mild depression after reading this and realizing it applies to them? – Mike Weller Feb 09 '12 at 12:51
  • @Mike Weller I have, of course :) – Wayne Molina Feb 09 '12 at 15:04
  • 1
    Ironically a year later and I *just* got let go from my job due to constantly pushing us to have an architecture and standards! – Wayne Molina Jul 21 '12 at 17:36
  • It sucks even more when you push for good practices and the whole company turns on every piece of code you have written saying that it has 3 classes. The funny thing is they also claim the follow craftsmanship !!! The fact is, there are far too many high level "This is good" concepts in the software industry. You are far too likely to violate one or more of them no matter what you follow. – arunmur Jun 06 '13 at 05:18
  • +1000000000000000 That's why I steered off towards database administration. – Tulains Córdova Jul 30 '13 at 12:53
  • 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 09 '13 at 15:10
  • 2
    @Wayne M => you deserve better. Perhaps its time to be more discerning in your choice of employer. Remember job interviews are not only for the employer's benefit, it's also your chance to size up the company and it's values. Choose an employer that speaks your language and embraces your values. – murungu Nov 16 '13 at 22:02
  • 3
    @murungu The issue is that often companies are able to portray that they do embrace the values, and then only reveal later that they don't. For instance the job I left last July was one such company - pretended they cared about things and really didn't. – Wayne Molina Nov 17 '13 at 17:58
  • Reading this I can't help but wonder at turn-around time... I've worked with a couple very smart who were all about good-practices, but I saw very little of use coming out of them. Really, if people were so resistant to "good ideas" I wouldn't wait for them to fire me -- I would quit. – emragins Mar 07 '14 at 19:46
  • In my case it was because I was constantly being fed the "give it a little bit and you can fix it" approach, including being told I was going to be made the AppDev Manager. – Wayne Molina Mar 07 '14 at 20:25
  • 2
    I waited until I was the senior developer and had the buy in from the Development Manager before changing our process. When I had the power to change it, I did (well, we are still evolving into better processes). I wouldn't force it on entrenched people with more seniority/power. – Miyamoto Akira Apr 09 '14 at 13:56
  • 2
    I have seen a lot of teams which choose to not follow best practices, because of some external pressure (as example super agressive deadlines).. However, most of the people with whom I worked over last 15 years would like to follow best practices. Sometimes it takes time to get it through. However, I don't remember even one case when somebody was fired for that. This kind of raises a question whether you are too aggressively trying to push your vision. – Victor Ronin Mar 27 '16 at 02:20
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.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • 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 07 '11 at 15:17
  • It depends on the duration of the project. For a long term project that will be entering a maintenance phase, this would have a huge impact on the bottom line. On the other hand, if the project was a short-term rapid prototyping (especially if it was a throwaway prototype), then no, this is of little value. – Thomas Owens Jun 07 '11 at 15:23
  • 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 07 '11 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 07 '11 at 16:58
  • @deterb That would be an interesting perspective. But I'm not entirely sure how I would explain "technical debt" to a manager. I can show him work by McConnell, Boehm, and others that relate practices now saving money later. I would be interested to see where that leads, though. – Thomas Owens Jun 07 '11 at 17:00
  • 2
    @Thomas Owens Take a look at http://www.codesqueeze.com/refinance-your-technical-debt-just-like-your-mortgage/, 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 07 '11 at 21:11
  • Thanks for that link. I'm going to bookmark it and read it when I get a chance. – Thomas Owens Jun 07 '11 at 21:12
  • @HedgeMage They are out there? Where? And how does one know before taking the job? (Probably 0 out of 3 of these questions are fair to ask...) – Andrew Jun 08 '11 at 20:16
  • @Andrew I never said they were *easy* to find. The only reliable ways I've found to identify them is 1) to get a look at some of their code and see how much cruft and kludge it is dragging around or 2) to get recruited to the company by a current employee you trust who vouches for their standards. Since I work mostly with open source tools, of course, 1) is way easier for me than for most people. – HedgeMage Jun 08 '11 at 23:35
  • Had a boss who used to say: "Good good, the worse the code the higher the maintenance costs ... that's good for us." After all, those people are not interested in good software but in profit. – Falcon Sep 09 '13 at 15:12
  • 1
    Link rot, unfortunately :-( – EBarr Mar 19 '14 at 22:04
  • Note that, minimizing maintenance costs means **nothing** if your *"Time To Market"* is to long and all your customers have already bought a competitor's crap-ware. – recursion.ninja May 10 '14 at 16:12
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.

  • 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 08 '11 at 19:06
  • @Newtopian: Time to change the industry then? –  Jun 08 '11 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 09 '11 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.

Dave
  • 869
  • 5
  • 7
  • 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 04 '15 at 09: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 '18 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.

mattnz
  • 21,315
  • 5
  • 54
  • 83
  • 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 08 '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. –  Jun 08 '11 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 08 '11 at 21:18
  • 4
    As someone else said somewhere "shipping is a feature". – TecBrat Apr 09 '14 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 '16 at 02:26
  • The flip side of this argument is simple. The code was unmaintainable. If you were (which you weren't) a big business that would someday release a 2.0 of the software, you would have had to start from scratch. Spending much more time and effort than "Overengineered" code. The best part of BP is recycling. Especially across many product lines. I work at a company with many software products. Using well documented JS libraries across different projects saves a ton of time, and money in turn. So, it may not help in your case, but often it really does. – EvSunWoodard Oct 07 '16 at 20:02
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.

jwenting
  • 9,783
  • 3
  • 28
  • 45
  • 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 07 '11 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 07 '11 at 11:37
  • @Thomas Owens. Those stats most probably don't include start-up projects and companies that didn't survive. – StuperUser Jun 07 '11 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 07 '11 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 08 '11 at 05: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.

Community
  • 1
Joel Etherton
  • 11,674
  • 6
  • 45
  • 55
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.

jhyot
  • 429
  • 3
  • 12
amol
  • 131
  • 3
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.

  • 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 07 '11 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 08 '11 at 21:11
  • @mattnz, code for non-Microsoft/Apple platforms tend to be usable for decades. –  Jun 08 '11 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.

SoylentGray
  • 3,043
  • 1
  • 23
  • 31
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.

Homde
  • 11,104
  • 3
  • 40
  • 68
  • "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 07 '11 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 07 '11 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 08 '11 at 00: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 08 '11 at 01: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 08 '11 at 03:02
  • Real craftsmen and tradesmen have to be formally educated in the craft and work for years as apprentices just to become a journeyman, i.e. licensed to practice independently. Becoming a master is *excruciatingly* difficult in regions that have the designation. Computer programming is *nothing* like this. It's one thing to play with goofy analogies at the water cooler, but it's being taken to a comical extreme here. Software is engineered, not crafted. The fact that most programmers have no engineering training only means that most software is engineered *poorly*. – Aaronaught Jun 08 '11 at 18:38
  • That probably differs between different peopple, I know and have experience working with both kinds of programmers I'm just saying that craftmanship is something we should strive for, IMO. It seems you have a lot of experience with programmers who dont', which is a shame. – Homde Jun 10 '11 at 07:08
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.

DanMan
  • 105
  • 6
Matt Ellen
  • 3,368
  • 4
  • 30
  • 37
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.

wildpeaks
  • 2,691
  • 1
  • 19
  • 17
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.
Jim G.
  • 8,006
  • 3
  • 35
  • 66
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.

Paul Nathan
  • 8,560
  • 1
  • 33
  • 41
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.

Danubian Sailor
  • 1
  • 9
  • 17