In this interview with Artima, CipherSoft's Jennifer McNeill explains why adhering to standards is important in ensuring application longevity, and why developer curiosity can make it harder for applications to take advantage of future technologies:

http://www.artima.com/lejava/articles/javaone_2007_jennifer_mcneill.html

How do you balance your desire to try and learn new things while also sticking with the beaten path of standard tools and technologies? And how does your company manage the tension between keeping developers stimulated with new environments and tools, while also keeping them focused on the tools and technologies that they need to work with each day?

This is exactly the kind of nonsense that makes IT such a boring field these days.

How many thousands of hours need to be wasted on bad approaches in order to make it easier to save time on something that may or may not be needed? If I find a tool or create one that cut development time and maintenance down by a factor of 10, I should not do this because we might want to spend even more money on some tool to migrate to some other abhorrent standard in the future. Standards can be great but to use something that is not working out just because you might want migrate to something else later is stupid.

This idea that there are some brilliant standards-writers over in some ivory tower that will hand down 'the way' to do things and everyone else will do only those things is a totalitarian concept. It's completely incompatible with a Darwinian 'survival of the fittest' model.

Good standards are based on things that already work. If everyone followed what Jennifer McNeil says, this would be impossible. Standards that are based on theory are almost always inadequate and often are hopelessly broken. EJB is a really good example of a basically failed standard. If it weren't for those rascal developers that picked up Spring an Hibernate, would EJB 3 be essentially a complete rewrite? Probably not. It'd be more of the same old crap, just more of it.

Personally I think CipherSoft should work on the apparent inadequacies of their tool instead of blaming those who are making things happen and not waiting around for someone to tell them what to do. This argument is self-serving and the advice dubious.

Let me admit upfront that I have not listened to the interview. If she illuminated what is meant by standard tools and technologies, then I'm not aware of it.

I would like to know what is meant by standard? Is "standard" being used synonymously with "currently en vogue"? Our field changes rapidly enough that standard loses some of its meaning. I remember when the standard 4GL development tools for GUI's were Powerbuilder and Gupta's SQLWindows. Are they still? Are the two-tier architectures they promoted still standard? These tools were the standard at a time when Windows development was really difficult. (Maybe it still is but I'm almost exclusively UNIX side now.)

It seems to me that industries, in which technology gives competitive edge, need their developers to be a little more experimental. If technology isn't a differentiator in your industry, then following the bell-curve of adoption is a smart choice.

More to the first question, my own need to see what I develop being used keeps me from trying "cool" things when projects are on the line. In my spare time, I try out different languages/tools and read as much as possible from ACM and IEEE's periodicals.

The client I am contracted to seems to manage the tension by ignoring it. (Our tools' version is about 10 years out of date.) They stay behind the curve and make the working environment "cushy" enough that people who have a lower need for stimulation stay and those with a higher need leave.

> Let me admit upfront that I have not listened to the
> interview. If she illuminated what is meant by standard
> tools and technologies, then I'm not aware of it.
>
> I would like to know what is meant by standard? Is
> "standard" being used synonymously with "currently en
> vogue"?

Not that standard. Standard as in 'official'.

"Our recommendation to clients when they start developing in Java is to use as many of the Java standards as possible."

Taken out of context, it sounds really stupid but her point is that you should stay in the lines, so to speak. Don't got out and use framework X unless it's been blessed by a committee and given an acronym.

> The client I am contracted to seems to manage the tension
> by ignoring it. (Our tools' version is about 10 years out
> of date.) They stay behind the curve and make the working
> environment "cushy" enough that people who have a lower
> need for stimulation stay and those with a higher need
> leave.

How is that working out for them? I kind of have my doubts about the 'employ people with lazy minds, buy gobs of software without a clear understand what problem it solves, and have a river of consultants, contractors and outsourcers flowing through the organization all leaving their marks on your system' strategy. Everywhere that I've seen this done progress grinds to a near halt as things become completely incoherent and unmaintainable.

> Not that standard. Standard as in 'official'.
>
> "Our recommendation to clients when they start developing
> in Java is to use as many of the Java standards as
> possible."
>
> Taken out of context, it sounds really stupid but her
> point is that you should stay in the lines, so to speak.
> Don't got out and use framework X unless it's been
> n blessed by a committee and given an acronym.

Thanks for the clarification. Teaches me to throw on a pair of headphones (I'm in a cube farm) and listen from now on.

I can agree with her to a certain point. I wonder if taking that mindset can stifle innovation? (Of course, this begs the question "Is innovation important to all companies?")

> How is that working out for them? I kind of have my
> doubts about the 'employ people with lazy minds, buy gobs
> of software without a clear understand what problem it
> solves, and have a river of consultants, contractors and
> outsourcers flowing through the organization all leaving
> their marks on your system' strategy. Everywhere that
> I've seen this done progress grinds to a near halt as
> things become completely incoherent and unmaintainable.

If you look at it from a pure dollars standpoint, the company is doing well. (Of course, it's going through a growth by acquisition stage, so I'd caution judgment on its financial health until all the costs have been paid.) From an IT standpoint, the systems are definitely not extensible and are hard to maintain. Fortunately (read with sarcasm), they've solved this problem by taking a "buy" approach and just having developers create reports and provide "glue" code. Everything is pretty much a stove pipe application.

> I can agree with her to a certain point. I wonder if
> taking that mindset can stifle innovation? (Of course,
> this begs the question "Is innovation important to all
> companies?")

I completely agree that standards are a good thing. I'm not going to try to connect across a network without using TCP/IP. But sometimes restricting yourself to a standard can be outrageously expensive and produce poor results.

The most annoying thing about this is that it falls back to a completely ad hominem argument that developers that don't follow the standard are just loose cannons that must reined-in. I am completely convinced that a lot of the conventional wisdom in IT is dead wrong and will be scoffed at a few years out.

> If you look at it from a pure dollars standpoint, the
> company is doing well. (Of course, it's going through a
> growth by acquisition stage, so I'd caution judgment on
> its financial health until all the costs have been paid.)

I've worked at a couple places that follow this and it always seemed to me that the incidental costs of things not working properly or creating more work for others in the organization were never accounted for in these costs. For example, ITs budget might have gone down 1 million but we lost 2 million on improperly placed orders, 6 million from hackers, and another 5 from lost business. IT should never be a net cost. If it is, it should be fixed, not made cheaper. I mean, saving money is good and you shouldn't waste money but I see so much penny wise, pound foolish decisions it makes my head spin. Somehow it makes sense to have one hundred people spend 2 hours a day doing data entry for years than to have one developer spend a month or two writing some custom code.

> From an IT standpoint, the systems are definitely not
> extensible and are hard to maintain. Fortunately (read
> with sarcasm), they've solved this problem by taking a
> "buy" approach and just having developers create reports
> and provide "glue" code. Everything is pretty much a stove
> pipe application.

Oh, you work here? Where do you sit? We are going to solve this with an integration architecture. We'll buy something for that too. It's amazing how much it costs to save money.

> I completely agree that standards are a good thing. I'm
> not going to try to connect across a network without using
> TCP/IP. But sometimes restricting yourself to a standard
> can be outrageously expensive and produce poor results.
>
> The most annoying thing about this is that it falls back
> to a completely ad hominem argument that developers that
> don't follow the standard are just loose cannons that must
> reined-in. I am completely convinced that a lot of the
> conventional wisdom in IT is dead wrong and will be
> scoffed at a few years out.

It's funny too that (I believe) developers like standards because standards help to reduce variability in situations when variability is not desirable or helpful. We just don't like them to squash our ability to make what we develop better. However, we've become stereotyped as cowboys in the wild, wild, west. Maybe developers newer in the field are a little more daring, but after you've had to sleep in your own littebox a few times you develop an appreciation for caution.

Maybe I'm a little cynical, but I think a lot of the conventional wisdom is someone pushing an agenda. "Time is the only true test." This quote from my English teacher in high school has stuck in my mind. Hopefully good ideas will outlast the lousy ones in our field.

> It's funny too that (I believe) developers like standards
> because standards help to reduce variability in situations
> when variability is not desirable or helpful. We just
> don't like them to squash our ability to make what we
> develop better. However, we've become stereotyped as
> cowboys in the wild, wild, west. Maybe developers newer in
> the field are a little more daring, but after you've had
> to sleep in your own littebox a few times you develop an
> appreciation for caution.

There are cowboys out there, no doubt. But to have a knee-jerk reaction and say "I'll never trust another developer again!" is a little foolish, IMO. The funny thing is that it seems like the real cowboys are the 'superstars'. You know, the ones that finish everything early because they didn't bother to add any error handling or do any testing.

> Maybe I'm a little cynical, but I think a lot of the
> conventional wisdom is someone pushing an agenda.

Absolutely there is no question. A lot of this stuff comes from vendors. Who do you think pays the bills at CIO magazine?

> How do you balance your desire to try and learn new things
> while also sticking with the beaten path of standard tools
> and technologies?

I have generally found that the simpler a standard, the more likely it is to have enduring value. So for example, stuff in java.util tends to be very useful, and worth sticking with. In J2EE, it starts getting dicey. While some of the more "primative" portions, such as JMS and JDBC, seem to have stood the test, much of the more elaborate standards have a bit of a flavor of the month nature to them. The industry tends to do a good job of solving small problems, but a poor job of providing universal solutions for large domains such as web development.

What this tends to mean in practice is that the more important a problem is, the more likely you will want to consider going with the "best" option, instead of the "most standard" one. A poor fit in web technologies is fine if you are writing a quick web app to expose monitoring data; it can be disasterous if you are writing a revenue-producing web site.

> And how does your company manage the
> tension between keeping developers stimulated with new
> environments and tools, while also keeping them focused on
> the tools and technologies that they need to work with
> each day?

I've found that letting developers dig in deeply to a smaller set of technologies (even something as core as java.util.concurrent) often leaves them more satisfied than "mastering" something like JSF which will come and go.

> There are cowboys out there, no doubt. But to have a
> knee-jerk reaction and say "I'll never trust another
> developer again!" is a little foolish, IMO. The funny
> thing is that it seems like the real cowboys are the
> 'superstars'. You know, the ones that finish everything
> early because they didn't bother to add any error handling
> or do any testing.

Or the cowboys who jump on a project using the latest and greatest technology only to produce a pile of junk, pad their resumes, and leave before having to live with their junk? You know, the ones who are sort of like contractors/consultants only less honest.

I listened to the interview finally. Her company has a product that migrates legacy applications into standard Java. She states that the biggest problem her company faces is from legacy applications in which developers didn't follow standards. I have no problem if she acknowledges it as a problem, but she goes on to make the developers seem like kids with no sense of the "Big Picture". The situations I've seen - and this is a study with a poor sampling - in which developers don't follow a standard occur when a standard hasn't been set and a solution to a problem is required by the business. (It takes a real novice to get distracted by "cool" at the expense of the application IMHO. Which is why you want senior, experienced developers leading teams in a project.) At a hospital I worked for, another developer and I were converting a legacy app. into a Java one using JDK 1.0x. He took care of the GUI stuff while I did the server and database stuff. At one point, he spent some time writing print routines because the AWT didn't handle what the users required. There was no standard (or at least not a well-formed one) in that case but the doctors and nurses we wrote for needed a solution. Would some tool of the future converting this future legacy application to some language of the future have a problem with his routines? Perhaps. What he did was right at the time. You can argue that when a standard has been formed then the routines should be swapped out for ones that fit the standard, but that's a business decision.

> > There are cowboys out there, no doubt. But to have a
> > knee-jerk reaction and say "I'll never trust another
> > developer again!" is a little foolish, IMO. The funny
> > thing is that it seems like the real cowboys are the
> > 'superstars'. You know, the ones that finish
> everything
> > early because they didn't bother to add any error
> handling
> > or do any testing.
>
> Or the cowboys who jump on a project using the latest and
> greatest technology only to produce a pile of junk, pad
> their resumes, and leave before having to live with their
> junk? You know, the ones who are sort of like
> contractors/consultants only less honest.

Well I'm working on some code that went exactly like that. The biggest problem doesn't seem to be the use of tools even though apparently the only requirements of the design were to use two new frameworks. The real problem is that the code sucks. If I could get it working smoothly the way it is, it would be a lot easier to enhance it and perhaps move it away from one of the frameworks that is a liability. According to everyone I talk to, this developer was a boy-genius. I look at the code and I don't get that impression. In fact, almost every piece of code written by a 'golden boy' (or girl) has been amateurish at best. Some of it is just downright bad. I had to work on some code by what I was led to believe was one of the greatest programmers of our time and the guy hadn't put in any error handling. He was inserting into a queue and not checking whether it succeeded. Not only was the event source not checking for the error, the code that did the push to the queue was not capturing and returning it. The queue could be completely unavailable and this code returned a success code. These were not messages that were nice to have. Losing them (which we were) was not acceptable and caused serious problems throughout the enterprise. But this guy was considered awesome, given administrator access to production servers, and was exempt from code reviews. I see this scenario played out again and again. And the people charged with cleanup are treated like slow dunces. It's depressing.

> Well I'm working on some code that went exactly like that.
> The biggest problem doesn't seem to be the use of tools
> s even though apparently the only requirements of the
> design were to use two new frameworks. The real problem
> is that the code sucks. If I could get it working
> smoothly the way it is, it would be a lot easier to
> enhance it and perhaps move it away from one of the
> frameworks that is a liability. According to everyone I
> talk to, this developer was a boy-genius. I look at the
> code and I don't get that impression. In fact, almost
> every piece of code written by a 'golden boy' (or girl)
> has been amateurish at best. Some of it is just downright
> bad. I had to work on some code by what I was led to
> believe was one of the greatest programmers of our time
> and the guy hadn't put in any error handling. He was
> inserting into a queue and not checking whether it
> succeeded. Not only was the event source not checking for
> the error, the code that did the push to the queue was not
> capturing and returning it. The queue could be completely
> unavailable and this code returned a success code. These
> were not messages that were nice to have. Losing them
> (which we were) was not acceptable and caused serious
> problems throughout the enterprise. But this guy was
> considered awesome, given administrator access to
> production servers, and was exempt from code reviews. I
> see this scenario played out again and again. And the
> people charged with cleanup are treated like slow dunces.
> It's depressing.

Assuming you're the one who had to report the bad news about the boy genius' work, did you get a "Shoot the messenger" response? It seems like developers who can spin management heads with a lot of jargon and hit randomly set deadlines, regardless of code quality, get the warm-fuzzies from higher-ups. Everyone else might as well move to a leper colony.

This brings up another interesting point about standards. How do you follow standards closely when the company doesn't encourage its developers to do so or even to keep up with standards? People here don't get rewarded for following standards or good design. They get rewarded if they keep users from complaining to management. The message becomes: hit the users' deadline, make the data accurate, and any way of doing 1 and 2 is acceptable.