The Eternal Struggle Between Business and Programmers

I've always wondered why, in a company that loves 6 sigma and other process improvements, we never really got behind refactoring code. I mean, cleaning the flow of books and nuts through the line is praised, but the flow of an array through logic is not. I think it has to do with the former being easily seen - physical and the latter being abstract. It could also have to do with easily proving repeatability... It is easy to see that the bolts will be installed 500 time in a week; less so about the logic. In fact, I think if we could show measurable velocity improvements from refactored code; it would show business how investing in refactoring pays off. Kinds like a Toyota production system for c++.

As a mostly business guy, I kind this post said it best. It is about velocity and when to tractor/automate. It came across HN a couple weeks ago, but I'm not great at searching HN. http://blog.hut8labs.com/speeding-up-your-eng-org-part-i.htm...

This is a vague discussion that stays at a high level... I'm not sure how valuable this kind of generalization is.

The "programmer" side of this discussion certainly does not always have a grasp of the needs of the business in mind, and it doesn't help that estimations of effort for new features (or refactoring efforts, even minor ones) are notoriously difficult. Some programmers are business-savvy, but most really aren't -- not necessarily due to ignorance or inexperience! It takes significant effort & time to keep a finger on the pulse of a business, to really know how much this contract matters in the grand scheme, what's really required to land it, and when.

So it comes down to communication, and different people figuring out what actually needs to be communicated, but that's so relevant to everything it's almost useless to say.

Case studies would be more interesting -- real ones, inasmuch as that's possible without making real people look bad. The author seems to consult on this sort of thing for a living, so that's probably possible.

Thanks!

Part of the problem here is that developers don't do a good job of creating a culture that values refactoring as a key part of the overall process. The underlying issues are not, at a general level, unique to software. It's not like the business folks at GE aren't asking for more features faster. However, other engineering fields have done a much better job at making things like, e.g. testing, a core part of the culture. GE doesn't ship a refrigerator without incredibly extensive testing, not just because of the threat of lawsuits (another thing software developers don't really face), but because the relevant engineering bodies have made testing a non-negotiable part of the process.

From a manager's point of view, there's a big difference between having to say "our engineers would like some time for refactoring" and being able to say "refactoring is just part of the process--any other engineer would tell you the same thing."