Even Simple Software Applications Can Be Complicated

If I asked you to write a simple software application to calculate loan payments and remaining balances over time, how would you approach it? Here are a few possibilities:

  1. Ask questions to clarify the requirements and document the answers before continuing.
  2. Write a formal requirements document and obtain sign off before continuing.
  3. Produce a user interface mockup or wireframe and use it as a way to clarify the requirements.
  4. Develop a software prototype and use it to finalize the requirements and the design.
  5. Locate a few existing loan payment applications and use them as examples to define detailed requirements.
  6. Write the application as you believe it needs to be done and deliver the final version.

How would you approach the problem?

None of these approaches is necessarily better or worse than any other — as long as the customer is happy with the end result. There are, of course, several complications. Did I mention…

  • …the software must handle balloon payment loans.
  • …the software must handle interest-only payments during the first few years of the loan.
  • …the software must export XLS or CSV files.

 Would these complications make you approach the solution differently?

#1 works well if you know what questions to ask. Do you?

#2 isn’t much better than #1.

#3 might work well … if … the mockup or wireframe is detailed enough.

#4 will ferret out the details though it may take several iterations.

#5 may help enormously … if … you can find existing applications that handle most of the issues.

#6 will only work if you are intimately familiar with the customer and the solution space.

I prefer approaches that are agile and offer multiple opportunities for customer feedback. Thus, #3 and #4 are most appealing to me. What would you do?

Updated: September 11, 2011 — 10:56 pm