Problems of Corporate Software Development Today

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.

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.