elegant software design

An impression others often have of my insistence for. Upon further thought when this term was used on me again recently, I realised the usage of the word "elegant" is erroneous.

"Elegant" is used to describe an idea, plan or solution that is clever but simple, and therefore attractive (http://dictionary.cambridge.org/define.asp?key=25143&dict=CALD). Elegantly designed things takes effort. But the magnitude of elegance in the end-product is subjective. Different people hold differring views of what constitutes elegance and how much a particular factor affects elegance. Almost just as beauty is in the eye of the beholder.

However, software design is less of an art but more of a science. There are design patterns to help solve common problems; even if one is ignorant of patterns, an effective solution usually mimics an existing pattern. There are also general rules one should follow; the most common but most difficult to adhere to is the simplicity rule. (I'll write on SIMPLE software design in a separate posting.)

Given that there are rules which should be followed, this makes a good piece of software design to be described as proper more than elegant, which is the point that I want to get at. It is proper design that makes for easy usage, debugging and maintenance. In fact, this applies not just to software, just as a properly designed car makes for ease of handling, low maintenance and efficient motor transmission.

The catch is: it takes a certain amount of understanding to appreciate the proper-ness of a design in any domain-area. Only when proper-ness is attained can one perhaps debate over its elegance, beauty and all other things subjective.

a webservice chore

Creating a webservice has become a chore. In fact, it has never been exciting. There are just too many things to do and too many things that can go wrong. Starting with the WSDL, defining the service poses just too many posibility of making errors. Namespaces can go wrong; the WSDL can be WS-* non-compliant; even with WS-* compliance, Java can possibly generate difficult to use endpoints, or .NET not generating the expected proxy classes. This is certainly not recommended for the non-technically inclined. You create either a mess or an art, a painful piece of art.

Having adopted the development process of WSDL-to-Java, I start to wonder if the opposite way might have been easier. Just define the endpoints in my Java codes, and let the tool generate the (supposedly) WS-* compliant WSDL. Certainly I won't have as much control over the WSDL and XSD generated, but doing it this way will help to negate the need for designers to know the technical details of WSDL and XSD. Note that not all designers are technically inclined or trained, which I've always wonder why are they not so.

funny day

Funny day this is. Suddenly thought about how the world came about from millions of years ago to this day as I make my way from the train station to the office. Imagined that the ground beneath me is just plain dirt, not concrete. Or could just be just the ocean as land has not been formed. Do God really exist? Then I snapped myself out of it... back to reality.

Work at office is bordering on insanity. People questioning whether a public static final constant is initialised. The server not started, and the status right in my face and I don't see it. Recalling entire application configuration from memory. Generating those stubs when they refused to only yesterday, and I still don't know why it couldn't before. And to round up the day, evergreen war stories from the frontlines of user interaction.