|
Posts: 135 / Nickname: fsommers / Registered: January 19, 2002 7:24 AM
Application Longevity
June 5, 2007 4:10 PM
|
|
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? |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: Application Longevity
June 6, 2007 9:06 AM
|
|
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. |
|
Posts: 12 / Nickname: ianr / Registered: April 20, 2007 6:37 AM
Re: Application Longevity
June 6, 2007 8:15 PM
|
|
> 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. |
|
Posts: 1 / Nickname: akeefer / Registered: February 28, 2007 9:08 AM
Re: Application Longevity
June 7, 2007 1:49 PM
|
|
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. |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: Application Longevity
June 8, 2007 5:34 AM
|
|
> 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. |
|
Posts: 28 / Nickname: billpyne / Registered: January 29, 2007 4:12 AM
Re: Application Longevity
June 6, 2007 10:05 AM
|
|
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. |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: Application Longevity
June 6, 2007 11:02 AM
|
|
> 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. |
|
Posts: 28 / Nickname: billpyne / Registered: January 29, 2007 4:12 AM
Re: Application Longevity
June 6, 2007 11:53 AM
|
|
> 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. |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: Application Longevity
June 6, 2007 0:39 PM
|
|
> 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. |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: Application Longevity
June 6, 2007 10:55 AM
|
|
> 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. |
|
Posts: 28 / Nickname: billpyne / Registered: January 29, 2007 4:12 AM
Re: Application Longevity
June 6, 2007 11:42 AM
|
|
> 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?") |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: Application Longevity
June 6, 2007 0:29 PM
|
|
> 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. |
|
Posts: 28 / Nickname: billpyne / Registered: January 29, 2007 4:12 AM
Re: Application Longevity
June 6, 2007 1:03 PM
|
|
> 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. |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: Application Longevity
June 6, 2007 1:22 PM
|
|
> 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? |
|
Posts: 28 / Nickname: billpyne / Registered: January 29, 2007 4:12 AM
Re: Application Longevity
June 7, 2007 6:54 AM
|
|
> 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. |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: Application Longevity
June 7, 2007 7:46 AM
|
|
> > 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. |
|
Posts: 28 / Nickname: billpyne / Registered: January 29, 2007 4:12 AM
Re: Application Longevity
June 7, 2007 9:42 AM
|
|
> 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. |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: Application Longevity
June 8, 2007 5:29 AM
|
|
> 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. |
|
Posts: 28 / Nickname: billpyne / Registered: January 29, 2007 4:12 AM
Re: Application Longevity
June 11, 2007 5:40 AM
|
|
> 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. |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Application Longevity
June 7, 2007 10:35 AM
|
|
> 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? |
|
Posts: 28 / Nickname: billpyne / Registered: January 29, 2007 4:12 AM
Re: Application Longevity
June 11, 2007 6:00 AM
|
|
> 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? |