Codes of conduct for IT professionals do not fully cover the conflicts inherent in IT.
In all trades, there is a commercial conflict between the consumer and the provider; the provider wants to make as much money as possible, and the consumer wants to pay as little as possible.
Where there is competition, this conflict is outweighed by commercial pressures, and, consumers generally get what they want at a reasonable price and providers generally make a profit.
Professional services are different because the service is more complicated and the client does not fully understand the service that they need. Clients have to trust professional providers. There is a conflict between the professional duty to provide only the services that the clients truly needs, and the professional need to make money. Most professions manage this to an extent through professional standards and professional bodies.
Some professions have special conflicts that are managed in special ways.
Healthcare is particularly expensive, and people need it most when they are least able to pay for it. There is a conflict between the professional duty to care for the sick, and the professional need to make money. Many authorities manage this conflict by providing healthcare through taxation (as in the UK) or through compulsory health insurance.
Lawyers and similar professionals have special conflicts if they are representing both sides in a dispute. Lawyers have to refuse work (and therefore money) where there would be a conflict of interest by representing both sides in a dispute.
IT, and particularly software, also has a special conflict.
Software does not rot, through generalisation software can deal with many different problems, software can potentially be reproduced without limit, and software can be combined and extended to create new solutions. The special conflict in IT is between the professional duty to provide a good enough solution at the lowest cost, and the professional need to make money through activity, uniqueness and change.
Mostly we ignore this conflict. IT sales aims to sell the customer as much as they can. Although there is competition, as a profession we have not evolved an ethic to exploit the reusable, general, unlimited and extensible potential of software. The open source movement is a step in this direction, but it is an alternative supply model rather than a set of industry principles.
There are attempts at ethical codes in IT, such as the very good Software Engineering Code of Ethics and Professional Practice. However, other than generally acting in the interests of the client and employer, this does not recognise the unique conflicts inherent with software. If you substitute the word "signage" for "software" throughout the document, it reads OK as a code of ethics and professional practice for sign writers.
I do not want to abandon the idea of making money, but I think there is massive potential for delivering better solutions for less if we can manage this conflict better, and we will hit both ethical and practical problems unless we do. We need to find a way of making money, while fully exploiting the reusable, generic, unlimited and extensible potential of software. I do not have a solution, but the first step is to recognise that the conflict exists.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 27 July 2010
Tuesday, 20 July 2010
An apology to project managers
It is easy to lose sight of the basic benefits of project management.
In these newsletters, I have often criticised IT projects and project management. Here are a few examples:
However, I think I have made a bit of a mistake and forgotten the basic value that project management brings. For that I owe an apology to project managers everywhere.
What has made me see sense is that we have recently taken on a new manager. Part of her role is to manage our development projects, which, being primarily a software company, is where we spend a good deal of our time and energy. Up until recently we have muddled through managing the projects ourselves, and the improvements of the last few weeks have been a very useful reminder of the basic benefits of project management. This is what we have found.
First, project management frees up the time of technical staff. I used to spend a large part of my time wondering what to do next, and losing time by swapping between tasks. Now I don't. I have someone to worry about that for me.
Second, although we are focussing more on the technical work, we are more confident that neither the big picture nor the little tasks are being forgotten. Both of these tend to get squeezed when you really focus on detailed work, but good project management can look after these without diluting focus.
Thirdly, project management keeps us on track (well, almost). We have an idea of what we need to deliver, when, and gentle but firm reminders to do so.
Lastly, project management helps us to manage the externals. As owners and representatives of the business, we have to keep in contact with partner organisations. However, when it comes to delivery, it is useful to delegate some of that contact to a project manager who can deal with it efficiently.
This may be an oversimplification of project management, but I think it is useful to remind ourselves that the basic benefit of project management is to bring organisation, focus and communication to the work. And to project managers everywhere, I apologise for missing that.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
In these newsletters, I have often criticised IT projects and project management. Here are a few examples:
- Are IT projects or IT systems more important?
- Projects are NOT investments
- Project manager required: heroes need not apply
- The culture of dishonesty
- The blame game
However, I think I have made a bit of a mistake and forgotten the basic value that project management brings. For that I owe an apology to project managers everywhere.
What has made me see sense is that we have recently taken on a new manager. Part of her role is to manage our development projects, which, being primarily a software company, is where we spend a good deal of our time and energy. Up until recently we have muddled through managing the projects ourselves, and the improvements of the last few weeks have been a very useful reminder of the basic benefits of project management. This is what we have found.
First, project management frees up the time of technical staff. I used to spend a large part of my time wondering what to do next, and losing time by swapping between tasks. Now I don't. I have someone to worry about that for me.
Second, although we are focussing more on the technical work, we are more confident that neither the big picture nor the little tasks are being forgotten. Both of these tend to get squeezed when you really focus on detailed work, but good project management can look after these without diluting focus.
Thirdly, project management keeps us on track (well, almost). We have an idea of what we need to deliver, when, and gentle but firm reminders to do so.
Lastly, project management helps us to manage the externals. As owners and representatives of the business, we have to keep in contact with partner organisations. However, when it comes to delivery, it is useful to delegate some of that contact to a project manager who can deal with it efficiently.
This may be an oversimplification of project management, but I think it is useful to remind ourselves that the basic benefit of project management is to bring organisation, focus and communication to the work. And to project managers everywhere, I apologise for missing that.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 13 July 2010
XML-based programming 7: is it for you?
Is XML-based programming suitable for your project?
Over the past few weeks I have described using XML during systems development and programming. It all started with using XML to pass data between different layers of the application, and has grown to use XML as a common format for all the ancillary parts of the system, such as configuration and testing.
When I started, I did not set out to create a whole new way of working. There are already lots if good frameworks to choose from, and it would be stupidclever to invent another one.
However, our use of XML has evolved to something significant and useful. It delivers very good separation between different layers of the system, and provides a flexible and consistent approach for many different aspects of development.
This has allowed us to merge together a complicated web application, some fairly hefty batch-style analysis, and a generic report production mechanism. It has allowed us to develop a single test approach which covers all of these, including low-level services, user interface, and reporting. It provides good facilities to load database data as XML, including the automatic resolution of foreign keys. It allows us to build higher level XML-based services from lower-level XML-based services.
There are some disadvantages. Some people are not comfortable with XML. Even though XML is good as a general-purpose format, it is rarely the best tool for any particular job. There are limits to what should be done in XML, especially for intensive use.
Overall the approach works well for us, and we do not intend to change it. We now have a significant investment in XML, and we have grown familiar with it.
But now I have two other questions. First, would I recommend this approach to others? Secondly, should we develop this further as a product in its own right?
I would definitely recommend the approach if you are familiar with XML, you have complicated integration inside the application, and you want a lot of control over how it is going to be put together, as in our merging of web application, batch processing and report production.
Conversely, the approach would be overkill for architecturally simpler applications that can be developed using one single set of technologies.
I do not know whether we should develop this further as a product. The XML capabilities have been developed independently from the application that use them, and could easily be applied to other projects. We would be happy to share them under some suitable open source license, if there was a demand for this.
So I am going throw this question over to you. Would the Java and XSLT tools we have developed for XML-based programming be something that you think could be useful in your work? If we provided them as open source products, is this something that you would use? Could you contribute to them to help their further development, or know of similar projects that they could contributed to?
If you are interested, contact me.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Over the past few weeks I have described using XML during systems development and programming. It all started with using XML to pass data between different layers of the application, and has grown to use XML as a common format for all the ancillary parts of the system, such as configuration and testing.
When I started, I did not set out to create a whole new way of working. There are already lots if good frameworks to choose from, and it would be stupidclever to invent another one.
However, our use of XML has evolved to something significant and useful. It delivers very good separation between different layers of the system, and provides a flexible and consistent approach for many different aspects of development.
This has allowed us to merge together a complicated web application, some fairly hefty batch-style analysis, and a generic report production mechanism. It has allowed us to develop a single test approach which covers all of these, including low-level services, user interface, and reporting. It provides good facilities to load database data as XML, including the automatic resolution of foreign keys. It allows us to build higher level XML-based services from lower-level XML-based services.
There are some disadvantages. Some people are not comfortable with XML. Even though XML is good as a general-purpose format, it is rarely the best tool for any particular job. There are limits to what should be done in XML, especially for intensive use.
Overall the approach works well for us, and we do not intend to change it. We now have a significant investment in XML, and we have grown familiar with it.
But now I have two other questions. First, would I recommend this approach to others? Secondly, should we develop this further as a product in its own right?
I would definitely recommend the approach if you are familiar with XML, you have complicated integration inside the application, and you want a lot of control over how it is going to be put together, as in our merging of web application, batch processing and report production.
Conversely, the approach would be overkill for architecturally simpler applications that can be developed using one single set of technologies.
I do not know whether we should develop this further as a product. The XML capabilities have been developed independently from the application that use them, and could easily be applied to other projects. We would be happy to share them under some suitable open source license, if there was a demand for this.
So I am going throw this question over to you. Would the Java and XSLT tools we have developed for XML-based programming be something that you think could be useful in your work? If we provided them as open source products, is this something that you would use? Could you contribute to them to help their further development, or know of similar projects that they could contributed to?
If you are interested, contact me.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 6 July 2010
XML-based programming 6: the dark side
Without care, XML can be difficult to understand, complicated to work with, and inefficient to process.
In the interest of balance, I want to present the negative side of using XML.
XML can be very complicated. Basic XML is easy, but once you get into namespaces, schemas and public standards, it can be a nightmare. The XML standards for Microsoft Office are over 5000 pages long.
XML is difficult to work with. It takes 20 lines of code to read a single value from an XML file using the W3C's document object model (DOM) programming interface.
XML can be very inefficient. I recently tested an XML-based routine to create 2000 questionnaires, which took 40 minutes of 100% CPU time and 500MB of memory.
Because of these problems, not everybody shares my enthusiasm for XML. Most people use a variety of scripts and files to construct, configure and test their systems, very few standardise on XML. Some use simpler standards such as JSON to represent data.
The underlying problem with XML is that because it is so flexible, methods for defining and processing XML have to cope with many different requirements. XML gives you a lot of rope: if you are lucky you just get tied in knots, if you are unlucky you hang yourself.
However, you do not need complicated XML if you are only using it to glue together your systems and to structure ancillary components like configuration files and test scripts. You can explain the rules for simple XML in less than one page. If you stick to these rules, which I find cover more than 90% of requirements, your XML will be as simple as any other data representation.
XML programming interfaces are complicated because they have to cope with all the different uses that XML can be put to. For simple XML, it is easy to create a wrapper that covers everything you want to do in a few function calls. You can process simple XML as easily as Java properties or simpler standards such as JSON, and still have the full flexibility of XML in reserve, if you need it.
The inefficiencies of XML need to be put in perspective. In my example, I was using the XML language XSLT to manage execution, which is just plain wrong. When I converted this so that Java was managing the execution, even though I was still using XML-based calls, the run time and memory more than halved, and the CPU requirement dropped to 10%. Core processing should remain in a general purpose programming language, and the core data should remain on the database; XML is there to provide a common approach to all the rest.
If you consider only one requirement in isolation, it is usually easier to use something other than XML. If you are writing Java, Java properties are easier than XML configuration files. If you are writing JavaScript, JSON is easier than XML. If you are writing a data manipulation script, bash is easier than XSLT. However, the great advantage of XML is that, with a little care, it can meet all of these requirements, and many more, with a single, consistent set of technologies.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
In the interest of balance, I want to present the negative side of using XML.
XML can be very complicated. Basic XML is easy, but once you get into namespaces, schemas and public standards, it can be a nightmare. The XML standards for Microsoft Office are over 5000 pages long.
XML is difficult to work with. It takes 20 lines of code to read a single value from an XML file using the W3C's document object model (DOM) programming interface.
XML can be very inefficient. I recently tested an XML-based routine to create 2000 questionnaires, which took 40 minutes of 100% CPU time and 500MB of memory.
Because of these problems, not everybody shares my enthusiasm for XML. Most people use a variety of scripts and files to construct, configure and test their systems, very few standardise on XML. Some use simpler standards such as JSON to represent data.
The underlying problem with XML is that because it is so flexible, methods for defining and processing XML have to cope with many different requirements. XML gives you a lot of rope: if you are lucky you just get tied in knots, if you are unlucky you hang yourself.
However, you do not need complicated XML if you are only using it to glue together your systems and to structure ancillary components like configuration files and test scripts. You can explain the rules for simple XML in less than one page. If you stick to these rules, which I find cover more than 90% of requirements, your XML will be as simple as any other data representation.
XML programming interfaces are complicated because they have to cope with all the different uses that XML can be put to. For simple XML, it is easy to create a wrapper that covers everything you want to do in a few function calls. You can process simple XML as easily as Java properties or simpler standards such as JSON, and still have the full flexibility of XML in reserve, if you need it.
The inefficiencies of XML need to be put in perspective. In my example, I was using the XML language XSLT to manage execution, which is just plain wrong. When I converted this so that Java was managing the execution, even though I was still using XML-based calls, the run time and memory more than halved, and the CPU requirement dropped to 10%. Core processing should remain in a general purpose programming language, and the core data should remain on the database; XML is there to provide a common approach to all the rest.
If you consider only one requirement in isolation, it is usually easier to use something other than XML. If you are writing Java, Java properties are easier than XML configuration files. If you are writing JavaScript, JSON is easier than XML. If you are writing a data manipulation script, bash is easier than XSLT. However, the great advantage of XML is that, with a little care, it can meet all of these requirements, and many more, with a single, consistent set of technologies.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Subscribe to:
Posts (Atom)