The "If Onlies" Of App Dev

Img_0101 Do you, as an application development professional, often find yourself starting your sentences with the phrase “if only”? I hear this phrase an awful lot from Forrester clients.

The Situation

Imagine that you didn’t have a driver’s license and you had to travel to another city for work within a day. The conversation you had with your manager might go something like this: Mclovindrivers_4

You: I can’t drive. I don’t know how, and I don’t have a license.
Your Manager: Maybe you should take the train.

Imagine if instead the conversation went like this:

You: I can’t drive. I don’t know how, and I don’t have a license.
Your Manager: Too bad. Drive anyway. And if you get a ticket or get into a crash, you’ll have to cover it yourself.

That would be ridiculous, right? But that's actually how things work in enterprise app dev organizations. For example, take the following all-too-common conversation:

You: The requirements are still changing.
Your Manager:
Too bad. Proceed to design anyway. And by the way, if the project fails you’re responsible anyway.

(That last bit is always implicit: No one ever says it, but you know it's true all the same!)

The Analysis

There are some challenges in application development that are so constant that we probably ought to work around them rather than trying to ram our way through them. I call these the “if onlies” of application development.

Here are some examples of “if onlies” of app dev:

  • If only requirements were complete
  • If only there were enough time to test at the end of the life cycle
  • If only everyone followed the process
  • If only development efforts were predictable
  • If only metrics were comparable across projects
  • If only our tools worked together
  • If only we weren’t constrained by legacy
  • If only we could reuse our prior work
  • If only software were easier to evolve

The "So What"

So here is my question for you. What if these things, these “if onlies,” are impossible? What if were a bad idea to assume that you could drive from point A to point B? Isn’t it a better idea to recognize that and find another means of transport than to keep trying to figure out how you can drive tomorrow?

Thehomercar_top_5 What are the “other means of transport” in this case? These are ways to be successful even if this “if only” is actually true.

These are game-changing tactics. Examples might include:

  • Service-oriented architecture
  • Agile processes

What are your "if onlies"? What are the perennial problems that you feel might make more sense to accept and work around rather than continue banging your head against?

-- Carey Schwaber

Comments

re: The "If Onlies" Of App Dev

The 'if onlies' are so real. Most of us have faced them throughout our careers, in different roles, organization and team cultures, delivery paradigms, ... You captured them well. There is no doubt that agile processes and SOA are part of the 'transport' mechanism or game-changing tactics (BTW: I love that phrase) -- but I find that people even struggle to understand what 'agile' means and how best to implement it.

re: The "If Onlies" Of App Dev

Re. incomplete requirements - it seems pretty inexcusable that most organizations can't apply more order to this part of the process. If you don't know what you're trying to build, how can you possibly build something quality or adhere to deadline? Agile process / methodologies notwithstanding, a lot of developers find themselves picking up product manager slack and asking the "who is this for?" and "what problem does it solve" feature definition questions.