Add Simplicity

SIMPLICITY needs to be constantly "added" to software solutions.

It's very easy to create unnecessary complex solutions for variety of reasons. We engineers like to create smart and unique solutions, but can't always see where it is justified to do so. It can easily become an "ego thing" where too much of personality of author creeps into solutions. No one else then fully understands the solution, which becomes increasingly problematic with time.

Today I'm painting my garage. It is 30 degrees Celsius out there and all I want to do is to give the garage a new coat of paint. The builder has decided to add nice mouldings horizontally and vertically - every few feet. These mouldings while nice, increase my effort exponentially, as I have to paint them individually. 30 degrees heat is equivalent to a need to turn a project around quickly - under heat. Luckily I don't have to paint the garage that often, but I'd be in serious trouble had it been my software product.

Another reason for complexity can be just the development landscape. Especially enterprise software can be a mine field of complexity. Variety of implementation technologies, techniques and patterns is augmented by infrastructure as colorful as United Colors of Benetton.

So just to display enterprise grade "Hello World" - what do we need to consider? Front End? Check. Load balancers? Check. Web tier? Check. App Server? Check. Database? Check. ORM? Check. Caching? Check. MQ? Check. EMB? Check. WS-*? Check. A few obscure protocols of choice? Check. Complex transactions? Check. N-Stack for redundancy? Check. One mainframe for "Hello" and another for "World"? Check.

OK, there is more but I'll stop here. The point is that the landscape is complicated as it is. We should not add any more complexity (or "smarts"), we need to strive for the opposite. Simplify, Simplify, Simplify.

It is the same outside of enterprise software. The competition is tough, you need to be constantly adding value and looking for new opportunities. You need to be nimble an light on your feet. Ability to adapt and change is more important than validity of that "Great Idea" you once had.

The formula to success in software business is to Add Simplicity on every step of the way. If you think your killer idea will make your solution successful - dream on. Actually, WAKE UP, you are delusional and it is hurting you. Your idea has already been thought of by someone, somewhere. The difference is in execution.

"Add Lightness" - Colin Chapman

Software Art

Software engineering is part science, part art. The science part is all about making computers understand our instructions. Science are the algorithms, languages, execution environments and semantics. The science portion of software is fairly cut and dry and mastering that will give an ability to execute a given task. It is not a difference maker, though.

The difference maker is the Art component of software. Software Art is all about how do we translate an idea into instructions that computers understand, while losing as little of the original intent and scope as possible. Software Art is encompassing both What are we solving and How are we doing it, in exact measures of each. Software Art is the sweet science (doh!) of the Big Picture. It has some properties and mechanisms of its own, via which it impacts the results. The most important property of Software Art is SIMPLICITY.

To be continued ...

SOAP, REST, Postmen and Telephones

Once upon a time, SOAP was Simple Object Access Protocol.




That is some 310 characters in simple enough message.
What we want to do is to execute a remote method such as:

Amount getAccountBalance (AccountNumber);

We also wish to ask a specific endpoint:
http://example.org/account for the answer.

The actual ask could be encapsulated in as few as 65 characters.

In this example, our question’s payload grows ~5 times. The reason is that we are not ASKING A QUESTION; we create an intermediate message that does it, including complete explanation of the intent. We than sent the message to the other side, that will do nothing upon receiving the message – there is no business meaning to receiving a message, yet. The receiver has to open the envelope, read the message and reconstruct sender’s intent. Only then can the receiver actually ANSWER the question – but it proceeds to put the ANSWER into yet another vanilla envelop and send it back to the original sender, continuing the cycle.

Consider following scenario: Jane wants to ask John “What time is it?”
A SOAP service could do something like this:

Figure 1 Wait a minute Mr. Postman!


This certainly works, but there is a significant overhead in this style of interaction. Think of all the logistic and recycling needs! Also, there are dangers lurking in the shadows: Ink may dry up. Letterhead paper may run out. Or we maybe out of stamps!

It works, but we could do better..

Imagine a phone conversation:

Figure 2 Mr. Marconi? Hello?











There is no reconstruction of sender’s intent needed, the receiver reacts directly to sender's QUESTION.

This is much like RESTful style

HTTP GET www.john.org/time
HTTP/1.1 OK 200
10 AM

~
The proposition of SOAP style messaging is that it can abstract communication details. SOAP message is a SOAP message is a SOAP message. A letter can travel all around the world. It used to be that letters were the only way how to communicate remotely.

But SOAP also abstracts the actual QUESTIONS. We exchange envelopes of “mysterious content” and reconstruct senders and receivers intent encapsulated within on each respective side. OVER AND OVER AGAIN.

The main benefit I see is that SOAP is transport agnostic. I am not tied to HTTP for my Web services. Is it worth the price? Is the cost benefit justifiable? I don’t think so. Especially when I introduce other WS-* concerns, which snowball INTO my SOAP message, I quickly come to a need for dedicated midle ware, effective compression and transformation mechanisms etc. I’ll take SIMPLICITY, instead.

In RESTful style, we can ask more direct questions. The question is expressed directly to the RESOURCE, not through auxiliary message. There’s little need to keep introducing additional, verbose, xml based mechanism “encapsulate” the QUESTION and make it generic “Message”. Understanding of a Resource IS generic already, just as Jane knows what time is, so she can ask the QUESTION about it.

WS - Reuse - Simplicity - Consistency

Reuse in Web Service world. I think about reuse from the perspective of two major architectural styles - Message based (SOAP) and RESTful. It seems to me that SOAP based architecture is poor fit when we aim for REUSE, from its very foundation.

Let's have a look at the building blocks of both styles (pic below), with a bit of a twist. Clearly, SOAP style ignores the full CRUD API of its most usual transport protocol - HTTP. Instead of using full set of HTTP API - GET, POST, PUT and DELETE, it uses POST only - just as transport gimmick.

There maybe some good reasons for this, but what it also inherently means is that this very CRUD capability of HTTP needs to be replicated on the service API - after all CRUD change is what we want to do with the service.
Each service now has to re-implement a definition of CRUD capability by itself! Just by definition of this information interchange, we mandate waste. We do not use what we have and invent something new for the same purpose.

Not only is this an replication and overhead on the service provider side, it also causes an overhead on service consumer side, where each consumer pretend they do not know what they want to do, must "learn" (i.e. discover) the capability set of each service, map it onto their original intent, exchange messages with the service provider and interpret the results. So we have reimplemented the same capability, just made it more complex.

Compare that with simplicity of RESTful approach. No auxiliary messages, no discovery of APIs, each service has the same set of capabilities - HTTP methods. These methods than "transfer" "service state representations" (an instance of resource) from consumer to provider. To know WHERE to transfer and to know WHAT is the relationship of resources - there are URIs, to know HOW to transfer- there're the methods of HTTP. To navigate and relate, there's hypertext. No fancy middle ware needed, short and sweet information exchange using the battle tested infrastructure of WWW.

Now that is some sweet REUSE - SIMPLICITY - CONSISTENCY!

Ford Flex take 2

I previously wrote about my experience with driving rented Ford Flex from Toronto to New York and back. There is an UPDATE ... .


2010 Ford Flex Ecoboost now finds home in my driveway. The trusty Duratec 3.5L V6 makes way to a new 3.5L Ecoboost engine. Twin turbocharged, direct injection mill is good for 355 hp and 350 lb ft of twist that is channeled to all four wheels. The ride is lower to the ground, susspension is stiffer, steering wheel feedback (EPAS) is much improved and the 6speed automatic transmission much better match with the engine than in the rented model. The dash issue of glowing see of green buttons I complained about previously is mitigated by large screen navigation system, which is also used to control the sound, climate, phone, 10G of HDD for entertainement or backup camera. Microsoft's SYNC is still doing a great job in providing voice interface to most of the features.


Features galore indeed, but you can always turn most of it off, open the sunroof, push on the steering wheel mounted paddle shifter do drop a gear, step on the gas pedal and ... GO! There's no thinking twice about it anymore, the peak 350 ft lbs of torque are on tap almost instantly (from 1500rpm), pushing you into the seat, while the sprint from 0-60mph comes in just 6.5 seconds. Very quick and effortless. And this is a large seven seater we are talking about! The speed maybe something to get used to, Flex is a very quiet and comfortable car and it is very easy to seamlessy cross into the illegal speed range if not checking the speedo.

Another great aspect of the car is the ability to cross large distance without tiring either the driver or passengers. It is a great family GT car. That kind you can pack all the camping gear into, car seats for the little ones, seat two more adults in comfort (grandparents) and go for a weekend trip without worrying if the destination is couple hundred kilometers closer or further. Or fold all the seats flat and load up half of IKEA into it. Or take all the sippy cups and toys out and go enjoying the on-ramps and back roads. Flex can do it all and do it very well.

From the pen of Jake Maly

I pooped well this morning. Halmony washed me up nicely.

I came downstairs sans diaper & pants, and decided to go to wake sleeping Harabujy up.

Harabujy pleasantly woke up by me. Since I was feeling extra happy with the nice bowel movement, I decided to sit on Harabujy’s lap on his bed.

Harabujy and I were chilling. But then something strange & stinky happened behind me. Harabujy and I both got shocked and we started screaming together.

Halmony seems busy today washing lots of things.

Ford Flex Test Drive

Spec: 2010 Ford Flex, AWD Limited, 3.5l www.twitpic.com/lhvda

Having an extended family of six and desire for a road trip from Toronto to NYC during Thanksgiving weekend, the trusty '08 Altima was relegated to a driveway rest and we rented a Ford Flex. I was quite intrigued by the vehicle before, so I was quite happy I got to rent it for a long drive.

It's a big car. It feels like a big car inside, it drives like a big car. Lot's of toys inside, Sync is fantastic, great seats, great versatility, good handling and comfort, great HID projectors up front, LEDs in the rear. So many good things that the shortcomings are even more disappointing. In sum, it feels like a two step car. Turn the wheel and wait - it shall turn. Step on the brakes and wait - it shall break. Step on the gas and wait - it shall accelerate. There is no progressin, no modulation. It's on or off. Anemic steering feel negates very solid suspension setup. Lazy (very) 6sp automatic transmition does absolutely no favors to the 262hp V6. The important instruments are too small - speedo. There's a million buttons (so it seems) on the console http://twitpic.com/lhvgi and it does no favours to the driver on a long drive through the night and rain। Great functionality, good fit and finish but lacking ergonomics - I was really distracted by the flowing field of green buttons when needing to adjust temperature and fan speed (toggle+button action) after 4hrs of driving. What's with the single stick with turn signals, highbeams, lowbeams, front wipers rear wipers and windsheeld washer? Couldn't Ford fit even more functions in there :-)?
The writeup may sound a bit negative, but I really like what this the car COULD BE as whole. Great handling, good power, great utility and comfort in a package seating 6 people. If the next iteration fixes some of the issues and puts a bit more GT and refinement into the car (which I hope the EcoBoost version already does, to some extent), I'll put it towards the top of my shopping list for large family car, regardless of make.

Agile Done Right

Agile as a software development methodology [http://www.agilealliance.org/]. The empowering of teams, the productivity of team which surpasses combined efforts of individuals. The starter fluid to change and improvement. The results orientation. Constant iterations and reflection. All of it provides tremendous potential for an organization to deliver outstanding results.

It can be a tall order to influence the way an organization works. I work for a large financial institution and rigid, risk averse environments are typically hard to change. But I'm proud that our own "Agile Mix" is successful and finding its way to broader and broader audience. I was the main advocate, proponent and preacher of Agile, at the beginning. Not so lonesome, anymore. Given trust and a seed team, we have not only developed out own "Agile Mix". We have also delivered the product with zero variances detected through out QA, on time, on budget. Our plans and estimates were aggressive and REAL. The team loved working in high paced and stimulating setup. They loved owning the product.

Everybody listens and learns from success stories. There is no better way to convince anybody that Agile works, other than when teams love it, while superb results are delivered.

Agile done right will evolve organically, with thin layer of "impediments removal" on top of it. The core values need to be reiterated and reflected in each team's decision. The particular flavor of Agile - XP, Scrum, Lean doesn't quite matter. All of the different methodologies provide yet another set of tools we can choose from, with useful variation in approach to achieving the same thing.

To make Agile work in any organization, you need results. Go get a team and DO IT. No matter the scale of the project, doing it is the only way to figure out what works in your environment and what doesn't. Your "Agile Mix" will always change and evolve - that's a good thing. Set the expectations right, be 100% transparent with all stakeholders. Apply the same rules on the process, which you'd apply on the product. Iterate. Iterate. Iterate.