Reaction versus anticipation
It is not enough to react quickly to meet your customers feedback as a software engineer, if you truely want to be an excellent engineer you need to anticipate their needs (to an extent). This does not mean creating applications that are so generic that they can meet any user need: as such systems usually suffer from feature overkill, take too long to develop and are overly complicated to use or maintain.
Anticipation takes many forms and covers many areas of software development:
- Anticipating Questions:
- Have you described your software in terms the customer can understand?
- Do they still want the software now they understand what you are proposing?
- Have you been precise with your description? Vague descriptions can lead to confusion and user disinterest or down right resistance to your software (if they think it is something it is not).
- Do you have design documentation you can show the customer?
- Is your design documentation actually understandable (by the user) and is it user focused e.g. work flows, user interfaces etc? High quality, readable and concise design documents are an excellent way of allowing the customer to soak in the design in their own time.
- Anticipating deployment:
- How is the user going to run your software?
- Have you test run your software on the customer’s platform with a similar environment configuration before you attempt to roll it out?
- What other dependencies will need to be installed to support your software?
- How do you plan to push out those dependencies?
- What sort of configuration management (CM) system is your customer using and can you harness it?
- How will you install and configure your software?
- Anticipating integration:
- How will your software integrate with the customers current work flow and application stack?
- Does your software have dependencies are shared with other applications that could require those other applications to be upgraded too? What extra cost would this introduce?
- Does your application have specific operating system configuration requirements that could cause side effects for other application?
- Anticipating support:
- How will you support your software post roll out?
- How will diagnose problems on customers computers when you don’t have your development environment available?
- Have you built any logging, metrics or error reporting tools built into your software?
- Is there a help system integrated into the software and is that help system’s content usable and understandable by the target users?
- How do you intend to upgrade your software or its dependencies in the future?
- What sort of testing do you have in place to prevent upgrades breaking existing functionality?
- Anticipating retirement:
- How easy would it be to remove your software from the customers application stack?
- Do you have some sort of uninstallation script?
- What about your applications dependencies: will any dependencies be orphaned and how will you remove them?
- How tightly coupled is your software to the other systems it interacts with? Can it be easily and gracefully decoupled?
You don’t need to answer all of the above questions but spending some time thinking about them and jotting down even single senence answer will help you anticipate potential problems. It is never fun to have to tell a customer “I hadn’t thought about that.” after some show stopping problem emerges…