Does craftsmanship pay off? [duplicate]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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.