Here is an interesting story. An European university has recently commissioned a new payment system for it’s laundry with the budget of $14m. In the new system, all the laundry machines in the University are networked. A student needs to create a ‘Laundry Account’, which is a one time process, upload money to his account, enter his username/pwd before using a laundry machine and the money will be debited as per usage. It has cool features where students can view the “online status” of the laundry machines, reserve the machines, view account details etc in a web based system. Looks cool.
However, the system was conceived, designed and implemented poorly. The problem included login failure, complicated processes and unproductive blockage of machines through online reservation system. Read the entire story here.
There is a lesson or two for every software person here. It goes to show that while conceiving, designing and developing a system, the technical team must always:
- a) Focus on requirements engineering
- b) Focus on design: Keep it simple
- c) Focus on review, inspection and testing
- d) Ponder on the Impact on end user/business
Ensure the requirements are clearly understood, documented and agreed upon from the end user perspective.
Rather than getting swayed by cool things, focus whether the design fully solves the business requirements and keep it simple and straight forward.
I can vouch that this system was not tested properly. I bet the various reviews – like requirements review, design review, code review – etc were never done or done superficially. The test coverage and review/inspection efficiency must have been awful for the system to be messed up like this.
Last but not least, every software engineer/manager should ponder the impact on the business and/or end users the system failure or system inadequacy will cause.
I wonder whether any one has done any business case/ROI before spending that damn $14m? Heard of overkill? I am sure this will figure in the top 10 list.