Anyone who knows me will tell you how much I love this quote:
For any question, there is an infinite number of wrong answers and very few right answers. – Robert Baldyga
Of course, you could argue that a true/false question only has one right and one wrong answer. Unless your answer was “cabbage” or “tightrope”. Those are wrong. Infinity.
Also, there are some un-answerable questions: “What is the sound of one hand clapping?” Or my favorite: “what is faster, a bullet?” Heh. That one always cracks me up because it is not a complete sentence. You have no hope of giving a correct answer and probably there is no correct answer. Heh heh!
Software development is the world of infinite wrong answers. This is especially obvious when somebody asks you to make something interesting, without enough information. If the person is very flexible and accommodating, they might accept a wide range of answers with varying degrees of correctness. On the other hand, if the person is a real buggar, then you might never be able to satisfy them, no matter what magic you are able to deliver.
The only projects that I have seen fail, outright, were the ones who 1) had difficulty gathering requirements and 2) the owners (the ones who determine if it is right/done or wrong/not-done) were unusually picky. I mean, let’s face it, if you ask me to make a polly-wally-doodle (without any further explanation), then you are obligated to accept whatever I deliver. From there, you can ask for revisions. Do not simply look at the results and say “Nope. Wrong again. Keep trying” without any better instructions. That won’t work.
Let me be clear about something: I am not the type of person to give up on a problem. My relentless pursuit of a solution has served me well in my career as a programmer and system architect. However sometimes, a person can find himself in a check-mate situation and there are no more successful moves. In such a situation, your options will be very limited.
If you ever find yourself in a project where the prospect of success has gone out-of-the-window, and yet you refuse to give-up, here are some things to try. These could actually improve your situation:
- Lower the expectations You know you won’t get it right the first time (or the second or maybe even the seventieth). Start with getting something done and then begin plotting a moderate course towards “more correct”. You might never get to correct/perfect, but each time you get closer, you are, um, well, closer.
- Reduce the dev time If everything you deliver is going to be wrong, then DO NOT make it perfect each time. A classic technique for developing (under these conditions), is known as prototyping. Make a straw-man (a fake program with little or no code behind it). Revising it, will take fractions of the dev time and will get you some progress more quickly.
- Split your requirements/scope (sort-of like a follow-up to lowering expectations) Commit to completing most of the features. Focus on the ones that are most achievable. Then when it isn’t perfect, you can say “Ah, but a portion of it is correct. Let’s ship the parts that work. Hashtag-Win!”
- Focus on the root cause of your problem (without resorting to finger-pointing) If your designs are wrong or your data is complicated or the business rules change frequently, then address that specific problem head-on and focus on it. Doing so, might require that you change your entire dev process or methodology or whatever. Until you pin-down the cause, it will be difficult to identify a remedy.
- Change up Once you have identified your cause(s), then change your process (maybe just part of it) to directly deal with that problem. The problem might be temporary, so be ready to change again, once the problem is refined out of your way. Repeat as necessary.
- Punt/de-scope the problem Sometimes, it is not possible to solve one or more particular problems in a reasonable amount of time. Don’t let those things sink the whole project. If you have an impassable barrier, your best move might be to cut it out of the scope of your current project and complete everything else. Of course, the biggest culprits are usually the crown-jewels of your project. So this approach might create a real stir or meet with strong resistance. Still, I have found that when you push to drop the core feature of a project, sometimes people get serious and reconsider your offers to compromise. You would be surprised how reasonable people can become when they truly believe that their favorite feature will get cut.
In the end, if you don’t have good requirements, then your results will not be correct. If you have no other choice, you can make that the plan (i.e. plan on incorrectness), then it becomes much easier to implement the plan and complete the project. It may sound stupid but it is accurate, honest and much better than throwing your hands in the air and ending with “I don’t know”. Yes, you actually do know. So just say it.
If it is not possible to be right, then prepare to be wrong for a while and focus on becoming a better kind of wrong (also known as “getting a red win”). Just don’t make a habit out of something like that.