Share via

FAQ - Where are my skills going to be required with Software Factories?

  • Article

In a previous FAQ we addressed some of the fears that our 'eager-professionals' are likely to have about the introduction of software factories into their projects and organisations. In this post I want to address one of the concerns that the expert solution developers among them and their organisations will face with the advent of software factories.

Some of those fears raise the question of "where will my expert development skills fit in with solution development with software factories?"

Specifically, how, adoption of software factories will change aspects of the landscape of software development today, and how that shapes the way we as solution development professionals focus our efforts from the tasks we perform today. In short, how prolific adoption of factories will change the roles of today's developers, and the mix of developer skills in organisations.

Backgrounder

An overall objective of the industrialisation, that software factories bring, is to reduce the shear amount of manual labour required to be performed by solution developers (and cost of course) in developing solutions to specific well defined solution domains. I'd also say that just as important - is to reduce the amount of re-work, and increase the amount of re-use of experience (and assets) of others who have already solved those problems thoroughly already. Today there are an inordinate amount of solution developers who re-craft artefacts for already solved solution domains over and over again, and that is handicapping what they can deliver. In order to do this today, developers knowledge and skills are required to span, in depth, many domains in order to piece together whole solutions. Due to practical resource limitations (like time and money) this often results in sub-optimal solutions, either because they don't have the resources, experience or knowledge to do this - which of course means the solution doesn't get whatever the individuals don't have.

OK, I think everyone understands the issues here and where this is going, so let's not harp on too much about it at this stage. Suffice to say, that the introduction of factories should basically relieve a great deal of current expert solution developers from having to possess (and maintain) a great deal of knowledge, experience and skills specific to known solved domains that they build.

So, this begs the question: "if a factory already does a lot of this work for me, what is left for me to do now? How are my current skills relevant anymore?"

[Just to clarify, we are really addressing those solution developers whom today create whole solutions rather than those who are only focused on very specific highly customizable tasks and responsibilities. For example, those who only write business logic rules. Of course, these folks roles and responsibilities probably won't change much with introduction of factories.]

Answer

I think the obvious answer is that the skills are still very relevant and will continue to be, but the role and focus of the individual developers now changes - particularly those who craft large parts of the overall solution. Instead of creating whole solutions (or parts of them) repeatedly, certain developers are going to have to focus on more profitable tasks in a software factory product value chain. In other words, some developers are going to build solutions using factories and some are going to build the factories (and their assets). These two primary roles are going to require a different division of skills, knowledge and experience and ultimately resource than what is done today.

[I believe there might be further secondary roles also, like those for factory customization and those for factory product customization, which may, or may not be the responsibility of the same people in the primary roles. I just wanted to focus on the main roles for now].

It might be a safe assumption therefore to conclude that once software factories are in wide and extensive use in development organisations we can expect to see a change in the mix of development resources required on mainstream solution development projects.

Whereas we see today most expert solution developers are required to possess expert level knowledge, skills and experience in all domains of a solution, tomorrow we will see that the expert solution developers will be either required to have higher-level development skills using high-level assets and abstractions (models, designers etc), or required to have lower-level programming skills for creating the assets (models and designers). [Lower-level programming skills means the programming skillsets we see in expert developers today. Although, tomorrow they will be relatively more specialised to certain domains than today.]

Furthermore, we can also expect to see a change in percentage of each group. Whereas we see most solution developers possessing the lower-level programming skills today covering whole solution domains, tomorrow the majority of mainstream solution developers will possess the higher-level development skills to cover the whole domain, leaving fewer (more specialised) lower-level programming skilled developers. Very few bridging this gap. In fact, this gap may just be transitory, and a means to go from mainstream development to specialist programming developers. We can also predict that some organisations will branch out further to either business.

So, to summarise. If you are an experienced mainstream solution developer today, chances are you are required to be an expert in many of the domains of the solutions you build. Of course, few can say they are the top enough experts in all the required domains of their solutions, but most (due to market pressures, and resource constraints) have to deliver on all those domains.

Tomorrow, when factories are prolific, you will have a choice, of either 'keeping your hand in the game' and specialising more in many fewer of these domains and create/customize re-usable assets that are likely to find they way into the factories to build solutions, or generalising more (at a higher-level of abstraction) and assembling the solutions using factories. As an entrant novice into the development market, the chances are you'll enter as the latter and through experience, or by organisation necessity (or perhaps passion, or other pressure), work your way into specialisation.

Like it or not, customers and the market will ultimately determine the required balance of skills, and organisations will have to adapt to be able to deliver on the market demand. One thing is for sure, once factories have proven their value in productivity, quality and cost savings, those organisations who still hand-craft solutions as inefficiently and of variable quality as they do today for mainstream markets, will certainly be mainstream no longer, and will be forced to move towards boutique software solutions to be profitable.

Comments

  • Anonymous
    January 03, 2007
    I buy software factories as a way of avoiding solving problems that have already been solved (which is typically not very interesting work anyway), but the implied idea that applications will consist of nothing more than the coordinated output of software factories seems naive. While it might be true for certain simple cases, for anything else it's a recipe for mediocrity (and going through ridiculous hoops just to fit an existing pattern). Now that I think of it, exactly the sort of thing that would appeal to the accountancy consultancies who have done so much to codify idiocy. Are we doing nothing more than pandering to the people who are just to cheap to acknowledge that some tasks actually do require a degree of aptitude, experience and skill, and that these things need to be paid for? I fear we are.

  • Anonymous
    January 03, 2007
    The comment has been removed