An idiot rules for the programmer specialized in java/ee



I would like to share my bad and good experience in application's design and planning.



Remember, if you work with WEB/EJB container's objects, never make assumptions.

This stuff always tends to behave against your common sense.

As example:

Servlet is stateless , never assume you able save a state in it, even static variable of the servlet is not appropriate for the purpose!

Servlet managed by WEB container and god knows when it reloaded and why, so never <EVER> attempt to save state in the servlet.

As alternative use the ServletContext - this one for sharing purposes by spec.

Read spec when you make assumptions for other container objects. They behave against common java rules :), because they are MANAGED.



Having a collection as a state accumulator in you class, always be cautious form the beginning!!!

Collection , when it used to save a state is dangerous!


Because , if more than 2 callers access the state and modify it, you have to assume concurrency!

If you even suspect that concurrent access to state is present , be prepared!

Never leave this work to the last moment. You have to establish right concurrent access as a rule!

Use Lock(java 5), use synchronized(java 2), use Semaphore (java 5), use CopyOnWriteList(java 5), use Synchronized collections.

But for the god's sake use one of them!!!!

Otherwise you will got ConcurrentModificationException in production - nastiest thing , worse is only OutOfMemory!




Avoid entirely an inheritance tree and complex sub classing and interfaces unless you absolutely sure you have to extend this class.

If you write a simple Calculator, be sure you DO NOT OVERDESIGN IT!

Nobody needs that complex hierarchy, where 5 classes extend each other and nobody really needs first 4 in the tree!!!

Unless you plan work in this company for years and extend this shit by your own hands.

Never use closures, callbacks unless you absolutely sure you have to do that.

This makes your job secure, but nobody able to read that garbage!

Less static variables you have - more secure you are.

Be simple, be stupid - this is a way to meet others!




When you access DB or other shared resource, make this in order! Make this German!

Your method may lock DB objects one by one: lock A, lock B, lock C.

Always preserve this order whenever you lock something, changing the order is DEADLOCK risk.




Choose easy and fast transport, not always WebService is perfect. :)  Not always HTTP is a best choice. Choose fastest and most reliable protocol

for your real (R E A L) needs. Less data you pass by wire, better for you.




Use those frameworks which you know. A bit. At least some internals. Avoid frameworks if it's a black box. Choose this one, whose forums are active and whose releases are frequent. As rule - less TURD(not mistake) party you use - more stable you are.




All books I've read about exceptions are perfect, but the shortest rule is:

make custom exception checked if your write for other people, if you write an library, if you wanna to declare the possible problem for the external user.

Your checked exception is a contract between you and unknown user. Or between you and an external level.


Make it RuntimeException, if your consider this exception fatal and unrecoverable.

Also use RuntimeException whenever you have a doubt have some hesitation.

Better explode earlier than later in production! If your instead hide exceptions like this:


try{...}catch(Exception e){/**Do nothing**/}, you are sucker!  And watch your back, people will hunt you!




If it works - do not touch it! This is the first rule if you work on legacy code!!!

Do not touch a working code!

Do not make your clever assumptions. Those who designed this

stupid application are already retired or dead and you have thank them for the bunch of bugs and for the paid hours you got.

Respect their work - do not touch it!




And last and most comprehensive rule:

Discuss your work with others  - this make you look friendly and allows you fix some problems at the very beginning.















Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at