What's wrong with software development in large corporations
How much time does it take to become a knowledgeable professional? 2 years, 4 years, 10 years or half a lifetime? How much time does it take to become a good artist such as painter, musician or composer? What about the saying that good artists are born? That somehow implicitly means that either you are a good artist by birth or you aren't and you can try as hard as you wish, you'll never become a good artist even if you had an eternity.
What has that all to do with software development? If work in the IT department of a larger corporation or as a consultant helping them, you'll certainly can tell by now what I'm about to write next. It doesn't matter where you look, you'll get to know over time hundreds of people working as programmers for those corporations and it's very, very rare to encounter someone who really has a clue about what he's doing. Think about something as common as object-oriented programming. How many people do you know who really got it and are able to come up instantly with a good OOP design with good separation of concern, all those little collaborator objects talking to each other and so forth? I guess you will have to think hard. Sure there has been that one guy or gal but that's about it - isn't it? But you certainly can easily remember a fair number of people who call themselves software architect and the only contribution to the project you were working on where a lot of blockage and repeating stuff that sounded awfully similar to some vendor's sales talk to praise their rigid waterfall'ish tools.
But why is that? I think it has something to do with education and the expected behavior good employees should show. Let's start with the latter.
Today's corporations are still created after the organizational model of the military. Any military organization has a clear chain of command where orders flow down from high rank to lower rank and the lower rank is expected to execute the order given by the higher rank without questioning it. That works great in a battle situation - at least that's what you usually hear about that. But let's ask for a moment what that battle situation actually is. It's quite simple and cruel at the same time. Any battle ends with a large number of dead people and low ranking soldiers are disposable "units". Nobody really cares if they die. The less the know about the overall picture and the more they believe in what you want them to believe the easier it is to make them accept the risk, which nobody would ever accept under normal circumstances. But let's not slip into talking too much about that topic. The point is that in the military it is not common to not inform lower ranks about the overall picture, they get some strong motivation to do a stupid thing (put themselves up for being shot) and they are made to follow orders without questioning - and of course there are sanctions put in place for those who do question and not follow an order.
Now let's look at any corporation. The chief in command is the CEO. He has a number of officers (CFO, CIO, etc)., which command other officers at the departamental level and so on until it comes to the ranks of sergeant, corporal leading groups of privates. The sergeants and corporals are the low ranking line managers and the privates are the common workers. So in the world of corporate software development we can identify the programmer and tester as privates and their team lead as some kind of corporal. The project manager might be some kind of sergeant. As you can see that all so important project team is not so important after all. At least from the vantage point of the commander in chief, the CEO commanding the corporation.
How much time does it take to become a good soldier? Most armies of the world train their lowest ranking members for something betwen a 12 or 18 months. In the beginning they perform some tests to determine whether a person is better suited for less complex work, that is usually Army or manufacturing in most corporations, or for more complex stuff, which is usually Navy/Air Force or administration/support/development. Then basic training starts and the most important part of that basic training is to learn the rules. That is to make people understand that they have to obey orders or suffer consequences. In the corporate world the common consequences are reassignment or you simply get fired. And as people's well-being depends usually on their job, everybody understands all too well that it's a bad idea to show too much of an independent mind.
So... What is software development in its core? Is it some other form of manufacturing? Or is it research or art or what? Can you construct software or is it more that you create software?
It depends on how you answer these questions whether you want corporate soldiers (sergeants, corporals and private) to work on projects or not.
In my opinion software development is something between research and art. After all the word development implicates that something gets created for a purpose and before you develop you will have to know what the purpose is (the problem you want to solve; what you want to improve), what the environment looks like, who will use it, etc. So that includes a very large research component as well. I think one can describe software development as some kind of exploration with the goal to create something with a certain level of quality to solve a problem that is well understood.
That doesn't sound very much like a battle situation - does it? One may think that a good part of software development is about learning, reflection, experimentation and other activities usually associated with scientists. And when it comes to write the code then skills and attitudes, which musicians are known to possess, will be helpful. It needs an awful amount of time to practice test-driven development and be disciplined enough to implemented only what's needed to solve a problem described by a user story.
What's the situation of most corporate programmers? They get hired based on their resume and then put to work on a project. Typically the HR department decides upon hiring or not and they do some kind of pattern matching by looking at the keywords. They get a shopping list from the department and if it says Java, Struts and Junior Programmer, they will easily find someone with less than 5 years experience. Now that poor soul arrives and gets assigned some tasks by the team lead (sent into battle) and there we go. Will that person be creative? Will she be part of a group analyzing the business problem the team wants to solve? Usually not, because everything has already been done and now it's about to write the code based on a specification, which is kind of the battle plan.
Now here is a suggestion. Wouldn't it be great to employ the master/apprentice model known since the middle ages? Why do we allow inexperienced people to mess around with the most important thing in software, which is the code? I think a well motivated apprentice working alongside with a good master will evolve into a true master himself over the years. He will take more and more load off his master as his skills evolve. He will understand why the master does employ certain techniques and why he doesn't use X or Y in different situations. That takes time. But the quality will be higher and so will be the capacity of the whole team, because the team will be comprised of more masters as time goes on. That's an investment and corporation leaders would be wise to invest into the future of the corporation they serve instead of only stare at the short-term shareholder value created in any given quarter.
How long does it take to become a master? In my home country Germany plumpers, carpenters, painters, electricians and others spend three years as apprentices and easily up to eight years as journeymen before they are allowed to lead their own shop as masters. So that old saying "learn how to program in ten years" isn't that wrong after all. Between 4 - 6 years formal study at the university followed by an apprenticeship of maybe 2 years means one learns for at least 6 - 8 years. The next few years are then to hone one's skills and after 10 years one will know the whys and hows of software development.
Re: What's wrong with software development in large corporations
Your ten years statement sounds about right - but maybe only for those of us who get stuck in an army-like company and temporarily lose our way.
Re: What's wrong with software development in large corporations
It will never happen.
Why?
Because corporations refuse to be held hostage to anything that might be described as talent. They know where that goes- dependency on talent. Look at the NBA and Hollywood if you want to see what dependency on talent leads to. The talent calls the shots in terms of projects and remuneration.
instead, corporations have agreed to the McDonalds model of the programmer-employee. They are not talented. They are therefore numerous and above all cheap. All corporations agree implicitly in a type of open conspiracy to follow this model. That way, they never get into wars based on software quality- they just do not go there. They compete on branding or marketing or strategic alliances of any number of other things, but not quality- it all sucks. It all crashes and it is all behind schedule and over cost because the developers all suck and that is the way it is- everywhere- so you cannot go looking elsewhere for better, Mr. Customer, because it is not out there.
Get it? They are not going to be beholden to talent, no matter what.
When I was taking my software project management course, our professor came in and said -
"What is the first thing you do when you take over a department? You find that one guy the company absolutely positively cannot function without, and you fire him".
Why, as explained above.
The only room for talent is in the executive suites, and oh what "talent" we find there. Just read the headlines for the kind of talent money buys there.
Corporations are the latest instantiation of the oldest game in the world- the game of owner - serf. The owner is the owner because he is the owner- no further justification is necessary in terms of performance based metrics.
The serf is the serf no matter what they are capable of.
Power flows one way and there is no concept of "worthiness" or "talent" permitted to develop as it might apply to the serfs.
The owners pay themselves whatever they want and populate their boards and "watchdog" agencies with other owners that they're good buddies with.
It's all a scam but a scam that makes them a lot of money.
There is no competition for talent because there is no talent (permitted to be acknowledged).
Re: What's wrong with software development in large corporations
I believe the role of analysts and programmers shouldn't be dissolved. If you look at the fugue rules of musical composition, you will see many pre-established structures. Nevertheless, some great composers (like J.S.Bach) were able to be very creative in spite of these restrictions. When it comes to art, restrictions may increase the artist's creativity as it directs the artist's efforts. There is still space for creativity even when specifications are done, but I also believe that programmers on this situation are more likely to not know much about what they're doing if the communication between analyst and programmers isn't good. The master/apprentice suggestion, then, would fit very well, as the novice programmers would learn more about analysis, client interaction, etc.
Re: What's wrong with software development in large corporations
Re: What's wrong with software development in large corporations
Your blog title bills you as a "Software Technology Consultant."  I wonder if perhaps this job hasn't put you in the same perceptual situation as a police officer.
I'm told that it's very easy for police officers to become cynical about people, if not blatantly contemptuous. I've heard speculation that this occurs because the police are forced to interact with human beings primarily under the worst conditions.  If you meet a cop, chances are there's something wrong.  With that sort of behavioral sampling, who wouldn't develop a skewed viewpoint?
Perhaps as a consultant, you are usually called in when projects, departments, and companies are failing. Finding incompetence in such situations would not be too surprising.  I wonder if this has skewed your viewpoint as well.
I suppose it's also possible that I'm a poor judge of intelligence, or I've just had an amazing run of good luck with encountering smart co-workers.
Re: What's wrong with software development in large corporations
If you don't know the real reason for this, maybe you should learn some elementary economics.
(Hint: It has nothing to do with ensuring a basic level of skill.)
Re: What's wrong with software development in large corporations
Re: What's wrong with software development in large corporations
Even if that is true, is it always good? In other words, is better quality always good?
The answer is no. Better quality is good only up to a certain cost. Beyond that, it is a loss.
There are some places where an untrained 20 year old who can code PHP for $15/hour is better than a guild-trained 30 year old man who has a family to feed.
Forced interventions in the markets process (like guilds, professional licensing,etc) produce unintended consequences that are always bad.
Re: What's wrong with software development in large corporations
I'm aware of the Mythical Man Month. That book was first published in 1975 and as I can tell based on personal experience as a consultant who gets to compare several of those large corporations not much has changed.
But yes a blog post is not the same as a well researched book or magazine article. It's just personal - isn't it? Is it bad because of that? I guess it's not, as it allows to add another aspect, another opinion, another experience to the great books that are available.
To be treated as a Master Architect
To be treated as a Master Architect
I remember one of those telling me that he gets called frequently into the office of his boss where he gets to hear the same lecture over and over again. They are happy with his achievements but constantly remind him that they expect him to play by the book because the organization were large and the same rules apply to everybody and so on. This is about things like talking directly to technical people in other departments instead of going through committees exclusively or speeding up the process of enabling access to source repositories for new team members.
Although it is unrelated to software development but very well shows the effect of going the extra mile or not is what is currently happening with the pilots for the Panama Canal. Apparently by going back to play by the book they managed to build up a backlog of about 100 ships in just one month. Given that the canal has a nominal capacity of about 38 ships per day and they were operating at 42 with pilots coordinating things amongst themselves you can easily see the effect.
Organizations should frequently improve their processes for better throughput and a better work environment for their people. That what the term business agility refers to. Unfortunately many large organizations seem to attract a fair number of people who dislike change because they seem to feel more comfortable with the status quo for personal reasons.