Nightmare of the typing pool

Will the IT profession die out like the typing pool?

For those of you lucky enough not to be at least fortysomething, the typing pool was how businesses used to get things typed.

It worked like this. You would hand-write what you wanted, and send it in for typing. A day or so later you would get it back, typed up. You would scribble amendments on it, and send it back in. Eventually, when you were happy with it, you would distribute it in the internal post.

As a trainee, the typing pool was fearsome. They definitely enjoyed the power they had over juniors like me. They had a complete monopoly. Only they had the qualifications and skills to type, only they had specialised and expensive word processors, and only they could produce documents to company standards.

The typing pool died quickly. Younger workers like me had started using word processors at college, and, although we were not qualified as typists, and our typing was shaky, we could get by.

For a while, the typing pool still had a monopoly on decent printers and corporate standards. I remember writing on mainframe text editors, and sending paper printouts to the typing pool to be typed up "properly".

But this did not last long. PCs and laser printers made it easy for anyone to produce good quality documents, and email removed any vestiges of document standardisation. The typing pool was no more.

My nightmare is that something similar, but on a larger and more complicated scale, is going to happen to IT.

We preserve our position because only we have the qualifications and skills to build and run IT solutions. Only we have access to specialised and expensive software and hardware. Only we can enforce standards.

To an extent, the role of IT professionals is already diminished. Businesses are run on Excel spreadsheets. And with products like Microsoft Sharepoint, business users can build a lot of their IT solutions without the need for us awkward and expensive professionals.

But I can think of real examples of why IT as a professional will survive.

The first example is what has happened with typing. Although typing has disappeared as a profession, authoring in its many forms (copywriting, technical authoring, web authoring) still thrives. The mechanics of writing may be available to all, but writing anything complicated, or anything for publication, still requires a specialist.

The second example is that end-user IT becomes infeasible when it gets too large. I know an IT professional with decades of experience in large databases who has been brought in to support a business critical spreadsheet that has become just too complicated to manage.

This calms my nightmare. IT will remain as a profession. It will not survive because only we have the basic skills, because technologies are too hard, because standards are complicated or difficult, or because we use certification and qualification to retain a monopoly. There is a value to removing costly professionals when you do not need them, and we should not try to stop this happening. What will keep the profession going is our experience and skill in larger, more complicated and specialised solutions, which will always remain outside the scope of anyone other than a professional.

© Copyright 2011 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

You Aren't Gonna Need It, revisited

It is better to spend time on system structure, documentation and testing than on adding features that you do not currently need.

You Aren't Gonna Need It, or YAGNI, is a programming principle which states, "Always implement things when you actually need them, never when you just foresee that you need them."

YAGNI saves time because you do not develop features that you do not actually need. YAGNI keeps your code simpler because it is not polluted with unnecessary features. YAGNI is realistic because what you imagine you want now will probably not be exactly what you do need, when you do finally need it.

I try to follow YAGNI when developing systems. However, recent work on our Metrici Advisor product has made me question whether we have been applying YAGNI too much.

We have been adding a new feature to allow user-defined server-side code in JavaScript, for example to provide custom calculations. Previously, we had not considered providing a JavaScript interface. However, we do have an XML-based service layer between the front-end user interface and the back-end functionality. We also use this to provide a web services interface to the product, so it seemed a suitable integration point for JavaScript.

Using these services in JavaScript has been frustrating. Although the services are just what we need from the user interface, some are difficult to use from JavaScript. For example, to identify data, we use either internal numeric identifiers or text references. Some services use one, some the other, some either. Some update services return data to redisplay a page, others do not. And so on.

This has made me wonder whether we had applied YAGNI too hard. Had we created services which were so specialised to the user interface that they are not good candidates for reuse?

While reworking some of the services and making them more usable from JavaScript, a number of things made me realise that our original decisions were reasonable.

First, we have good tests for these services. Adding a new option is not that hard when your tests guarantee that you are not going to break existing functionality.

Second, we have reliable documentation. This makes it easy to understand what is going on and, for example, work out how to add options that do not invalidate existing calls.

Third, the system is reasonably well structured. For example, we use a parameter parser to interpret service parameters. More recent services use an improved parser which can use either internal numeric identifiers or textual references. We can simply slot this into older services to make them more usable from JavaScript.

Although it is frustrating to rework old code, I think on balance we were right to keep the services simple initially. If we had added to them, we would probably not have added exactly the features we need now. And by spending our time on design, on documentation, and on testing, we did prepare the services for future use.

So is YAGNI worthwhile? When it comes to functionality, You Aren't Gonna Need It is a good principle. But you are going to need testing, and documentation, and good structure, so spend your time on these rather than on building functionality that you might never need.

© Copyright 2011 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

How to choose architecture and technology

Architecture and technology decisions need to be driven by IT management requirements more than by functional business requirements.

We have plenty of methods for analysis and design, for project management, for programming, and for evaluating software. But we rarely take a methodological approach to defining an overall architecture and selecting the main technical components within it.

Part of the reason for this is that major architectural and technology decisions have usually been set by earlier acquisitions and projects, and, rightly or wrongly, new solutions tend to fit into what has gone before.

But if it is not already set, how should you define architecture and technology?

I do not think that you can start with business requirements, or even general non-functional requirements such as security and usability. Business requirements translate into IT functionality, and most modern architectures can deliver pretty much any functionality. You need to start with broader IT management requirements, such as:

• Constraints of existing architectural choices or of chosen solutions.
• Which parts of the solution are going to be developed and run in-house or externally.
• Availability of skills.
• Need for longevity of the solution.
• Whether acquisition cost and running cost are significant factors to the organisation.
• The degree of independence of the different business areas served.
• The size and location of the user population.
• Likely availability of packaged application software.

Once you understand the main IT management requirements, you can consider the architecture by splitting the overall solution down into major chunks. You will need different chunks for independent business areas. You will need different chunks where pieces are outsourced, or where you may use packaged software. If longevity is a major concern, you need to split solutions so that different parts of the solution can be replaced independently, and pay attention to standards.

Once you have the major chunks, pick sets of technologies that fit into your architecture, which are conventionally used together, and which meet your IT management requirements. These may well be subsets of one of the major families of technologies, such as Microsoft, Oracle, open source or IBM mainframe. However, just because you pick, say, Oracle, it does not mean that every product from Oracle is appropriate. You still need to think through which pieces of that family meet your IT management requirements, and steer away from the ones that do not.

This is not in any way a detailed method, but for me the key points of defining an architecture and picking the right technology are:

• Base major IT architecture decisions on how you need to run your IT rather than what you want to do with your IT.
• Remember that management is more important than technical elegance. Often IT management will require that you break up the architecture even when the technology would allow tighter integration.
• Although most of the time you will pick one of the major technology families, make sure that you use it in a way that is consistent with your management requirements, and not blindly adopt it all as a standard.

© Copyright 2011 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Who aren't you?

To really explain who you are, you have to explain who you are not.

One of the difficult things about any profession is marketing yourself. You have to convince colleagues, customers, partners and employers that you are someone worth doing business with.

As an established employee, this is not that hard. Your colleagues get to know you, the things that you are good at, and the things that are best directed to others. You can be reasonably honest about who you are.

If you are looking for a job, or working as a consultant, it is much harder. The employers and clients do not know you. With all the competition for your services, you must not admit any weakness. You have to be all things to all men. You have to be a great team player and capable of working on your own, a great manager and great at following the direction of others, innovative and good at following standards, and so on.

The problem with this unremittingly positive viewpoint is that it does not really explain who you are at all. If you are all positive, you will mismanage expectations or just not seem credible.

Somehow, to give a more accurate view of ourselves, we have to communicate what we are really good at, and what we are not so good at, without actually presenting this as weaknesses.

One way of doing this is to present yourself as a set of preferences. To show you what I mean, here are my preferences.

• I am a leader more than I am a manager. I enjoy setting a direction and enthusing people to follow it. But I a not enthusiastic about managing a team just for the sake of being the manager.
• I consider fundamentals more than the details of products. I focus on understanding different types of technologies and how they work together, rather than the details of specific versions of specific products.
• I am concerned with solutions and software more than infrastructure. I can shape solutions to meet different types of business and management requirements, and although I understand what infrastructure does, I am happy to leave the detail of setting up the infrastructure to others.
• I am a generalist more than a specialist. I look at IT strategy, requirements, value, technology, development and operations. I can contribute to many areas, but like to work with specialists on more detailed work.
• In my communication, I try to cover the key points of the situation impartially, rather than focussing too much on just what people want to hear.

I could have listed a set of weaknesses - my low patience with project management, a lack of detailed knowledge of products and infrastructure, and a less empathetic approach in my communication. But by explaining these as preferences, it paints a more positive picture of who I am, without conveying a sense of weakness.

What I found really good about writing this is that it made me more confident. I can be honest, without either underselling myself or mismanaging expectations.

To market yourself, you need to be able to explain who you aren't.

© Copyright 2011 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.