IT Directions

Keith Harrison-Broninski

How to become an IT professional

user-pic
Vote 0 Votes
In the last post to this blog, I outlined some of the problems with outsourced application development, and promised to provide solutions in future posts.  In particular, I said that the lynchpin of a successful outsourced application development lay in supervising the work properly, which means managing the code development as closely and carefully as if it was written in house.

To do this, you must at a minimum be able to understand the work that is being carried out.  More accurately, one needs not only to understand the work, but further, to understand how to do the work well.  Then you can step in if it is not being done in the most appropriate manner.

So here is the first step towards outsourcing success: make sure that your own organization has a professional development capability.  Even if this consists only of a couple of individuals, it is essential to have people in-house who are genuinely capable of judging the deliverables provided by an outsourcing company, and positively influencing the way in which the work is being carried out.

Unfortunately, it is getting very hard nowadays to see the wood for the trees in enterprise IT.  A recent Computer Science graduate, for instance, is likely to lack the key knowledge and skills required to make the most of an increasingly complex development landscape.  As I described in the first post in this series, the current profusion of acronyms is enough to bewilder anyone, and it's getting worse daily.

So it is useful to step back from the sea of neologisms, and divide the sorts of skills required into levels that are independent of any particular technology or methodology.  This can be done as follows.  Here is a graded series of skill levels that a software developer should rise through on their way to becoming a modern professional:

  1. Language.  This is what someone will typically know coming out of University, or after having taken certifications in a programming language.  It consists of knowing the core library classes/functions of the language(s) concerned, as well as techniques for exception handling, reflection, concurrency, and so on.  Note that superficial knowledge is not enough here - to write a language well, or code review other people's work, you need to know and understand all the features that are available out of the box.
  2. Language skills.  Once you know a language, you must then learn how to use it.  This involves stylistic aspects - the way you structure, format and document code. It also involves technical aspects - how to use concurrency safely, pessimistic rather than optimistic programming, how to instrument code to permit analysis/debugging, the different forms of collection object and their uses, proper management of loading/binding, and so on.
  3. Design patterns.  Since the late 1980s it has become accepted practice to utilize standard abstraction techniques when writing code, mainly for maintainability but also for code quality and productivity.  The key reference here is the "Gang of Four" book ("Design Patterns: Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson and Vlissides), which uses C++ and Smalltalk for its examples.  The GoF book has inspired a decade of further research. A professional programmer must know not only the 23 design patterns from the GoF book but also many additions to and enhancements of these patterns. They will also understand when and how to use each pattern, and how to refactor code - to restructure it to conform more (or less) closely to specific patterns, or just to improve its elegance and readability, without changing its functionality.  As well as for programming, there are also design patterns for enterprise application architecture - the key reference here being Martin Fowler's book, "Patterns of Enterprise Application Architecture".
  4. Frameworks.  No-one now writes enterprise applications without using an abundance of frameworks - code libraries that embody best-of-breed solutions to common technical problems. Frameworks are based on design patterns, and you cannot properly understand how to use frameworks unless you first gain confidence with application of design patterns. Many frameworks are open source and can be used to build a product intended for commercial sale.  Frameworks often have associated domain-specific languages such as XMI (XML Metadata Interchange) and OCL (Object Constraint Language). The productivity advantages of using a framework are enormous, since you may be drawing on hundreds of man-years of previous effort. For example, the HumanEdj framework for human work draws on research going back to the 1980s, and allows you to build collaborative applications in minutes that would otherwise be beyond most development budgets.
  5. Standards. Any software going into a corporate environment must interact with other software in a standardized way.  Hence such applications need to conform not only to accepted standards but also to emerging standards. For instance, any Java-based application that talks to a content management system must be aware of JSR-170 and JSR-283, which are standards for communicating with such a system via the Java language. There are many important standards pertaining to application development, some like the above arising from a language-specific community, and others (such as Topic Maps for XML documentation of linked content, or DocBook for technical documentation) from non-language-specific bodies such as ISO and W3C.
  6. Work Management.  Any professional developer should have some grasp of the various possible approaches to managing a software project, ranging from traditional waterfall techniques through to the many different agile methods and techniques.  There are also design patterns for work management - the key references here are "Organizational Patterns of Agile Software Development" by Coplien and Harrison and my own book "Human Interactions".  I will have a lot more to say about this in future postings, since agile techniques are key to the successful management of outsourced application development - whether or not the project is officially viewed as being "agile".

TAKE AWAY

The first step towards successful outsourced application development is to make sure you know what is going on.  This means that your own staff must be able to understand technical matters at least as well as your outsourcing supplier.  To achieve this, you must ensure that your organization possesses people with skills at all the levels described above.  Some of these people will have only skills to a certain level - but you will need at least some people who have all the skills right up to level 6.   The number of such people required depends on the size of your organization and the number of outsourcing projects you have going on.

This is the first step towards outsourcing success and the most crucial.  In my own consultancy work, I provide clients proposing to engage in an outsourcing project with a learning trail that their key technical staff should follow, customized to the particular type of project they are considering.  If their people are familiar with the material already, all well and good.  If not, acquiring this knowledge not only prepares them for the project in question, but is a valuable contribution to their organization's general capability - a contribution that will stand the organization in good stead in future (as well as, of course, being useful professional development for the individuals in question).

Only once your organization has developed such an in-house capability are you in a position to code review the work that is done on your behalf, as well as to engage with your supplier as to how the work is being carried out.  In the next postings to this series I will discuss how to position yourself so that such engagement is not only painless, but viewed as beneficial by both sides.

5 Comments

user-pic

Keith,

I think you've accurately descibed the reality of outsourcing, but as someone who has had his role outsourced and had to work with new practices, there is one point that should not be overlooked. This new working model is very new, and frankly the initial results are not encouraging. We are not talking about past ways of working with either a manager role or business analysts coordinating experienced developers, but a "design authority" who draws on their knowledge and experience to police others work. No problem with that today or tomorrow, but a few years down the line one's development skills become degraded from not being used. My fear is these Design Authorities will get their learnings of new technolgies second hand without the continuous practise required to keep them sharp. I think only time will tell if I'm being too pessimistic, but I suspect that soon we will not only "forget what we knew", but "forget that we ever new it" and poorly delivered applications will become the standard that everyone just accepts.

Yes, I agree, Phil. There is a big difference between seeing and doing, isn't there, even if the seeing involves in-depth review. I will be talking more about this issue in subsequent posts.
--
All the best
Keith

user-pic

I agree that your employees must be capable. They must be able to deliver quality services to satisfy the client. If all your employees are quality workers, you are on your way to outsourcing success!

user-pic

Of course IT professionals should always be updated with the latest trends. The education of IT specialists does not stop when they graduate from college. It is a continuous process.

sir,
please gve me some more tips regarding to plans future asa it professional

Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.

Subscribe

 Subscribe in a reader

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT