What would it be like if you were not a picture person?
I know I am in a minority, but I am not a picture person. I like words. I like numbers. I can cope with simple graphs or formal diagrams. But my mind does not work in pictures.
Most people are picture people, and work best with pictures and diagrams. I respect their preference; but, in the same way, I expect some respect for my preference. So this week, let me share with you what it is like to not be a picture person.
In my work as an IT-consultant-cum-software-developer-cum-business-owner, I get involved in a fair number of meetings and proposals for prospective customers. Typically I consider my contributions by writing them down.
As soon as I share my ideas with my colleagues and partner organisations, inevitably somebody declares "I am picture person", or suggests "Let's do some slides". My heart sinks.
Because I am not a picture person, not only do I not understand other people's pictures, I am incapable of explaining myself in pictures. Whatever I do is wrong. I try to recast my ideas as pictures, and I just get blank looks. I can not get the main ideas across, let alone the nuances that make our offer unique and compelling.
I am mystified by aesthetics. "The colours are a bit muted, it needs some more sparkle, can you love it up." I have absolutely no idea what people are talking about.
Because I have no empathy with the finished product, PowerPoint is, to me, an impenetrable work of Satan. I can do bulleted lists and simple boxes of colour, but anything more than that takes me hours and looks rubbish. I have to rely on the helpfulness of my colleagues to get anything presentable.
In my graphically-challenged mind, I am constantly suspicious of diagrams. Let me give a couple of examples.
My first suspicion is that pictures imply attention deficit. A lot of people like pictures because they find them easy to understand. The books I read to my children have pictures to keep them interested and to help them follow the plot, but something like a software purchase or service engagement needs more attention than a children's story. If I receive pictures, is it because the sender thinks I am stupid, or because they have not got any details?
My second suspicion is ambiguity. I greatly admire a chap we work with who has fantastic diagrams which he "talks around" as part of the sales process. His pictures are a series of topics and suggestions which he can weave into the story that the customer wants to hear. It's a great sales tool, but it works because it is ambiguous. It is very dangerous when the diagrams turn up later as somehow representing an agreement.
So, if you are a picture person, remember that not everyone thinks like you. Some people struggle to communicate in pictures. They will be incapable of expressing themselves to you, and will misunderstand and be suspicious of anything you give them. A picture may be worth one thousand words, but some of us still prefer the words.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 25 May 2010
Tuesday, 18 May 2010
Vote Minimal, again!
The time is right to adopt a less assertive, more down-to-earth approach to IT.
I must have been writing these newsletters for a long time because, when I looked back through them, I noticed I had written about the previous UK general election in 2005.
Back in 2005, the UK general election was extremely boring. The two main parties had similar manifestos. There was strong support for the ruling party and little hope of the opposition winning.
The 2010 election was very different. There was a real chance of changing the government. Voting was up, so much so that there were almost riots because some polling stations closed before everyone had a chance to vote.
The aftermath of the election has been fascinating. The parties were left with a near-impossible situation, and ended up with a coalition government the like of which has not been seen in generations. Nobody knows how the government will fare, with commentators split between optimists who say that it heralds a new age of politics and naysayers who say it will crash and burn in a few months.
What has this got to do with IT?
Our approach to IT is as much political as it is technical and commercial. Just like politics, circumstances and fashions change in IT.
Five years ago, the overwhelming majority thought that IT should take an assertive role, driving business change by implementing major new systems and getting rid of all the old systems. "IT is good, more IT is better" was the mantra. There was little dissent from this, and I saw Minimal IT as a small contribution to keeping the debate open.
Now everything has changed. Few organisations have the funds or appetite for the major implementations of a few years ago. I have not measured it, but I sense there is a greater openness to different views about IT, especially those that can help organisations weather the current and future financial storms.
Given this changing landscape, there is value in restating the principles that I started with years ago. We need less assertive IT, that focusses on the mundane work of supporting business operations, and is not obsessed with trying to drive business change by imposing new IT solutions. We need to educate our colleagues to reduce demands on IT to those which deliver real value, and avoid expensive, politically-motivated projects. We should constrain IT solutions to work within existing organisational structures, rather than try to use IT to cut across organisational responsibilities. We need to focus much more on the good management of the IT that we already have. We need simple, management-focussed models of IT, rather than complicated enterprise architectures. We need to stress outcomes, rather than obsessing about processes. We need to think about the systems we deliver much more than the projects that we use to deliver them.
I may be a ranting ideologist, but I am unrepentant. Now, more than ever, alternative viewpoints are valuable. Even though they seem eccentric, they are a fertile source of new ideas, which can help the mainstream more effectively navigate the problems and opportunities ahead.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
I must have been writing these newsletters for a long time because, when I looked back through them, I noticed I had written about the previous UK general election in 2005.
Back in 2005, the UK general election was extremely boring. The two main parties had similar manifestos. There was strong support for the ruling party and little hope of the opposition winning.
The 2010 election was very different. There was a real chance of changing the government. Voting was up, so much so that there were almost riots because some polling stations closed before everyone had a chance to vote.
The aftermath of the election has been fascinating. The parties were left with a near-impossible situation, and ended up with a coalition government the like of which has not been seen in generations. Nobody knows how the government will fare, with commentators split between optimists who say that it heralds a new age of politics and naysayers who say it will crash and burn in a few months.
What has this got to do with IT?
Our approach to IT is as much political as it is technical and commercial. Just like politics, circumstances and fashions change in IT.
Five years ago, the overwhelming majority thought that IT should take an assertive role, driving business change by implementing major new systems and getting rid of all the old systems. "IT is good, more IT is better" was the mantra. There was little dissent from this, and I saw Minimal IT as a small contribution to keeping the debate open.
Now everything has changed. Few organisations have the funds or appetite for the major implementations of a few years ago. I have not measured it, but I sense there is a greater openness to different views about IT, especially those that can help organisations weather the current and future financial storms.
Given this changing landscape, there is value in restating the principles that I started with years ago. We need less assertive IT, that focusses on the mundane work of supporting business operations, and is not obsessed with trying to drive business change by imposing new IT solutions. We need to educate our colleagues to reduce demands on IT to those which deliver real value, and avoid expensive, politically-motivated projects. We should constrain IT solutions to work within existing organisational structures, rather than try to use IT to cut across organisational responsibilities. We need to focus much more on the good management of the IT that we already have. We need simple, management-focussed models of IT, rather than complicated enterprise architectures. We need to stress outcomes, rather than obsessing about processes. We need to think about the systems we deliver much more than the projects that we use to deliver them.
I may be a ranting ideologist, but I am unrepentant. Now, more than ever, alternative viewpoints are valuable. Even though they seem eccentric, they are a fertile source of new ideas, which can help the mainstream more effectively navigate the problems and opportunities ahead.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 11 May 2010
Business value and maintenance
Although much of the code in a typical IT system adds little business value, there is a huge value in keeping it well maintained.
I don't know exactly how you could measure it, but I reckon that if you examined a typical IT system you would find that more than 90% of the value comes from less than 10% of the code.
The 10% is the code that directly stores, transforms or communicates valuable business information. The 10% is the reason you run the system. Everything that is unique about your business or your product is in the 10%.
The 90% is the code that supports the 10%. It is all the admin and infrastructural stuff, like user management, security, screen handling, housekeeping and interfaces. The 90% is the same in every other system, and adds no particular value to your business or your product. You would not bother with the 90%, other than that it supports the 10%.
This split explains why application frameworks are valuable. They provide the 90% out of the box, leaving you to focus your energies on the 10%.
The split shows you where you should focus when you are defining, piloting or demonstrating software. A colleague or customer is not going to be impressed with your slick user password change screen; they want to see what it valuable and unique about the solution.
The split also helps understand long-term management priorities.
You might think that because the 90% is of little value, you can get away with quick and dirty solutions, leaving your best work for the 10%.
However, you could argue the opposite. The 90% is relatively stable. Although it adds little value when it works right, it undermines all the value when it does not work. You want it to "just work" to support the rest. It needs good documentation, good test packs, and good disciplines, but it is relatively easy to achieve this because the code is stable.
The 10% is likely to be changed and modified more, as you explore more valuable and unique ways to support your business or your customers. It is less stable, and a constant focus of work. You do need good documentation, testing and disciplines, but you also need to explore new functionality, try new things, and maybe take some risks.
The 90% has a huge impact on the return on investment for the system. If you keep the 90% in good order, then you can redevelop the 10% without having to rewrite the whole thing. However, if the 90% is badly maintained, it will not let you make major modifications to the 10%. If the 90% is very bad, it may even force a complete rewrite, even if the 10% of valuable code does not need it. Your supporting code should aid the longevity of the valuable code, not undermine it.
For all these reasons, do not ignore the supporting code in your IT systems. It needs to be managed well so that it does not get in the way, leaving you to devote your energies to the more valuable and dynamic code that adds unique value to your business.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
I don't know exactly how you could measure it, but I reckon that if you examined a typical IT system you would find that more than 90% of the value comes from less than 10% of the code.
The 10% is the code that directly stores, transforms or communicates valuable business information. The 10% is the reason you run the system. Everything that is unique about your business or your product is in the 10%.
The 90% is the code that supports the 10%. It is all the admin and infrastructural stuff, like user management, security, screen handling, housekeeping and interfaces. The 90% is the same in every other system, and adds no particular value to your business or your product. You would not bother with the 90%, other than that it supports the 10%.
This split explains why application frameworks are valuable. They provide the 90% out of the box, leaving you to focus your energies on the 10%.
The split shows you where you should focus when you are defining, piloting or demonstrating software. A colleague or customer is not going to be impressed with your slick user password change screen; they want to see what it valuable and unique about the solution.
The split also helps understand long-term management priorities.
You might think that because the 90% is of little value, you can get away with quick and dirty solutions, leaving your best work for the 10%.
However, you could argue the opposite. The 90% is relatively stable. Although it adds little value when it works right, it undermines all the value when it does not work. You want it to "just work" to support the rest. It needs good documentation, good test packs, and good disciplines, but it is relatively easy to achieve this because the code is stable.
The 10% is likely to be changed and modified more, as you explore more valuable and unique ways to support your business or your customers. It is less stable, and a constant focus of work. You do need good documentation, testing and disciplines, but you also need to explore new functionality, try new things, and maybe take some risks.
The 90% has a huge impact on the return on investment for the system. If you keep the 90% in good order, then you can redevelop the 10% without having to rewrite the whole thing. However, if the 90% is badly maintained, it will not let you make major modifications to the 10%. If the 90% is very bad, it may even force a complete rewrite, even if the 10% of valuable code does not need it. Your supporting code should aid the longevity of the valuable code, not undermine it.
For all these reasons, do not ignore the supporting code in your IT systems. It needs to be managed well so that it does not get in the way, leaving you to devote your energies to the more valuable and dynamic code that adds unique value to your business.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 4 May 2010
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 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.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
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.
- Design approach 1
This is a highly interactive system, which requires a sophisticated user interface. It should be designed with a rich GUI, using libraries of standard GUI components to ensure a consistent look and feel. The majority of the design will involve a richly interactive environments such as Flash or Ajax, using calls to the back end to manage data persistence.
- Design approach 2
This system holds data on the server in complicated data structures. The integrity of the data is paramount, and must be managed within well-controlled back-end services. To deliver over the web, the most effective user interface will be pseudoconversational, in which a stateless client receives whole pages from the server. The majority of the design will involve the back-end database and services. The user interface can be built using relatively simple server-based scripting such as ASP or JSP.
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.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Subscribe to:
Posts (Atom)