If you want this, then:<p>A. Let your engineers know they will never have to look or explain this code to anyone, and<p>B. Their job isn't on the line if it doesn't work.<p>The reason your engineers want clean, testable, fast code is because they know that the project manager won't be up until 3AM debugging the system because it's down and there's a giant pile of hastily written code and technical debt.<p>(I agree with what someone else said that developing and selling your own product really clarifies the importance of getting things out the door, but in those circumstances the pain of no customers is more than the pain of the 3AM debugging session.)
“There are two types of startups... those that are successful on a code base of which the engineers are moderately ashamed... and those that go out of business.”<p>-- Lean Startup 2012 Conference<p>Perfect is the enemy of good enough, and all that. Especially as a startup, there's no guarantee you're going to be in business in a few months, and time = money. I'm not saying you shouldn't have well-tested code, but you probably shouldn't spend weeks perfecting something when a good enough solution can be done in a day.
Good enough is a struggle... but the one thing that should never be pushed down the pipe is ensuring the code is understandable.<p>Once you get beyond the basic crud-webapp-twitter-clone the ability for a new person to simply pick up and start working becomes increasingly more difficult. This is a cost that you <i>will pay</i>. You'll pay for it when one of the three people that understand the system decide to quit or when you have to put new hires through eight months of training before they can write a single line of code.<p>I've worked with systems that were written by people that have decades of industry knowledge. Every class, method and comment is using their lexicon and entire chunks of the system rely on assumed knowledge. Suddenly ranked_pct(std_dev_norm(userid,norm,v,arr,false,get_data(userid))) is returning 0.24 when it used to return 0.51 and the BA/PM would like to know what changed. That's when you'll realize that your growth has been severely limited.
This idea might backfire as the non-technical issues can easily mind-boggle an engineer working on a deep and complex problems.<p>Leave the meetings and reporting to managers. Some of the best teams I have worked in have managers who buffer/cushion every trivial externalities from the rest of the team. This is crucial for the sanity of many developers.
I can only think that transparency to a group of intelligent people would be cause for success. If you hired these individuals to build your product, you must trust them to be smart people. If you can't trust them to understand your job by explaining it, you shouldn't be trusting them with coding.
Transparency is an honorable goal in and of itself; that said, most people do not want to make complex trade-offs, nor do they want to own the unpopular outcomes of those decisions.<p>You can expect most people to acknowledge the problem - briefly - and then return to complaining about your solutions.
Love this approach, and the same can be done for IT departments. It's the first step in making IT a strategic resource and not just a utility. Show technical teams the details of how their work supports the results on the sales team (and maybe support, etc.) If the manager or executive doesn't already understand the connection, then this will be an excellent exercise for them too.
When I started developing and selling my own product, my obsession on code quality definitely relaxed. First and foremost, it's now about the end product and not the code.<p>It's painful for an engineer to be told to do MORE with less time and less "quality", but the business cares about more than just code.