A few thoughts about what I think ails software development - as done in corporations - today.
- Writing ability. Ability to articulate. IT professionals that can't write a paragraph of coherent text if their life depended on it. Professionals that can't articulate a thought. This is not just "documentation", and lack of. Writing, and an ability to write, is an indicator of the sophistication of a software developer. Coding is a kind of writing. When you code in Java, you are expressing thoughts in Java. And if you can't express thoughts in English, chances are your Java is pretty mediocre too - but who is going to tell with Java? You keep hacking at it, till something works. Then some ugliness is foisted on generations to come. My test, when hiring developers, is how well they can articulate a thought - in writing. Mastery of your spoken language is an indicator. Check with Dijkstra.
- Innovation - or lack of. IT professionals that are uncreative implementation drones. Professionals that master implementation arts and techniques that are popular and fadish at the time - mostly by copying and imitating without much alteration. They excel at the mechanics of coding and testing, but have no imagination to create new things.
- Workplace fear and apathy. Professionals that are afraid of expressing a thought at work, or voicing an opinion. Managers that discourage expressions of ideas that "rock the boat", or are not "the way we do it around here". Managers that go around telling teams that debating an idea via email is "spamming" your team members!
- Online technical communities that are brain-dead, and paralyzed by workplace fear (see above), where most postings are of the variety of "here's a link", or "go team", or "congrats to Zoltan - he submitted his report to the excellence committee on time", or "go carting last week was awesome - the winner of the supreme prize is Yakapuk". A blog posting, unlike a bulletin board announcement, is an expression of an opinion - of likes, dislikes, or evaluations. An online community needs debate to thrive.
- Anti-intellectualism. This sad, sad, phenomenon extends beyond IT departments and software development shops. It is an American phenomenon. It explains how a country as great as the USA can choose a president as dimwitted as George W. Bush - twice! Anti-intellectualism in the workplace exhibits itself in the dismissal of learning and studying as "book learning", or "not real-life".
- Mediocrity. Acceptance of the lowest of standards - that on the surface meet the requirements. "Framework" projects that are not clear what a "framework" is, or worse, redefine "framework" to be anything some committee would live with - and not find objectionable. "Framework" is just a word. Don't get hung up on words! A process of "Component Based Development", that defines "component" to be "anything we say a component is". Humpty-Dumpty word usage, and Alice in Wonderland standards. Mediocrity accepted and embraced.
- Knowledge of the fundamentals. Software architects who don't know what architecture means, or can't articulate it. The fundamentals of describing multiple views and multiple models. Basic diagramming techniques - above all clear free-hand drawings of conceptual architectures. Designers and developers and managers that don't know what a domain model is. Developers and designers that don't know what patterns are, how you develop to them, how you refactor to them. Managers that require refactoring to be budgeted separately as a phase. Professionals and managers that don't know what a design contract means, and think it is something "too academic" to look into, or that Design By Contract is "asserting out early", as a high level executive keeps repeating to everyone that is at his mercy. Designers and developers that claim they do Object Oriented Development, yet don't know what an object model is. Developers that don't know the fundamentals of UML, and think it is "Too complicated". They delight in repeating that "in agile methods, code is design". Finally, a lifesaver for the lazy. Database developers that snicker at object developers. Object developers that snicker at data models. And lastly developers that don't know what the word "requirements" mean. How do you articulate them and describe them. How do you know when they're good and sufficient to start developing from. How do you know which are architecturally significant, and which are not. "Requirements" miraculously come from the sky, way on high, and of course, they must be perfect, or everyone whines.
- Fadism. People thinking that whatever they just learned is a "paradigm shift". That today's fad is the silver bullet for all that ails us. SOA of course now is the king of the hill in "paradigm shift" land. You must know how to talk about "the bus". I saw a presentation that actually described the services bus as a metaphor based on a school bus (totally missing the point that the "bus" in question is derived from the electrical power distribution bus that is a universal interface connector).
- Complexity. Or the flip side of it, lack of understanding of simplicity. A deadly underestimation of how complexity can stifle and thwart. A simple minded understanding of what simplicity means. A dismissal of efforts to define and harness simplicity.
- Sloganeering Executives. High-level
executives that don't understand their own slogans - or what it would take to make the slogan a reality. "Outrageously Great
Software", they declare. Then, three months later, move on to another
slogan, "Insanely Great Scalability", then, "Recovery Oriented
Computing", then, "Fail Fast Computing", then, "Five Nines of
Reliability", then, "Design By Contract", then, ...Musical slogans game. Gets the executive in the press.
- Incompetent Managers. Managers who are task masters, not thought leaders. Managers for whom the task due date is more important than the task content. Managers who extol the virtues of high productivity, then suffocate it by the way they define and measure it.
Pretty good list.
But some of the points are subjective.
Point (1): Writing ability: google hires people who think the code is documentation enough while a defense contractor might want everything documented and the documentation may be 3 times as large as the code itself. Both approaches seem
to work well for the respective companies.
Point(3): Workplace fear and apathy: Google encourages it and thrives on it. A defense contractor usually is process oriented and averse to risks. Both do reasonally well in their work.
more later,
Posted by: Swamy Karnam | March 02, 2008 at 12:49 PM
Thanks, Swam, for the comments.
All the points are subjective - I filed this under the category, "My Soapbox". Unfortunately the category does not show, unless you get to the blog post through the category link. Then it is clearly marked, My Soapbox.
Re point (1), I am not talking about writing documentation. I am talking about writing ability as an indicator of development ability.
Also, I am not requiring that people write documentation. I am requiring that people have the ability to write - which may show in their ability to code. But it generally exhibits itself in the overall quality of their work. Poor writers will be poor developers. All their work products will be poor.
Re Point (3). I doubt that Google encourages workplace fear and apathy. You probably meant to say they encourage active participation in online technical communities. I don't see why process orientation would contradict an exchange of technical ideas free of workplace fear. The point of postulating a special case for a defense contractor implies that you have security concerns or IP (Intellectual Property) concerns.
A professional writer, blogger, or technical community contributor is fully aware of security and IP issues of his employer - that's part of what makes a professional a professional. I am not assuming amateurish, irresponsible people, or people working for Giant Food IT Department only. Debate about technical issues and ideas can proceed with full protection of what needs to be protected.
Posted by: El Profesor | March 02, 2008 at 01:11 PM
Great list.
I would agree with all the points, with some additional thoughts:
- Writing - I would go so far as to say that the average IT professional has no interest in writing well and often chooses IT as a career thinking they won't have to write. This is reinforced by CS programs that don't push a significant writing component, as if it isn't a key skill for any career.
- Managers - I think a large part of the problem with IT managers comes from how we promote. We take a perfectly good engineer who is happy doing what they do and think that the only way to reward him/her is to make them a manager, a position they're frequently woefully unequipped to handle. The end result is either the creation of a bad manager or a causative factor in the person leaving the company.
I look forward to more posts.
Posted by: Nick Klop | March 02, 2008 at 07:19 PM
Great post, Nabil! Everything you say here resonates in the academic health center world as well. We suffer the additional curse of not having profitability as a measure of success, which means there is no natural weeding process to root out the incompetent managers and the sloganeering executives. The profit motive is imperfect at best, but having witnessed life both with and without it, I am convinced it's the closest thing to natural selection in the realm of organizational culture.
Posted by: Dale Hunscher | March 03, 2008 at 05:50 AM
At least I won the go cart race!
It is true that a pre-law English major should be a more articulate writer than the average CS graduate.
I think it is possible for a person that is not a native English speaker to write very correct and elegant Java code and not be able write a particularly decent set of comments or documentation much less a coherent paragraph....
With regard to being an American phenomenon - perhaps. I did some work for a small German company and everybody (marketing, engineering, product development) knew their product domain and generally had a good grasp of the technology that was part of their domain. I don't see that in a lot of large US companies but that may be related to other aspects of a company like the culture or its size.
My world view is that people will generally prosper and make better decisions if those decisions can be kept at a local level. I think that is true of software development as well as the decisions at the ground can best be made when developers can innovate.
Having said that - it would appear that management will add process (CMM, etc.) to the mix if they are trying to gain better predictability into their scheduling which does two things: 1) Protects against poor/unskilled developers (or is at least supposed to). 2) Prevents very talented developers from excelling (Your Mediocrity item is relevant here). Call it corporate software development socialism where everybody performs to the same mediocre level.
Posted by: Cory | March 03, 2008 at 11:18 AM
Hi Nabil,
W.r.t to point (3) Yes I did not mean Google encourages work place fear and apathy but just the reverse. Thanks for catching that.
W.r.t to point (1) I am not sure that being good at writing also implies being good at developing code or cooking butter chicken :) They are all separate skills. The only common denominator between a writer and a coder is that they both use a keyboard. A writer is writing something to convince other humans or evoke some emotion out of them. A writer can add past experiences, relate stories, add case histories and other tools to make his or her case better. A developer has to mostly convince the compiler and some humans. Most compilers do not care about past experiences, stories etc. I guess there is this notion of left brain/right brain and based on it I would guess that a writer uses the opposite side of the brain most of the time to what a developer would use.
Yakapuk (oops, I mean Cory) congrats on winning the go kart (cart) race.
I never heard of the term "corporate software development socialism". Interesting thought and I am sure socialism and mediocrity are somewhat related. Maybe communism and mediocrity are also related.
Posted by: Swamy Karnam | March 05, 2008 at 11:23 PM
Being good at writing of course does not imply being good at writing code. I don't expect Ernest Hemingway to be a good computer programmer. The reverse is what I am claiming. A programmer that cannot write cannot program. Programming is a kind of writing, a subclass. That does not say all writing is programming. It says all programming is writing. This is classic inheritance. You cannot just turn the hierarchy on its head. A programmer who is a poor writer is a poor programmer. It is easier to spot poor writing. Much harder to spot poor programming. That is all I am saying. They are not separate skills.
Posted by: El Profesor | March 05, 2008 at 11:34 PM
Re Cory's points.
I find it hard to stay with Cory's tangents. But I'll try.
1. A pre-law English major should be more articulate than a CS major. If granted, would be irrelevant, but I don't grant it. Why isn't a CS major expected to be articulate? What is the point being made here? Perhaps the second paragraph makes the point.
2. "It is possible for a person that is not a native English speaker to write very correct and elegant Java code". It is not English that is the point of this connection between writing and coding. If the person, say, is German, I contend that he would be a good writer in German, in his native tongue, if he is a good coder. There is a very strong connection between writing ability and coding ability. Not necessarily in English - in the person's native language. Ability to articulate thoughts is the common element - not knowledge of English. Programming is the implementation of metaphors, and patterns. A programmer that has no imagination will not be articulate enough to write, or program. That is the major contention. He will merely copy and emulate - mainly method by method, and produce pretty mediocre work. I still contend that a good German Java programmer, will probably be a good writer in both German and English - not a necessary connection - but highly likely.
3. What I said was an American phenomenon was anti-intellectualism, not the general state of poor software development, that is universal malaise of our profession - happens in Australia, Germany, and Sweden, just as much as it happens in America. So I still don't get this second tangent.
4. People prosper if the decisions are local. Yes, Ok. What is the point being made here? Decisions are usually local, to a project, to a team, to an application, to an enterprise. When were you, as a developer, subject to making global decisions? So I don't get this tangent either.
5. Adding process produces socialism and mediocrity. Hmmm. There maybe something to that. Not sure. Seems clever, but dubious. I think there is a place for process. Whenever a group of people work together, you do need process. Visit California Pizza Kitchen, or Sweetwater's Kitchen, and observe process at work. Can be a beautiful thing. No. Don't get this tangent, either. Other than a dig on socialism, I don't agree that process produces, necessarily, mediocrity. Mediocre leaders, mediocre talent, and mediocre minds produce mediocrity - not the process.
Posted by: El Profesor | March 06, 2008 at 12:42 AM
Thought-provoking post.
Everywhere I've been I hear that the workforce is very smart. And I heard the same in engineering school, and usually about people's relations. Of course the fact is that our associates are very average ... realistically, for all the talk of entrance criteria, I don't see how the average IQ in any reasonably large company can much exceed the mean.
But workers in different organizations can be significantly more motivated and performing.
Thus, many of the things you criticize, such as zeitgeist, sloganeering, vapid conformity -- while repugnant to your personality or intellect -- might be the very trick to get your group of average folks marching in a preferred direction with right purpose etched upon their faces. I don't know, but I've got to suspect that's what's behind it. I've never worked at a level where much subterfuge is required.
Posted by: Scott Courtney | March 06, 2008 at 08:47 AM