Red wine and its impact on project longevity

The fields of nutrition and software development share a lot of parallels.

Both are notoriously difficult to study: Each person, background, situation, confluence of behaviors and goals have an enormous influence on outcomes.

Reductionist extrapolations, and a rough abuse of correlation versus causation, yield meaty headlines that seldom hold up to scrutiny, the fertile soil laid for the likely “counter-intuitive” reversal some time later.

Simple carbohydrates. Test Driven Development. Private offices. Protein. Antioxidants. Fat. Standing desks. Work hours. Telecommuting. Open plan. Functional programming. Red wine. Omega 3s. Relational databases. Work-life balance. Years of experience. Waterfall. Cubicles. NoSQL. Running. Dependency injection. Cardio. Agile. Service-oriented. Generics. Saturated fats. Squats. Glucose.

Ceiling Lamp

The simple-carbohydrate rich Japanese diet clearly works for some mixes of genetics and lifestyles, while being seemingly devastating to others. Functional programming works for some programmers and classes of problems, while being detrimental for others.

Of course there are some things that are of obvious, certain merit.

Keep an ideal weight and stay fit. How you achieve those goals are where the advice gets much more iffy, often made with statements of absolute certainty, but founded on ever morphing and unclear findings of dubious merit. We live in nations of people absolutely obsessed with those goals, very few actually achieving them.

Build software that competently solves problems in an optimized timeframe with minimal defects. How you do that varies dramatically by the project, team members, motivations, and technologies. Many of the teams following whole regimes of seeming best practices with best intentions find themselves eclipsed and out of business by competitors doing none of that.

In both fields, people looking for an approach to provide salvation for their problems become really emotionally invested in the idea, because it simply has to be true. They’ve bound their hopes and goals around it.

The whole Atkins craze, for instance, saw people advocating a dietary approach with such zeal and passion it was irrational, replacing a fanatical rejection of fats that held previously. The idea, it seems, is the more people believe it is universally right, the more real it becomes, the more it will help them out in their own battles. Many have moved on to gluten-obsessed diets.

Test-driven development has similarities. Raucous internet battles over who is right, judging on approach rather than outcomes. Are you a believer, or a Believer?

Your customer doesn’t care. They don’t care how many tests you have. They don’t care how many epics you authored, or that you use Agile development or have loads of code comments or that you work at a standing desk.

They really don’t. If you’ve ever communicated it to them, you might be finding surrogates in the place of the actual outcomes, and that’s a very bad sign.

The person who talks about their goals a lot seldom reaches them, and talk has become a substitute for action1.

Does the software solve a problem? Is it good quality? Was it delivered in a timely and cost-effective timeframe? Is the team reactive to changes that are invariable in the real-world?

The only answers to those questions are yes or no. “No, but…” is simply no.

There are teams with loads of tests and lots of talk about code quality approaches, yet they produce abysmal, low-quality code.

There are teams with big talk about Agile who respond to change at a glacial pace, producing solutions in a slow, inefficient manner (which, as an aside, is one fascinating aspect of this industry. There are teams of armies of developers who deliver a couple of basic web apps in a year and celebrate their accomplishment, evangelizing their approach. Yet they exist in a little pond and have no comprehension or measure to see how their productivity actually measures against competitors).

Throwing in with something doesn’t grant you the desired outcomes by default.

Whatever approaches you choose to pursue should fit your team, the type of software you are building and within what timeframe, and to optimize productivity and minimize defects. And when someone does something using different inputs and thus different choices, compare on the outcomes and not on the approaches.

If one truly believes their propaganda — whether it’s the absolutely importance of generics, the incredible productivity improvements of F# over C#, or the enormous value of TDD — then implement it and eat everyone’s lunch.

Put those practices into play and rule the world.

1 – One of the side projects that I’ve never had the time to pursue, eventually just dropping the whole premise and domain (which was quickly snapped up by someone else), was tewdew. The idea was a social web app that allowed you to post and share goals. Those goals and status updates would remain hidden until your declared deadline, when all would be revealed, and you will have either succeeded, or failed.

The philosophy behind such a tool is that people undermine their own motivations when they reveal their goals early. If you talk about the great new diet and fitness regiment you’re starting, for instance, you’re essentially attempting to cash in on the results at the outset, diminishing the social rewards on success.