- Store some of your configuration in properties files, some in XML files, some in the database, and some as static variables in your code.
- Use reflection and dynamic proxies wherever possible. Where not possible, use byte code manipulation.
- Never ever use assertions. Catch all exceptions and errors, and keep running. Don't ever send an error back to the user. Unless it's a NPE (Null Pointer Exception) . :)
- Log either nothing or everything. When logging everything, include verbose output from all your third party libraries.
- Always wrap your exceptions. Log the stacktrace from your wrapped exceptions only.
- Loosely couple all your classes using XML configuration. When you realize that you need to somehow call those classes, provide instance accessors using public static variables.
- Re-invent the wheel as often as possible. Write your own ORM. Your own remoting. Your own cacheing. Your own GUI framework. Your own testing framework. Your own widget toolkit. Your own scripting language. Write your own patterns or you can mix two or three patterns. Make up excuses and benchmarks to show why you needed to re-invent the wheel.
- Make your code base as huge as possible. Include classes that were never used or tested. Use an abandoned experimental product to compile your classes. Make it impossible to compile in an IDE, and painful to compile from the command line.
- Create many sophisticated disparate systems. Integrate by FTP. Using flat files with pipe delimited data.
- User experience is not important. Create a slow, ugly GUI that uses a massive 2 gigs of RAM.
Love the sarcasm and humour intended.
ReplyDeleteA lot of techno babble though which might not connect with everyone.I had a tough time connecting the loosed ends as I read throuh it.
Appreciate the effort though, and also assume that u receive this constructive feedback in the positive sense.
Keep blogging.............I appreciate people who manage to do it, coz I have never managed a single one till date.
Love the sarcasm intended. Lot of techno babbble though. Might cause a disconnect with select dumb readers like me.
ReplyDeleteunfortunately this is 100% true as well for some non-banking applications i've worked on :(
ReplyDeleteMake sure the transactions takes less than 15 days! if you do online banking with ipay you may find your payments start to get later and later?
ReplyDeleteu missed out the importance of having different versions of the same library some of which will be lazy loaded using custom classloaders...simply because someone simply refuses to RTFM :|
ReplyDelete11. Only use libraries from Java 1.0 because a Java 1.0 JVM exists everywhere.
ReplyDelete12. Use the newest technologies from Java 6 and Java 7 because it gives you the best features.
it was nice to read the humour but sadly it is true too these days :(
ReplyDeleteby the way, which actual application(s) and running in which organisation , prompted this article :-?
Ashish Ranjan
ashishwave@yahoo.com
If programming in Java...
ReplyDeletehow about catching those annoying OutOfMemoryErrors?
Heck, while we are at it, throw new VirtualMachineError("Muhahaha");
You forgot the most important part...
ReplyDeleteOFFSHORE THE ALL THE PARTS THAT SOMEONE ACTUALLY DOCUMENTED AND LAY THEM OFF and keep the programmers who created the components that were so convoluted and undocumented that they couldn't be offshored!
One to add:
ReplyDeleteCreate one shared development and test database to be used by all developers.
Hi,
ReplyDeleteFunny to read.Good points to remember to forget when working in these kind of applications.
Thanks
Prashant
http://prashantjalasutram.blogspot.com/
While I salute the author for several fresh points, link to "previous art" is needed
ReplyDeletehttp://mindprod.com/jgloss/unmain.html
Have a happy coding everyone!
AV