The “If Onlies” Of App Dev
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:
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?
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?