Unintentional “lies” in the software development field?

Beware the Chicken-a-saurus!

Marketing folks have learned a few things from software developers.

It is funny to me that developers often speak of marketing professionals as if they mainly lie to people about what they want to hear (or as if that were a moral thing).

I say that because it sometimes happens in our industry as well… maybe more often than we want to admit.

80% complete

I remember when I was just getting started in software… senior developers would report their tasks being 80% done… and remaining 80% done for weeks afterwards.

On better projects, they would report 80% complete on their first status report, and then 85%, 90%, etc.

And some of them couldn’t tell me what the “method of successive approximations” was. Go figure.

“Ready to ship” in 3 months

Or how about another example – that the software will be ready to ship in “N” months? In a recent MarketingProfs short, “How to Sift Through Unintentional Lies”, it cautions marketers to brace themselves for “one lie after another”.

It is worth reading, not so much to raise your hackles, but to learn about the perception we create in customers in whom we want to build an assessment of value. Though the article speaks about other domains than software, here is a fragment related to us, from their perspective:

No development team wants to miss a deadline—but it will happen. “There’s one project I’ve been watching that has literally been three months away from shipping for 18 months now,” notes Anthony. You’ll get more reliable estimates if you eschew a single, long development cycle for rapid cycles that produce a “minimal viable product” for testing and further augmentation.

[Bold emphasis mine. Again, please read the article at the source reference I included in the preceding lines.]

So there you have it… marketers asking for agile delivery of value. That’s pretty cool and a good place for us to work together on rebuilding trust.

Notice the article is careful to say the development team is not being malicious or intentionally deceitful.

I cannot remember a case where we have been, either. Most developers I know love to write software. We love to create and we love to solve puzzles… but let me highlight a third example before we close for the day.

Trusting each other

Now, there are explicit promises and implicit promises. In fact, it is the implicit promises that can do the most damage. You can try to disavow them easily or you may not even realize others think you made them in the first place.

In this case, DON'T read the manuals!

Have you ever made a promise to a teammate that you intended to keep, but failed in the end to keep? I know I have.

Did you ever “break the build” or overwrite someone else’s changes because of a merge conflict? I have done that, too.

Have you willingly taken on some task for a long time, and then just decided not to do it because it wasn’t really yours to do? Did anyone depend on it getting done, and did they know you stopped doing it?

Did you know you’d made a promise, or acknowledge the breakdown you produced? Not always, for me.

Do you think that failing to notice that you made a promise in the first place makes it any easier on the person you let down?

These are situations we create with our own teammates… and yet we sometimes try to diminish the importance of the cost we produce for others in failing to hold the promises we make.

Keeping promises requires professional attention

Many people write about agile methods being based on a notion of trust (including me). Quick releases, adaptive requirements, continuous integration, better testing and quick communication can go a long way to help us make and keep promises.

There are many levels in a project in which we make promises. They all count, especially in the eyes of those who accept our promises.

Keep the ones to your customers, but also keep the ones to your teammates.

Think about this – You may be committed to the top thing or two on your list, and everything else gets shifted around and de-prioritized. Though it makes you feel better to tell others you are over-committed, you may really be over-promising and failing to commit to the promises you make.

What hurts others also hurts your identity with them.

That which can’t be tested doesn’t exist… or must it?

That which can't be tested...

When I first read Martin Fowler’s Refactoring: Improving the Design of Existing Code, I stumbled on the phrase “That which can’t be tested doesn’t exist.”

In the years that followed, it has been something of a mantra to me, though I’ve found many things that made testing simply impractical.

What I want to do in this post is flip my earlier quote ON ITS HEAD!

Here’s a new category for ya!

In the category of not-really-a-corollary-but-it-makes-your-head-spin-to-think-of-it (dare me to add THAT to my blog categories!), Martin Weigel wrote in Restating The Wearingly Obvious, “You can’t test what doesn’t exist.”

That is flippin’ AWESOME! What he calls “wearingly obvious”, he describes in much more detail to be somewhat of a side effect of common sense thinking that we have ignored (in his case in the advertising industry) for over 30 years!

Here are a couple of key quotes and ideas from his writing that I see as relevant to the software industry:

  1. The idea that we can test “rough ideas” allows people to “abdicate their personal judgement and taste”, in other words, to “pass the buck” – what happens to the agile project without Metaphor or increasingly refined requirements?
  2. “Until you actually have finished work you are not testing creative solutions” – Hmm… sounds familiar (but not the same)?
  3. “Incomplete ideas evoke rough, incomplete responses from people” – even though he is writing about advertising, isn’t it important that what we test in agile is “true”, and that the reliability of our tests is related to some notion of completeness in the scenarios we anticipate?
  4. “Any research is therefore as authoritative and as fallible as the individual judgements and opinions of those involved in the [advertising] process.” Amen to that!

From Martin's post: did he identify an Archimedles?

Software development is creative work

And then he ends with a couple of really great sentences:

“There is no methodology in the world that can remove the element of uncertainty from the development of creative work. However much some might wish that to be the case.

“All creative decisions ultimately involve a leap of faith. And that requires more than simple courage. It requires people with taste and vision. People with the imagination and sensitivity to think ahead and be able to picture what has not yet been created.

“If you are unable to grasp these simple truths, if you slavishly believe rough responses to rough work to be The Truth, and treat them as directives for creative development, if you are uncomfortable with the notion of taking a leap of faith… then you are not one of those people. And you are very probably in fact, in the way.”

Wow! I hated quoting so much of his material here, but my challenge is that you look beyond the advertising domain he is writing about and think about the implications to software development.

So how does this trigger you? Let me know with a comment.