I recently had the opportunity to visit a potential client to look at a
software development project that had been started by another developer
over a year ago. Just the fact that nothing was yet operational (nor
really functional to the potential user) was really a warning sign to me
as I looked at what existed. The entry screens looked like the forms
which the customer wanted to print — cluttered, and of course, far more
entry fields than would likely be used — very inefficient.
What I realized from the client was that what they had asked for was a
program to allow them to be able to print out certain required forms
with information filled in from a central database. No off-the-shelf
program was known to them which would allow them to accomplish that
task, so they decided on a custom application. The developer chose to
basically mimic the forms in a computer screen and the result was
completely unworkable. They also mentioned, as a kind of “by the way”
remark, that their really urgent need was for a program which would
allow them to create “log” entries of events which occurred throughout
the day from each of their locations, and then also to be able to print
or review the “log” as needed.
I share this with all as an example of “real life” communication with
users which requires “real world” interpretation of what is really
desired and required. Bottom line on this, what the user is asking for
may really be something other than they are expressing. In the case
above, the productivity gains for the “log” (a by-the-way comment) were
huge! The desire for “parts” of what would be contained in the
developed “central” database, while important to the longer term, were
minimally important for the short term.
Within 2 weeks of this preliminary meeting this client now had a
working, useable, productive application for their log, and were
beginning to build the “central” database required for the longer term.
Post a mark for another happly client!
Thinking back over my years as an application developer I’ve recently
realised that my methodology since I first began was basically the
principles of Agile development. Principles of “…early and continuous delivery of
valuable software”, welcoming changing requirements, and “simplicity” to
name only a few — each of these has contributed significantly to the
successes I’ve had. For me the root requirement of “Agile” is communication.
Over the course of the coming weeks and months I hope to present
interesting and useful thoughts – hopefully even some insights into the
challenges of creating “custom” application programs which serve the
needs of users in a most efficient manner.