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