> 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.

There's always been these sorts of problems, but what makes it worse now is the way standards are being developed.

In the old days standards codified existing practices and those practices grew organically from solving real problems.

Today standards are just as likely to come from organizations who are not in the business of solving the problems they're developing solutions for. How different would J2EE be if Sun's core business was developing enterprise software?

Using a standard solely for the sake of using a standard really only makes sense when it comes to ineroperability: I might hate SOAP, but it's standard enough that exposing a remote API as SOAP instead of via some other, proprietary mechanism makes sense. Other than that, all bets are off, and I think standards should really only be used if the fit the application's needs. JSP and JSF are "standards," but if some other web framework is more appropriate to your development needs you should use it. And if there isn't anything out there that meets your needs, then build something that does. That's not cowboy-coding, it's just common sense.

There's naturally some value in using standards when it comes to the availability of tooling, the ramp-up time for new developers, and maintainability, but those are simply inputs into the equation and not trump cards. Perhaps I'm just being naive, but trying to design now with a future platform migration in mind is insanity: any predictions you attempt to make about what will make future migrations easy are almost guaranteed to be wrong. Thinking a little up front about application longevity and not painting yourself into a corner are always good, but making decisions that cost extra time, effort, and complexity now on the basis of some potential, unknown event 10 years out is just not a good idea. Developers will always complain about the earlier developers and managers will always complain about developers, and that's just kind of something you have to accept; what seemed like a good idea five years ago looks idiotic today, but if you obsess too much about what will look good in five years you'll never get anything useful out the door. Fashion always looks ridiculous in hindsight, and so do technology decisions; maybe you get lucky and create something timeless, but probably not.

I think the Java community in general has a serious problem with fetishizing standards for the sake of standards, as if some idea or piece of code isn't professional or valuable if it hasn't been blessed by some standards committee and given an acronym, and it really gives the whole language and community a bad rap. Most of the innovation in any language comes from outside the standards, and you should always use the right tool for the job whether or not it's been standardized.

> 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.

I was/am new so I'm easing in. But it's something I'm going to bring up at the right moment. I don't want to embarrass the people that gave him all this power but I do want inhibit the growth of new golden boys.

No matter how great I am, I don't even want to be the golden boy running around with no leash. I think that's bad leadership and being a bad team member.

I've actually talked about two different golden boys in this thread. Just to be clear. I've got more golden boy stories if you want to hear them. They are all pretty much the same, though.

> Using a standard solely for the sake of using a standard
> really only makes sense when it comes to ineroperability:
> I might hate SOAP, but it's standard enough that exposing
> g a remote API as SOAP instead of via some other,
> proprietary mechanism makes sense. Other than that, all
> bets are off, and I think standards should really only be
> used if the fit the application's needs. JSP and JSF are
> "standards," but if some other web framework is more
> appropriate to your development needs you should use it.

Total agreement. I like that I can drop a web project on Jetty, or Tomcat or WebSphere and it works pretty much the same on each one. But if it were really difficult to build the web project in order to do this, it wouldn't be worth it to me.

> I was/am new so I'm easing in. But it's something I'm
> going to bring up at the right moment. I don't want to
> embarrass the people that gave him all this power but I do
> want inhibit the growth of new golden boys.

Being right and employed is better than being right and unemployed any day! Pick you moment.

> No matter how great I am, I don't even want to be the
> golden boy running around with no leash. I think that's
> bad leadership and being a bad team member.

Agreed.

> I've actually talked about two different golden boys in
> this thread. Just to be clear. I've got more golden boy
> stories if you want to hear them. They are all pretty
> much the same, though.

I'd appreciate hearing them but it would drag this forum too far off topic.

> There's always been these sorts of problems, but what
> makes it worse now is the way standards are being
> developed.
>
> In the old days standards codified existing practices and
> those practices grew organically from solving real
> problems.

It seems like "the industry" is trying to take shortcuts by developing standards before problems are understood. Certainly there are classes of problems that repeat but do they also evolve such that they defy standardization after a certain point? Put another way, should we expect long-living applications to evolve through standards over their lifetime?

> Today standards are just as likely to come from
> organizations who are not in the business of solving the
> problems they're developing solutions for. How different
> would J2EE be if Sun's core business was developing
> enterprise software?

Excellent point. Should we be more careful with vendor-defined standards?