Best Practices
Listen to this article
I happened upon this post on the artima web site which reminded me that I had been wanting to rant a little about best practices for a while.
It has always seemed to me that so called "industry best practices" are really only ever identified at the end of a cycle of innovation. Or in other words, when many in the industry have moved on to developing "better" practices. My observation has been that companies striving to adhere to "best practices" are often at least 12-18 months behind the leaders.
Some (read large, conservative, glacial, etc.) companies take so long to adopt advances in technologies and methodologies, etc. that by the time they do, they're really using legacy* practices. They are highly risk averse. They can't, won't or don't employ talented developers. Instead they hire an army of over-paid whiteboard architects who couldn't build a software system if they tried. These whitebaord architects, with little or no understanding of what really goes on their own industry, need to protect their backsides by showing little or no innovation by promoting whatever methodolgy sees most of a projects time and budget justifying their employment and ensuring there is always someone else to blame if/when something goes wrong.
Now, don't misunderstand me. I'm, in no way suggesting you jump on the next AOP, IoC, whatever wagon that rolls into town. But don't be fooled that simply automating manual processes or creating a web site (inter-, intra- or -extranet) will suddenly make your business more efficient. We should be striving to deliver high-quality, adaptable systems that allow the business to realise competitive advantage as early as possible.
* For clarification, I'll define legacy to mean anything that clearly doesn't work to all but the people who try so hard to believe that it does not least because their jobs probably depend upon it. A kind of managed failure. As a reader suggests, if it works, it's not legacy.
Comments
The converse is our profession is incredibly fad-ridden. If the olympics held competitions in bandwagon jumping, programmers would be the winners by a long way.
Most programmers have no knowledge of any technologies older than when they entered college and treat anything that's not the latest fad as "legacy". That's why we see so much reinvention of the wheel. Take IoC for example. That's just object oriented programming, but given a new name. The only people who for whom IoC is some kind of revelation are those who didn't understand object orientation in the first place.
The idea of legacy is mostly marketing bullshit. If a system works, it's not legacy. The problem is programmers who cannot learn different ways of doing things, and punt the blame onto the age of the technology instead of their own incompetence.
Posted by: Anonymous | December 26, 2003 08:11 AM
Anonymous--> There is a difference between what can work and what works. I can make a series of dos batch files take care of some of my backend integration needs. It may work for one feed. It may work for a couple, but basing this as your company's backend is downright scary.
However it doesn't work because that batch files are unaware of the success or failure of another component. There is no error logging, so detecting/repairing a failed feed is impossible. Testing is impossible since connection strings and drive mappings are hard coded. Therefore its also impossible to run just one feed.
(our company had a system like this).
It actually works 90% of the time. However, I don't consider that working. Adding a new process into this system is a nightmare, since there is no test enviroment. And error prone since the batch files get bigger(you have to remember to edit 5 of them). If you make a mistake it could mess up all the feeds.
I was originally written by a Buisness Analyst( retired cobol programmer), for one feed because the developers were busy. The BA probably had no buisness coding in the first place. However, it was later handed off to a junior programmer.
Now you have a system that is flat out scary, yet management does not want to spend the money to re-write it or purchase a real integration engine because it "works" (sometimes).
Posted by: Matt Payne | December 26, 2003 10:44 AM
I have to say The whole IoC, AOP whatever thing really gives me the shits. As you say, like it's some kind of revalation. I never went to college. I started my careeer as an assembler programmer in 1987 and it's always amused me that way back then with none of this fancy OO stuff, we wrote code that branched through what we called "jump vector tables" to achieve pretty much the same thing as method overriding and overloading. So I couldn't agree more. But then, of course, you have the so called core J2EE patterns which IMHO are largely workarounds with a fancy name as well. When it comes down to it, you need good people who understand how to build software not a bunch of technology / methodologies that somehow tries to make up for a lack of the former. I'm constantly frutsrtaed by the lack of real innovation in our industry. We do keep re-inventing the wheel which is why I feel we need to forget about "best practices" and do whatever we need to start actually adding value instead of justifying our existence by assuming that if it's in software, it must be good for business.
Posted by: Simon Harris | December 26, 2003 01:53 PM