Slashdot Mirror
Software Fashion
fedor writes "Software fashions come and go, but they always claim a few victims on the way. Where there's fashion, you'll find that rather weak willed person who is the Stupid Fashion Victim (or the SFV for short).
This great article from Software Reality is all about fashion in software. Do you all remember WAP? In a couple of years some of the current 'technologies' will be gone too. The article mentions VB.NET, struts and XP as current fashion..."
It's good for a lot of situations, but it's the most overused framework I've ever seen.
Rick
In the pro community of linux, I've seen the fashion of linux distributions.
.deb format. Rpms and Ebuilds are the new fashion!
First it was Slackware, then Debian and now Gentoo. Now that Debian has lost around 90% of its market share it is being left out to dry with its anceint packages and deprecated
Whats next? Ive recently seen a rise in Mandrake cooker users, as they provide the ultimate in ease of use combined with the power.
Hungarian Notation., the fashion of obfuscating your code.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
.NET will disappear once Microsoft starts pushing their next initiative and forces upgrades and rewrites. It's all about the $$$, never about the product. The product is just a conduit for money.
This is why OSS is so great. Most of the time, it's not about the money; it's about the product. Therefore, it's not about getting sales, it's about getting users.
But missed CORBA! Surely it belongs in the Technology X != Silver Bullet category. As far as I'm concerned, CORBA best solves the "this project has too many resources" problem.
But then again, I'm probably just another SFV :-)
DROS - Open-Source Robot Software
Don't you see? Moderating it as Interesting is a master stroke of comedy. It's the only thing which has made me laugh on Slashdot all day. Most of the other attempts to be funny here result in my wishing cancer upon the poster.
From the article:
That alone should tell you that the author has no clue as to what they are talking about. I am most definately not a VB.NET fan, but that statement is just false and shows a huge lack of understanding of the .NET Framework.
Forget the whales - save the babies.
I don't mean this to be flaimbait...so please hold off getting angry at me for just a moment.
But the article did describe (unwittingly) the OSS movement and Linux. There is a lot of hype out there(there is also a lot of substance too). There are a lot of people fueled by the desire to kill MS and others that happen to charge for their OS's. These will eventually burn out.
A business has a lot to consider when using Linux in their projects. Maintenance is one of them. I'm of the opinion that Linux is very Maintenance intensive when it comes to installing new things onto it. Once an installation has been stabilized...sure it works well for the long term. But it takes a fair amount of effort to get it there...at least now it does.
There is going to be competition. Vendors are going to work hard to improve their products to compete with Linux. Pricing structures will be affected. Linux isn't out of the woods yet.
Trolling a bit there - are they biting?
:)
I think their point on patterns is equally valid for UML, or TechnologyX in fact...
UML usage is often seen as an end in itself. Robin (intrepid co-author of this article) was once asked during a job interview: "What's your favourite UML Diagram?" What's the correct response to that? "Oh, Use Case Diagrams every time! Yeah, I use it for everything!"
However I think "Robin" should have read Joel On Software's Guerrilla Guide to Interviewing for the 'correct' response to that. If it was a smart interviewer, it wasn't a question designed to get an answer, but to elicit discussion about patterns and see if Robin really knew what they were and how to apply them. If they weren't a smart interviewer, and were really looking for an answer, then he/she is probably glad that the interview didn't go so well.
/* affect != effect */ void affect(int *thing,int effect) { *thing += effect; }
The biggest stupid software fashion is IT outsourcing--it has reached the point where every corporate middle manager feels they have to have a story on how they're outsourcing, long before (if ever) outsourcing has proven any reliable ROI.
Unfortunately, unlike other stupid fads applied to software such as TQM, ISO9000, RUP, etc., outsourcing does real economic damage to the victims, (as opposed to just the psychological damage represented by trying to work around the others).
Remain calm! All is well!
If UML and Patterns is making your engineers less intelligible, then they are doing something wrong. It is possible that those tools are not appropriate for your problem space. It is also possible that they need to drop the elements of the model that aren't working for them.
Design Patterns is an incredibly useful tool, especially in the OO world. But as was noted in the article, there is a danger of designing everything as a pattern. Being able to say "I use a Service Locator to look up the remote resources" or "I use this Abstract Factory to get the proper xml parser" is incredibly useful. But it has a tendancy to be overdone.
Everything, including tools, in moderation!
Ah, and then there is the other fad - point to Microsoft and say - "That's crap. Never used it, never will, won't even look, but it's crap. It's a fad! Watch it disappear."
I suggest you get off the bandwagon and do a little of your own thinking...
p.s. Stop making me defend Microsoft, you insensative clods!
XML is a fad because the whole concept of universal interchange of data is getting locked down by the big vendors. Theoretically, yes, data in XML is portable, but, so are well documented binary structures and CSV.
To have real interoperability, you have to know how the software uses the data. To get that, you must have open source. Microsoft knows this, and that's why they are pushing XML as the "nirvana" of interoperability.
I'd invite anyone who argues against the above to look at an XMLized Word document...
This is my sig.
UML, EJBs, SOAP, XML, all fashion trends, you say? This may be true, but take a look at job advertisements in the software development field... a lot of them require that you know wonderful things like UML, EJBs, SOAP, XML, etc. This is why I quit my very well paying software development job and went back to school to pursue graduate studies. I realized my job was based on nothing more than fashion trends. It was just the same old stuff being rehashed and remarketed in a different way. In grad school, on the other hand, I get to explore problems from the perspective of real research and development, instead of being constrained by a bunch of marketing drones insisting that we include every latest piece of technology possible to make our product seem "cutting edge."
Well, that sentance pretty much sums up what wrong with the computer industry, doesn't it?
"Freedom means freedom for everybody" -- Dick Cheney
Is it just me, or does this strike you as sort of a fluff-piece? It seems like the author had little to say other than a vague concept that "Gee, a lot of once-popular software ends up not really having any staying power." and realized he could put together something somewhat eye-catching by relating it to the fashion industry.
To me, fashion is a term reserved for defining the look of a thing. If people stopped wearing shorts because the weather got cold, it wouldn't be correct to blame the lack of sales of shorts as due to their being "unashionable anymore". Maybe everyone WANTED to wear their shorts but just couldn't stand to do so anymore because they weren't practical for the conditions.
This is how I view most software. Things get hyped up initially, simply because they're new and different. (I.T. folks generally like variety. We get bored if we use the same old tools every day, for years on end, and no new challenges arise.) Then, as enough people put the new tools to use, they start coming to conclusions. "This product is far more efficient than the last one." or "This thing is bloatware!" The products that are too buggy, insecure, too slow, or just not as practical as they sounded on paper get tossed aside.
The only element of "fashion" I can see in software development is in user interface design. Even this tends to stay within a single product line though. (EG. Apple went through their whole "Aqua" stage - where everything had shades of blue. Now Jobs is fascinated by chrome, and even his new G5 towers have metal cases, to match the chrome look to most of the new Apple apps.)
A lot of these "fads" are natural progressions of computer science.
:-). Again, it's not Struts itself, but "Struts-like systems" which are highly abstracted.
You do realize that computer science is pretty young still, right? Stuff like design patterns are breakthroughs, and they are *discoveries*, not "methodologies".
Design patterns: "[programmers] shoehorn as many design patterns as possible into their design". Well, the author misunderstands patterns just as much as the people he is criticizing. Patterns are not "cookbooks". Patterns are simply names we use to describe stuff that our programs do over and over. You can't say you're not using patterns, because you are. The purpose of patterns is to think about your code at this higher abstract level, so you can recognize what's "the same" between every loop you ever wrote (and no "loop" is not in the GoF book, but it's still a pattern, because each loop is different but there are still similarities. learning to recognize those similarities is what patterns are about. Some people who've never read GoF have this ability).
Struts: in the old days (a couple years ago), I'd agree with the author: Struts makes code too slow and complex. But these days with big complex projects and super-fast computers, Struts makes a lot of sense. In my own programs, as they become complex, I tend to abstract stuff out over and over until it ends up looking basically like Struts anyway. Why not just start abstract? My Struts code is completely factored into simple testable objects and is much more reliable. If I had to hire a wizard JSP/Beans programmer and a mediocre Struts programmer, I'd think hard about the Struts programmer because his code will probably be easier to refactor (this an untested theory
Web service: Sure there's a lot of hype but I can throw together a remote procedure call interface in Perl that calls Java in about 5 minutes. Computers are fast, I don't care if they are burning extra cycles building SOAP envelopes (or XML-RPC which I prefer at the moment, easier to debug, SOAP is not stable and universal yet).
XML: say, why does he "flinch" at XSLT? XSLT is a great solution to a whole class of problems. I think of XML as the ASCII of this century.. not the most perfect representation for all data, but probably pretty close. How many times have I needed a format and just started using XML and not have to worry about 1) how to escape weird characters; 2) how to handle different character sets; 3) how to write and debug yet ANOTHER parser for MyLittleDataFormat23425, etc., etc. XML just makes life easier.
VB.NET: haven't had much experience with this but people seem to like it....
XP: XP is definitely faddish, but beneath the fad is solid basic computer science best practices. For instance testing: is there any idiot out there who DOESN'T think testing is important? Unit testing catches so many stupid errors it's not even funny. And test-first development means the tests actually get written. Psychologically, it's a lot more "satisfying" to write the test, and then the code that passes it, then the other way around. etc. etc. etc... the author is right, XP stuff will be integrating into other "traditional" methodologies. But that means XP is not a fad, doesn't it! XP is basically the only methodology that I've seen that works, even if you don't do it right, and it makes programming FUN. I can't say that for anything else I've tried or seen.
So in summary, the author seems like an old-timer who doesn't like this new-fangled stuff, and doesn't realize that yes, after the fads die down, we'll be left with the best parts of each "fad", and we'll be the better for it!
This is XML as well, but is it any easier to pick apart once you've deserialized it into a tree?
Just having XML syntax just gives you a tree. You need some way to process Microsoft's model of something into a model your program can understand.
Will I retire or break 10K?
Misuse of EJBs complicate development. When they're used just for the sake of fashion (as often seems to be the case), a perfectly good solution (for something) can be applied to entirely the wrong problem, resulting in a mess. The parent post makes two good points about the danger of fashion (another way of saying following blindly without thinking?); one of these points is perhaps made inadvertantly. Firstly, the results are bad. Secondly, it can make it look as if the subject of the fashion always produces bad results and has no merit.
Just because EJBs can be (and sometimes are) misapplied does not mean they have no value. Sometimes the situation is not 'EJBs complicate development', but rather problems get complicated all by themselves, and EJBs can provide a solution. For example, container managed entity beans can make object-relational mapping happen (along with transaction management) with hardly any code. It may seem complicated when you look at the multiple interfaces and deployment descriptors needed, but really this is a very simple solution relative to the complexity of the actual task to be performed. If I had to write my own code to handle these tasks so easily, it would take me forever.
I would like very much to have a tool like UML to explain my designs -- I am a very visual/graphical type person. The trouble is that UML has so many kinds of lines, arrow heads, and connector icons that I can't make heads or tails of it. Even if I could learn the UML iconography and calligraphy, the representation is so busy that it seems to be useless.
A method that proposes comments that don't live in the code is broken. It requires programmers to have a second file open, and to update two things every time they make a change. A system that requires an extra annoying step for absolutely no gain is defective.
For absolutely no gain? Yes. There are better ways, such as putting any needed documentation into the source code itself. That way not only are they more accessible when reading the code but they're easier to change and harder to forget about.
Check out doxygen (at sourceforge) for a pretty cool system.
This is your fashion: it is cheaper to outsource, at least in the short term. This is here to stay (is not even a fashion, it has been common sense since the early 90s). If your company makes doughnouts why should it devote resources to accounting, IT or cleaning? All this can be done by specialists in the respective fields. And if those highly skilled specialists happen to live in Gujarat and charge you substantially less for the outsourcing, you, as the person responsible for increasing shareholders value (and you own stock options) would be mad not to take the oportunity.
End of the history. In an economic system where quarterly reports are king you did not expect long term vision, or did you?
IANAL but write like a drunk one.