|Research, training, consultancy and software to reduce IT costs|
Once a mainframe programmer, always a mainframe programmer
If you gave different designers the same business requirements and the same technical constraints, what are the chances that they would come up with a similar design?
Partner organisations who work with Metrici Advisor are impressed with its flexibility and analysis capabilities, but suggest we need to do more work on the user interface.
I have been wondering why our software has this combination of strengths and weaknesses. Why did we design the software the way we did? Why does anyone design software in one way rather than another?
Consider two approaches to the design of a web-based system such as ours.
Approach 1 is the PC programmer's approach. It focuses on user interaction, at the expense of not fully understanding the back-end implications.
Approach 2 is the mainframe programmer's approach. It focuses on managing complicated data in a multi-user environment, and uses a method of interaction which works well technically with the web, at the expense of user interactivity.
Metrici Advisor follows design approach 2. I could make a spirited defence of why this is the better approach, but if I am honest, the real reasons for this is that my background was as a mainframe programmer. From the start of my career, my mind has been programmed in a particular way. Complicated data structures, multi-user systems and pseudoconversational programming are second nature, and so I designed the solution around what I know.
We could have built it another way, and we would have traded one set of benefits and problems for another set of benefits and problems. We are now improving the user interface; if we had started on the user interface, we would now be working on making the back end effective.
The IT solution you get will depends hugely on the background and experience of the individuals involved. Significant applications will require more experiences and skills than can be in one person's head. When building a team, consider where there are holes in their experience, and strengthen the team to ensure it has covers all the required areas. This will bring conflict, as different minds bring their preferences and experiences to the same problems, but it is better to resolve these conflicts during design than after the users get their hands on the system.Next: Business value and maintenance
Minimal IT: research, training, consultancy and software to reduce IT costs.