Having taken a position with a firm that recently launched an Agile Development initiative, I have been giving a lot of thought to how software is developed.
First off, I will say that I don't hold out much hope for Agile. Every company has its own work culture which is entrenched and not easily shifted. Some may be ripe for accepting an approach like Agile Development but most are not. If Agile is launched an AVP with a memo and training program, just sit through the seminar and wait. It will go away just like Who Moved My Cheese.
More generally, I think we spend much too much time and effort in agonizing over organization and methods instead of producing quality programs. I don't mean we need test-driven development or a million test cases in the QA group. I mean that little attention is paid to the actual code that is produced. Is it efficient? Is it secure? Is it robust? Is it easy to understand and modify? I believe W Edward Deming said that the problem with management is that it reads too many management books and not enough statistics. Same with programmers. My last organization did a Lunch-and-Learn series on best practices in coding specific situations. It was nice. Most of what I see, though, is google-the-problem/copy-a-sample-from-a-blog/compile-the-result. And that is when they aren't trying to stay on the bleeding edge.
I have rediscovered an admiration for COBOL programmers. I have to assume that the senseless dash toward "progress" seen in Java programming circles is less an issue in COBOL, which is considered a dying computer language. These guys and gals receive a request or specification and then code a solution. End of story. No need to impress anyone with the latest framework, there.
I read a comment thread recently which mentioned the "80% of anything is crap" rule with regard to programmers. Why don't we attack this statistic by attempting to make that crap a little less aromatic? What we need is a movement to improve the quality of programming by teaching theory and best practices. We all know that well written code is less prone to errors. But do we pay any attention to coding? No! We spend most of our time talking about patterns and pair-programming. Perhaps with enough theory and programming philosophy, developers might recognize that moving something from the Java source file to an XML file does not reduce the code, it merely translates it into XML. Or that using JUnit increases your code-base because your test modules are programs too that may need to be tested themselves.
I have been a programmer my entire working life but I trained as an engineer. I often wonder when will the time come when software "engineering" lives up to its name and drops the hacker culture and becomes a true discipline.
Tuesday, October 19, 2010
Friday, October 15, 2010
Code Smell
Can I count any Java class with the string "Util" in its name as smelly code? Helper classes, utility classes, they all scream. "I am Not Writing Object Oriented Code!"
Wednesday, October 13, 2010
Speaking of Protocol Droids ...
In my previous post, I might have inferred that protocol droids are annoying. If that is the case, then: Good. That is what I meant .
In reflecting on this further I remembered a train of thought shared back in the misty past of this blog: is it possible to create artificial intelligence without designing in some level of artificial neurosis.
I realize that C3PO's function in Star Wars is as comic relief. His quirky personality might be further justified by the fact that he is indeed a homemade droid built by Anakin Skywalker (in the heretical Episode 2 - or was it Episode 1 - who cares!) . I choose to think that C3PO's sometimes role go between for machines and people has required that he be designed to understand the weird thought processes of the human side of this transaction.
To be sure, C1PO was quite conversant in the binary language of moisture evaporators. Yet his designers (C# programmers no doubt) foolishly assumed that human communication could be achieved following the same simplistic assumptions required to understanding the ramblings of Obi Wan's toaster.
C2PO proved completely inadequate to deal with even the sarcastic utterances of an R2 unit. Only when the development team (having ditched Agile Droid Development in favor of actual forethought) watched the home movies of Anakin hiding his Halloween candy from Leia did they fully appreciate the possibilities of cyber-paranoia.
In reflecting on this further I remembered a train of thought shared back in the misty past of this blog: is it possible to create artificial intelligence without designing in some level of artificial neurosis.
I realize that C3PO's function in Star Wars is as comic relief. His quirky personality might be further justified by the fact that he is indeed a homemade droid built by Anakin Skywalker (in the heretical Episode 2 - or was it Episode 1 - who cares!) . I choose to think that C3PO's sometimes role go between for machines and people has required that he be designed to understand the weird thought processes of the human side of this transaction.
To be sure, C1PO was quite conversant in the binary language of moisture evaporators. Yet his designers (C# programmers no doubt) foolishly assumed that human communication could be achieved following the same simplistic assumptions required to understanding the ramblings of Obi Wan's toaster.
C2PO proved completely inadequate to deal with even the sarcastic utterances of an R2 unit. Only when the development team (having ditched Agile Droid Development in favor of actual forethought) watched the home movies of Anakin hiding his Halloween candy from Leia did they fully appreciate the possibilities of cyber-paranoia.
Labels:
Agile Development,
Artificial Intelligence,
Droids,
Star Wars
Monday, October 11, 2010
I Need a Protocol Droid
"What I really need is a droid who understands the binary language of moisture evaporators." - Uncle Owen (Star Wars - The Real Movie)
Working in software development, I am continually inflicted with the latest open source scheme to transform the way we program computers. Someone in the organization decides that WidgetScam 2.1 will make waterfall, procedural, proprietary coding a thing of the past.
First off, there is some resume padding going on - software architects recommend to management the latest thing so that they can put it on their resume inspite of the fact that it will make the comopany no more productive or profitable. Relatedly, I believe that there is an ego factor whereby individual programmers need to feel like they are on the cutting edge. Me, I am old fashioned. I take pride in being a pretty good debugger and in being able to produce decent code that solves the needs of the customer (remember them?)
One amusing thing about this technological arms race is that we install all the new jars and dlls on our laptops and then keep programming the way we always have. Don't get me wong. I like programming in Java. It has some nice properties but Object Oriented Programming was sold as a complete paradigm shift in IT. Have you looked at any Java code recently? Most of it is dressed up C. Most programmers are writing procedural code in .java files. Of course, it works. It does what the specs require (most of the time) but there is no way that the advertised benefits of OO are going to realized.
So where are we now. I spend my days trying to install (and re-install, and re-re-install) software development tools on my cutting edge laptop all the while trying to balance my 64-bit vs 32-bit apps, the programs that require Java 1.5 vs those on 1.6 and the three different document repositories our company is using (Wiki vs network drive vs Alfresco). My industry is approaching the point where two systems will not be able to share information without an intervening layer that is more expensive, cumbersome and annoying than a protocol droid. Sometimes I wish we all just had R2 units. They aren't real shiny but they seem to get the job done.
Subscribe to:
Posts (Atom)