Multi-competence required today
Today’s software development is more challenging than ever. Yes, in some part it’s a lot easier with higher generation tools compared to assembly languages, but I claim that requirements have raised even faster than the abstraction level in tooling.
Technological competence – programmer
My Colleaque Jouni had a nice post about what you need to learn in coming year if you are a Microsoft developer. Another colleaque, Aki, posted a nice summary of what expertise every web developer should possess.
These are nice summaries, but they still leave a lot of important skills out. Aki’s post for example leaves the server-side untouched. Usually, you don’t write xhtml and css without some kind of server technology, be it Java, .NET, Php, Ruby, Python or whatever. Each of these technologies come with their own surroundings. Let’s take .NET (the one I know best), you need to know a language (C# for example), the web framework (ASP.NET, in web forms or mvc flavor, preferably both), the huge class library (BCL) etc. Sure, you need to be competent in some data access technology (like Entity Framework, NHibernate) and seldom do you make it without touching a DBMS (like Sql Server, Oracle etc).
And if you really want be a competent guy, you surely do make use of unit testing, inversion of control, be familiar with collaboration envinronments and configuration management systems, handle the application server and it’s configuration, …
From programmer to developer
After you handle all this, it merely makes you a decent programmer. Once you get there, you need to crasp a good understanding of development methogologies and patterns, have understanding of project management and teamwork, understand the basics of software business and handle all the numerous social occasions in front of angry customers you are thrown into when something has gone wrong.
Understand these things, and you’ll be a good software developer.
From developer to organizational champion
So the days of “pure C++ developer” are long gone. You need to handle multiple technologies and understand your craft thoroughly. And one of the biggest challenges to typical programmers is to accept that programming should be the last resort to solve a problem. Most often, there are better and cheaper solutions. And when you advance in your career from mere programmer, you begin to see more and more problems.
All this makes me wonder, what is the point in being in business like this? For me the answer is obvious: software development is all about learning. If you are not willing to learn, software development is not for you. If you love to learn stuff all the time, enjoy the neverending journey! And as correctly executed agile development emphasizes learning, it is perfect fit. And what does agile have to do with competence? Read on…
Cross-functional teams come from… multi-competent people!
Yes, you could make Scrum team from one tester, three programmers, one technical writer and one project manager. But do yo think a team like that would work efficiently? I guess not. Traditionally, each person has a stigma in her forehead: “I’m a tester”, “I’m a DBA” or so. My claim is that this very specialization is the biggest obstacle to productivity. I’ve way too often witnessed value streams that go like this:
- Project manager (PM) listens to the customer (C)
- PM tells the requirements to the programmer (P)
- P implements the functionality
- PM tells user interface designer (UID) the requirements
- UID makes his part and notes that P should make some changes
- PM tells P to make some changes
… - Finally PM meets the C only to find out that both P and UID had implemented something that doesn’t please the C so let’s start from 2
… - Repeat this cycle n times and start wondering, why we are not making profit.
If we had a perfect human in the sense that she had all the skills of PM, P and C there would undoubtedly be no problems (of course there would, but those could be solved immediately). But we do not have perfect humans, so we need to have people with different skill sets. So here is our formula to productivity: The more distinct the skill sets of team members, the lower the productivity will be. Or the converse: The more diverse skill sets team members possess, the more productive team will be.
As we know, each handoff to a different person needs knowledge transfer, which in turn is costly. And the more distinct skill sets, the more handoffs there will be. This can also be seen as the classic debate, generalists vs. specialists.
I’m not saying that there’s no use to specialized expertise. What I’m saying is that general competence should be the norm and specialists are extra. What did you learn today?
Tags: agile
[...] from project management to team leading, from methodologies to practises. As I believe, that over-specialization kills productivity, I like to have a broad understanding to the [...]
[...] have written before on cross-functional teams. But it doesn’t stop on the software development team. We need a cross-functional business [...]
Your post is informative. Safety is quite vital, excellent post about this topic, thank you for sharing.
~,, I am really thankful to this topic because it really gives up to date information .*~
Iíd have to check with you here. Which is not something I usually do! I enjoy reading a post that will make people think. Also, thanks for allowing me to comment!