Legendary author Steve McConnell, in his book, Rapid Development - Taming Wild Software Schedules, gives a lot of importance to the People factors in software development:
|
The first conclusion is that we now know with certainty that Peopleware issues have more impact on software productivity and software quality than any other factor. Since the late 1960s, study after study has found that the productivity of individual programmers with similar levels of experience does, indeed vary by a factor of at least 10 to 1. |
When I was a young and budding engineer, I heard quite a few of my seniors and traditional managers be-little the activity of writing code as something 'anyone can do'.
A few of them, expressed their surprise at my desire to work with and hire smarter folks on the teams. They often remarked that if my design was detailed enough and if I had my documentation drilled down to the smallest detail of every class, anyone should be able to write the code and get the system built.
Back then, for them, and a lot of huge software development body shops around the world, developers were quite literally 'resources' you could hire to write code.
One resource was supposed to be very easily replaceable by any another as-and-when needed.
As much as the picture might seem funny, most body-shops around the world, even today, are blinded by the belief that if they have their CMM, RUP and Gant Charts in place, who writes the code does not matter much. Most developers today, are roaming the streets with the symbolic 'will code for some more food' sign in their hand as they hop from one job to another and most companies are picking up these developers off the road.
Lack of respect for kick-ass programmers, Inability to differentiate the flock of sheep from the thinking brains, organizations believing that Gant charts, RUP, CMM and BDUF approaches and methodologies can make or break a project, not programmers and their competency, is in fact, to a large extent, responsible for brining the business of building software to the sorry state that it is in today.
Steve McConnell in his book uses analysis from NASA to place a tight slap on the face of this traditional thought process:
|
After 20 years of experimentation on live projects, researchers at NASA's Software Engineering Laboratory have concluded that technology is not the answer; the most effective practices are those that leverage the human potential of their developers. |
Of-course you can get 'anyone' to somehow write some code and get something that looks like a system built; but if you don't have a self sustaining team of thick skinned programmers you are bound to fail infinitely. I am completely on Joel Spolsky's side when he says that primary cause for most failed projects are incompetent teams:
|
Even though a bad team of developers tends to be the No. 1 cause of software project failures, you'd never know it from reading official postmortems. In all fields, from software to logistics to customer service, people are too nice to talk about their co-workers’ lack of competence. You’ll never hear anyone say ‘the team was just not smart enough or talented enough to pull this off.’ Why hurt their feelings? The simple fact is that if the people on a given project team aren't very good at what they do, they're going to come into work every day and yet—behold!—the software won’t get created. |
Quite obviously this describes why I had heard so many complains about the client changing the requirements, the design not being detailed enough and the use-cases not being elaborate enough, early on during my career as I worked on one of my first 'successful' grand failure. The simple fact of life was we as a team were incompetent and instead of fighting my incompetence I was being taught to hide behind a thick curtain of processes and defend it. Thankfully, I ended up seeking refuge in think-skinned shamelessness. Years later, I'm damn happy I did.
Even today, when I go into a client's offices or multiple other organizations and see their team of developers complain about the requirements changing, about lack of process and about lack of documentation, I get my first hint of what's really wrong. Almost invariably, it's the team that needs more help at becoming competent, coping up with the changing requirements and shredding off excess baggage of stupid processes.
Bruce Eckel has done quite a bit of these postmortems that Joel talks about and had the courage to explain the root cause of all software development related problems:
|
We are in a young business. Primitive, really - we don't know much about what works, and we keep thinking we've found the silver bullet that solves all problems. As a result, we go through these multi-year boom and bust cycles as new ideas come in, take off, exceed their grasp, then run out of steam. But some ideas seem to have staying power. For example, a lot of the ideas in agile methodologies seem to be making some real impacts in productivity and quality. This is because they focus more on the issues of people working together and less on technologies. A man I've learned much from, Gerald Weinberg, wrote his first couple of books on the technology of programming. Then he switched, and wrote or coauthored 50 more on the process of programming, and he is most famous for saying "no matter what they tell you, it's always a people problem." |
Jeff Atwood does not hesitate to go even as far as saying that whether your project will succeed or fail depends on whether you like your co-workers or not:
|
Let's say I was tasked with determining whether your software project will fail. With the responses to these three questions in hand, I can tell you with almost utter certainty whether your project will fail:
That last question isn't a joke. I'm not kidding. Do you like the company of your teammates on a personal level? Do you respect your teammates professionally? If you were starting at another company, would you invite your coworkers along? Do you have spirited team discussions or knock-down, drag-out, last man standing filibuster team arguments? Are there any people on your team you'd "vote off the island" if you could? |
Steve Yege, is also all about developer competency and competency of teams much more than processes. He thinks even Agile is an overkill:
|
Most great software developers around the world don't use Agile. They just work hard, they stay lightweight, and they ship great stuff. Most developers still have no idea what Agile even is. Think of that! |
Surprisingly, even the Agile Manifesto to a large extent agrees with Steve and puts people ahead of process and recognizes the importance of having a motivated team of talented programmers and giving them the best of tools:
|
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done - Deploy all the tools, technologies and processes you like, even our agile processes, but in the end, it's people who make the difference between success and failure. We realize that however hard we work in coming up with process ideas, the best we can hope for is a second-order effect on a project. So it's important to maximize that first-order people factor. For many people, trust is the hardest thing to give. Decisions must be made by the people who know the most about the situation. This means that managers must trust their staff to make the decisions about the things they're paid to know about. |
These are in-fact, words of truth and wisdom. In all aspects of life, trust is in fact really the hardest thing to give. No wonder most body shops around the world find it really difficult to provide trust to their employees. No wonder we are spending countless man-years building support for law-suite in our documentation and trying to replace quality programmers with stupid processes and 'cheap resources'. No wonder traditional managers around the world, like to nurture beliefs that given 'x' number of 'resources', irrespective of who those resources are, they can get a system built in a finite pre-determined number of man-days.
On a side note, if there is one term in software development and project management terminology I grossly dislike it's the word 'resources'. It seems to club all programmers in a very generic pool almost making it sound like programmers are 'things' or a flock of sheep. But we all know kick-ass programmers are way more than a flock of sheep.
Who you work with, to a large extent affects how successful your projects will be and ultimately how successful you as an individual will be. If you're a manager who was reading that big fat book on managing projects using CMM and RUP and hoping to hide behind the process curtain if your project fails, sorry to shatter your dreams, but you know what? That won't work. Not in the long run. Do this for a few months and I'm sure you'll cultivate a tendency to fail constantly and blame it on the lack of process. For a change, help yourself by reading a slightly different blend of books. It might help.
On the other hand, if you are a programmer who is a part of a self managing team that's shipping quality software; there's a high possibility that you'll never get to buying and reading that big fat book on CMM and RUP. Yes, you'll make big fat new mistakes in every new project. But you know what? You'll tend to learn from them and get better and successful project after project as long as you keep working on your shipping skills.
Realizing and accepting one simple fact sets a successful pragmatic leader apart from a worthless manager sitting in his ivory tower: CMM, RUP and Gantt Charts Don't Build Successful Software. Kick Ass Programmers do.
Also, while we are at it; can we please stop referring to programmers as 'resources'? It's too generalizing, makes it sound as if all developers are exactly similar commodities that can be swapped for each other and more than anything else, to kick-ass programmers who are passionate about what they do, It tends to sound a little intimidating and condescending. May I suggest referring to them as programmers, developers or team members?
Reminded me of a conversation I had with my Tech Lead, where he told me
"All the languages are almost same. You can easily code in any language if your basics are strong" and
"Look at me, I am handling 7 different projects simultaneously"
He was actually right, because if you just want to create a piece of software which "does something when you click here and there" then ANYONE can code it. But if you want to build a software where quality matters at the *core* then it not everyone's cup of tea. You have to know the technology inside out. But again, ONLY if quality matters.
> Lack of respect for kick-ass programmers
So very true. I have just started my career and realised that if you have been coding for 7-8 years and still doing it then people will look down upon you as if you were competent enough to move to a managerial role and that's why you are still *coding* !!
Even during my MCA, almost all the professors used to give us an *invaluable* career info
"You will only do the coding in the starting phase of your career. Eventually you should move to a managerial role which has nothing to do with coding"
And unfortunately that is the career path that most of the software engineers dreams about. They want to (as you said in one of your articles) *Rise above the code*
Comments are closed.