The transition from the Information Age to the Knowledge Age can be thought of as both an expansion in the workforce that can create software solutions as well as the decline of traditional point solution software companies. To the developer who is right now sitting behind a desk in a point solution software company, this can sound pretty scary.
So let me take a moment to expand upon my position to show that the great opportunities that are coming with this transition are for everyone, programmer and non-programmer alike -- as long as change in the environment is met with change in the individual.
What are the personal changes I would recommend for a programmer? Give up being a coding hack -- those days are numbered. Just as the market for assembler coders has shrunk to virtual non-existence, so too will the market for line-by-line program writers shrink – and much faster. Expect the market for line-by-line program writers to be in high-decline by 2016 and effectively gone by 2022. While I cannot speak for other platforms, I can say that QBOS will be so advanced by that time that there will be absolutely no need for coding within the QBOS multi-Tradespace system. But what there will be a need for, a vast growing need for, is analyst and interpreters -- people who can listen to a business owner or stakeholder and help them voice their needs and objectives in terms that can be rendered into well-defined requirements with a high degree of functional orthogonality (FO). To be such an interpreter (or business analyst, if you will), two primary skill sets are required. Unfortunately one of these skills is also one of the worst performed yet most needed within the IT industry -- the specification and delivery of detailed requirements (without the details, FO cannot be assured). As a developer today, you should be receiving and working from very detailed, orthogonal requirements. In large companies, the programming team is complemented with analysts and architects and designers who bear the responsibility of proper interpretation and documentation of strategic requirements. However, requirement specifications are seldom put together properly and often not at all (I suspect it is fair to say this is even more prevalent in small companies where the developers may be working without analyst support). This is one of the top three findings of the SIM Enterprise Architecture Working Group's 2007 Information Management Practices Survey and it is ranked as the number 2 out of 53 top early warning signs of IT project failure!
This creates an opportunity for the developer who wants to assure their place in coming years. Learning how to recognize gaps in instructions and whether requirements are orthogonal or not is a valuable first step for a developer who wants to evolve their value. It also puts them on a path towards designing proper requirement specifications which will elevate them out of the position of pure coding hack and plant them firmly in an area that is going to be growing in need for many years to come.
The second skill, interpretation, is a little harder to come by because it is a mixture of perspective gained through experience (so the sooner you start, the better) and interpersonal skills (I know, all us programmers are just teeth a-chatter at the prospect). This skill culminates in the ability to relate to the business owner or stakeholder along the lines of their business acumen and interests and even demonstrate insight that they had not conveyed -- insight necessary to add to their statements the granularity needed to derive the details for their requirements. This means understanding the ramifications of their statements as well and identifying and exposing any implied requirements. It is this insight that requires perspective and experience -- the more the better. It is valuable. It is in growing demand. And it is not a common talent.
The best developers today are the ones who do the best job of interpreting the client's needs into requirements that can then be carefully followed in creating the solution the client wants. The demand for this talent is only going to grow -- and along way, the need for actual coding will fall by the wayside.
So while the business analysts are already on-board, my recommendation to all programmers today is pay attention to the need for proper requirement specifications, learn the difference between good and poor requirement specifications. Look outward at the business you are supporting, how it runs, how the requirements you hold in your hand actually relate to the business you see. Study the operations of the businesses you see and work with. Study the marketing. Study the administration and all the other departments. Gain a comprehensive understanding of the business as a whole. Learn to recognize what makes a difference to the business for better and for worse. Absorb the formal business compliance standards and any methods training available to you. And along the way, you will evolve from a developer to a business analyst - the developer for the Knowledge Age.
Jim Lord, CEO
QBOS, Inc.