Although very different, the IT industry can learn lessons from the movie industry.
When I was a student, a common type of exam question started "Compare and contrast ...", and would then continue with a couple of items to test your knowledge, like "... the feeding strategies of coral and carnivorous plants".
In a throwback to my student days, I though I would do the same. Today's exam question is "Compare and contrast the IT industry and the movie industry."
In many ways the two industries are very different. The movie industry focusses on the production of unique, consumer-oriented products (movies). The IT industry focusses on the production of more standardised, often business-oriented products (IT systems). Video games are an exception, and indeed are often linked to the production of movies.
Each movie is a one-off, independent entity. Even where a sequel or a series is produced, each movie is a separate artistic and commercial endeavour.
IT systems are rarely one-off, or independent. Computer software is integrated with other software, and software is periodically replaced with new versions. If this were to happen in the movie industry, you would be sent an update to each movie every quarter in which there was an even happier ending.
Despite these differences, the IT industry can learn from the movie industry.
Responsibility for the creation of a movie is split into two. The director is responsible for the artistic content. The producer is responsible for management. The producer and director each pursue their own role, and although there will be conflicts, each role can be represented effectively.
IT rarely defines roles so well. Often IT project managers act as both a technical and management lead. Some project managers achieve this admirably, but most project managers favour one or other role, and in many cases neither is done well.
Movies are well-defined entities. Although IT systems are very different from movies, they would also benefit from the a higher degree of definition and separation, to make management of them simpler.
IT projects and movie projects can both have very large budgets, or very small budgets. The return on investment can vary hugely from one project to another. Sometimes low-budget productions give astronomical returns. In each industry, a small number of successes finance a large number of failures. This is not well understood in IT, and is a constant source of frustration.
Lastly, the success of movies is heavily dependent on celebrity. A famous actor can almost guarantee the success of a movie. Newcomers are attracted to this glamour. IT has fewer stars, and is less willing to admit that some individuals make a disproportionate contribution to the success of IT.
Although very different, the IT industry can learn lessons from the movie industry. IT projects can benefit from a more defined split between technical and management responsibility, with neither overriding the other. IT systems can benefit from a more careful definition and separation, to make their management easier. IT can learn about financial return from the movie industry, rather than glibly assuming that all IT spend is worthwhile. Lastly, IT could recognise that some people make a disproportionate contribution, and use success and celebrity to attract and develop talent.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 23 February 2010
Tuesday, 16 February 2010
An unprofessional experiment
In our enthusiasm for our own profession, we make IT complicated and reduce value to IT users and owners.
Like all professionals, we are interested in and believe in what we do. And like all people, we are a bit selfish. We like to keep the best for ourselves.
You can see this in the IT that we ourselves use – the operating systems, development tools, methodologies, and operations tools that are aimed at IT professionals. These are much more fully featured and elegant than many of the end-user systems that are the ultimate goal of IT.
In fact, an awful lot of IT's efforts are aimed at IT itself. We are constantly reworking our design methods to make them more intellectually satisfying and elegant. We value abstraction and reuse, which allows us to consider problems in the general case and reapply solutions multiple times. We are forever creating new frameworks, components and toolsets. We, the suppliers of IT, are very well served by IT.
I am a particularly bad offender. I have built my career on the technologies, tools and methods internal to IT. The main product I sell, a generic tool for evaluating IT management, is aimed at IT and not direct business use.
To an extent this introversion of IT does trickle down into better systems for end users. But there is a darker side. All too often, we get carried away with the IT, building ever more elegant but convoluted solutions. We spend more time understanding technologies and tools, and navigating the complex interdependencies of a modern environment, than we spend on understanding and fixing real business problems.
As an example, I have recently been working with Microsoft integration and database tools. Used properly I am sure these are wonderfully elegant and productive, but we spent ten times longer configuring and debugging the environment than we ever spent on solving real business problems.
As well as overemphasising elegance, we constantly undervalue the boring parts of the solution that can help us manage efficiently in the long term, such as good documentation and regression test plans.
So, I am going to do an experiment. I am going to run a little project and try to shift my efforts from elegance, tooling and development efficiency to useful functionality and manageability. I want to:
I want to see what a system would be like if we focus solely on what is of real value to the user and owner (functionality and manageability), rather than what appeals to me as an IT professional (technological elegance).
I do not know if I will succeed. I may be diverted by the IT stuff, such as making simple programming elegant, or minimising dependencies, or self-testing systems. But I am keen to see if, by being less of a professional, I can focus more on what I should really be doing.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Like all professionals, we are interested in and believe in what we do. And like all people, we are a bit selfish. We like to keep the best for ourselves.
You can see this in the IT that we ourselves use – the operating systems, development tools, methodologies, and operations tools that are aimed at IT professionals. These are much more fully featured and elegant than many of the end-user systems that are the ultimate goal of IT.
In fact, an awful lot of IT's efforts are aimed at IT itself. We are constantly reworking our design methods to make them more intellectually satisfying and elegant. We value abstraction and reuse, which allows us to consider problems in the general case and reapply solutions multiple times. We are forever creating new frameworks, components and toolsets. We, the suppliers of IT, are very well served by IT.
I am a particularly bad offender. I have built my career on the technologies, tools and methods internal to IT. The main product I sell, a generic tool for evaluating IT management, is aimed at IT and not direct business use.
To an extent this introversion of IT does trickle down into better systems for end users. But there is a darker side. All too often, we get carried away with the IT, building ever more elegant but convoluted solutions. We spend more time understanding technologies and tools, and navigating the complex interdependencies of a modern environment, than we spend on understanding and fixing real business problems.
As an example, I have recently been working with Microsoft integration and database tools. Used properly I am sure these are wonderfully elegant and productive, but we spent ten times longer configuring and debugging the environment than we ever spent on solving real business problems.
As well as overemphasising elegance, we constantly undervalue the boring parts of the solution that can help us manage efficiently in the long term, such as good documentation and regression test plans.
So, I am going to do an experiment. I am going to run a little project and try to shift my efforts from elegance, tooling and development efficiency to useful functionality and manageability. I want to:
- Develop a simple web-based application.
- Use only simple programming, with no additional tools or frameworks.
- Manage external dependencies well, so that the system can be run or developed without any complication.
- Provide complete documentation: user documentation, developer documentation, operations documentation and legal documentation such as licensing.
- Complete regression testing, without complicated tools or frameworks.
I want to see what a system would be like if we focus solely on what is of real value to the user and owner (functionality and manageability), rather than what appeals to me as an IT professional (technological elegance).
I do not know if I will succeed. I may be diverted by the IT stuff, such as making simple programming elegant, or minimising dependencies, or self-testing systems. But I am keen to see if, by being less of a professional, I can focus more on what I should really be doing.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 9 February 2010
Programming is the last thing you should do
When you are developing a system, programming might be one of the last tasks in the project plan.
I have just finished working on a project to develop the data integration and storage for a data warehousing initiative. We had a challenging deadline, and needed to organise the work very carefully to meet it.
We did meet our deadline and delivered on time. But two weeks before the end of the project, we were only just starting the bulk of the programming. I felt a bit unprofessional, as if we had left most of the important functionality until the last minute.
But when I thought about it later, I decided that we had approached the project in the right order. On the office wall, I keep a reminder to help me when developing our own web-based products. It reads:
This reminds me to take an incremental, outside-in approach to development. Look at outputs first, and check that they are usable by creating a working model. Document what you are going to do. Make sure you can verify it by creating tests. Lastly, do the programming.
I wrote the list to make me focus on the important parts (usability and verifiability) rather than just hacking code.
The project I have just completed was a very different sort of project, building back-end infrastructure rather than web-based applications. But in essence we followed the same approach.
Our first tasks involved creating examples and documentation of the types of database tables that would be the ultimate output of the work.
We spent time thinking how we could test the work. We created stored procedures and scripts to check that the data in the database is as we intend.
Our first development increments focussed on the hardest things such as the technical architecture, to make sure that the overall design fitted together. We did these first because they had the most technical risk, even though they involved less programming.
We wrote lots of tests before we started the bulk of the coding. We created a complete sample scenario to exercise every condition in the system, and built a complete set of regression tests around this.
Lastly, we tackled the final coding.
I think the order we took is right. Of course it would have been nice to have more time on polishing and exercising the code. But we were very pushed for time, and had to focus on delivering in the right order. Programming is not the hardest or riskiest part of a project. To de-risk this project, we needed to focus on the required outputs, the technical architecture, the overall design, and how to verify it, before we started hacking code. In many projects, programming is the last thing you should do.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
I have just finished working on a project to develop the data integration and storage for a data warehousing initiative. We had a challenging deadline, and needed to organise the work very carefully to meet it.
We did meet our deadline and delivered on time. But two weeks before the end of the project, we were only just starting the bulk of the programming. I felt a bit unprofessional, as if we had left most of the important functionality until the last minute.
But when I thought about it later, I decided that we had approached the project in the right order. On the office wall, I keep a reminder to help me when developing our own web-based products. It reads:
Development Increment
- Mock-up user interface.
- Create working model of user interface.
- Document required functionality.
- Create test harness.
Then, in smaller increments:
- Develop test output checks.
- Develop test inputs.
- Fail tests.
- Code until tests passed.
This reminds me to take an incremental, outside-in approach to development. Look at outputs first, and check that they are usable by creating a working model. Document what you are going to do. Make sure you can verify it by creating tests. Lastly, do the programming.
I wrote the list to make me focus on the important parts (usability and verifiability) rather than just hacking code.
The project I have just completed was a very different sort of project, building back-end infrastructure rather than web-based applications. But in essence we followed the same approach.
Our first tasks involved creating examples and documentation of the types of database tables that would be the ultimate output of the work.
We spent time thinking how we could test the work. We created stored procedures and scripts to check that the data in the database is as we intend.
Our first development increments focussed on the hardest things such as the technical architecture, to make sure that the overall design fitted together. We did these first because they had the most technical risk, even though they involved less programming.
We wrote lots of tests before we started the bulk of the coding. We created a complete sample scenario to exercise every condition in the system, and built a complete set of regression tests around this.
Lastly, we tackled the final coding.
I think the order we took is right. Of course it would have been nice to have more time on polishing and exercising the code. But we were very pushed for time, and had to focus on delivering in the right order. Programming is not the hardest or riskiest part of a project. To de-risk this project, we needed to focus on the required outputs, the technical architecture, the overall design, and how to verify it, before we started hacking code. In many projects, programming is the last thing you should do.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 2 February 2010
In praise of HTML
HTML should be the first choice for most documentation produced in IT.
Hypertext Markup Language (HTML) is intimately associated with the world wide web. This strong association can stop us seeing that HTML is of itself a powerful standard, and can be used very effectively for documents that are not intended for publication on the web.
The core of HTML is simple. It is based on plain text files, with some additional markup to control formatting. So, for example, if you want to emphasise something, you enclose it in a .. sequence. You can do this easily in a text editor. There are good, free tools for editing HTML such as Amaya.
We can, and should, use HTML more widely is system documentation, including design documents, specifications, test plans and operations documents. Almost universally, these are produced in Microsoft Word, but for these types of documentation HTML has a number of distinct advantages.
Anyone can read and write HTML documents. This might not sound much of an advantage since nearly everybody uses Microsoft Word. However, system documentation has to last for many years. There is already enough confusion around word processor document formats. Are you really confident that what you write in Word today will be usable in 15 years time?
If you need to publish the documentation widely, it is much easier to have HTML on an intranet server than to make a Windows file server available to everyone.
HTML works well with source code management products, which are routinely used in systems development. HTML is compact, and it is feasible to retain a complete history of old versions of documentation alongside the versions of code that it documents. HTML is simple enough to allow a source code management system to merge changes made by different people. Although Word can track and merge changes, it does not lend itself to this level of collaborative development.
HTML's hyperlinks make it easy to divide documentation into manageable chunks, and then link between the different parts. This allows you to write documentation that is broken down to mirror the structure of the IT solution, and still read it coherently.
HTML works well with other technologies. It is easy to link to other pages or files. Although HTML itself does not include drawing commands, adding diagrams is easy. I create diagrams using Inkscape, and then export them as portable network graphic (PNG) files to include as pictures in the documentation. Although this takes a little longer than the drawing tools in Microsoft Office, the drawings are much easier to maintain and reuse through the life of the documentation.
Lastly, I like HTML just because it is simple. Although it is possible to produce nearly any formatting effect in both Word and in HTML, HTML's simplicity makes it a lot less tempting. You focus more on producing simple, readable, usable documentation, rather than unnecessary formatting.
I do not use HTML for everything – I would not use it for writing a proposal or management report. But it is much better than Word for the bulk of documentation we create in IT.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Hypertext Markup Language (HTML) is intimately associated with the world wide web. This strong association can stop us seeing that HTML is of itself a powerful standard, and can be used very effectively for documents that are not intended for publication on the web.
The core of HTML is simple. It is based on plain text files, with some additional markup to control formatting. So, for example, if you want to emphasise something, you enclose it in a .. sequence. You can do this easily in a text editor. There are good, free tools for editing HTML such as Amaya.
We can, and should, use HTML more widely is system documentation, including design documents, specifications, test plans and operations documents. Almost universally, these are produced in Microsoft Word, but for these types of documentation HTML has a number of distinct advantages.
Anyone can read and write HTML documents. This might not sound much of an advantage since nearly everybody uses Microsoft Word. However, system documentation has to last for many years. There is already enough confusion around word processor document formats. Are you really confident that what you write in Word today will be usable in 15 years time?
If you need to publish the documentation widely, it is much easier to have HTML on an intranet server than to make a Windows file server available to everyone.
HTML works well with source code management products, which are routinely used in systems development. HTML is compact, and it is feasible to retain a complete history of old versions of documentation alongside the versions of code that it documents. HTML is simple enough to allow a source code management system to merge changes made by different people. Although Word can track and merge changes, it does not lend itself to this level of collaborative development.
HTML's hyperlinks make it easy to divide documentation into manageable chunks, and then link between the different parts. This allows you to write documentation that is broken down to mirror the structure of the IT solution, and still read it coherently.
HTML works well with other technologies. It is easy to link to other pages or files. Although HTML itself does not include drawing commands, adding diagrams is easy. I create diagrams using Inkscape, and then export them as portable network graphic (PNG) files to include as pictures in the documentation. Although this takes a little longer than the drawing tools in Microsoft Office, the drawings are much easier to maintain and reuse through the life of the documentation.
Lastly, I like HTML just because it is simple. Although it is possible to produce nearly any formatting effect in both Word and in HTML, HTML's simplicity makes it a lot less tempting. You focus more on producing simple, readable, usable documentation, rather than unnecessary formatting.
I do not use HTML for everything – I would not use it for writing a proposal or management report. But it is much better than Word for the bulk of documentation we create in IT.
© Copyright 2010 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Subscribe to:
Posts (Atom)