Skip navigation

Tag Archives: team

We were recently summing up the last iteration of our product, when one of my co-founders appreciated me for the tough questions I keep asking him and the others. While I was drafting a reply, I felt it may also be worthy of a post.

In any setup, there are times when things start slowing down and people start losing focus. Also, when most of the parties involved are guilty of sloth, it makes it that much more tougher to ask questions. Which inturn can make it tempting to do something like what Warren Buffet warned against in his latest annual letter:

“From the start, Charlie and I have believed in having a rational and unbending standard for measuring what we have – or have not – accomplished. That keeps us from the temptation of seeing where the arrow of performance lands and then painting the bull’s eye around it.”

When you decide that you will be the one asking tough questions, you run the risk of not being loved anymore. You need to make a choice – whether you want to be the loved one in a mediocre performing system or possibly the hated one in a high performing system. But, coming to think of it, if you are really asking the right kind of questions then people will either come around, or they never truely loved you in the first place.

Another significant advantage to asking tough questions, making it more worthy of the risk, is that it forces you to always be on your heels and pushes you to give our best. Like Mahatma Gandhi said – “You must be the change you want to see in the world.”

Ofcourse, it does help when you are already a part of an amazing team.


Service Oriented Architectures [SOA] play a pivotal role in today’s Enterprise Systems. Service orientation requires loose coupling of services with the underlying technologies. There is a lot Web Oriented Architectures gain by taking the SOA approach, especially with regard to aspects like scaling and being cloud ready.

I dont use SOA here to mean XML web services, but as a pattern for breaking down applications into distributed software components (which we call services). The components being independent units that deliver specific functionality. Data is encapsulated and made accessible only through well defined hardened interfaces. Consumers of the service are provided with a contract for the functionality provided through the interface. Hence, a clear isolation of functionality and data storage is achieved. The services manage all data internally and never provide direct database accesses. Whether access happens as XML/JSON or over REST/XML-RPC/SOAP is irrelevant for SOA. They form the various implementation options.

SOA also provides operational advantages in terms of the break down of the development work. First, small teams are created around problems. Next, the interfaces are decided and agreed upon. The teams then have full freedom in choosing tools, design methodologies, etc., as long as they provide the promised functionality through the interface. Developers in the team own end-to-end responsibilities for the service and are subjected to direct customer feedback. The heightened sense of responsibility also usually translates to better ownership of work. With hardened interfaces, localised issues and reduced integration efforts the net chaos in the system reduces significantly.

The parallel for SOA approach in the programming paradigm would be the Object Oriented Programming approach [OOPS]. Like OOPS, SOA is also vastly misunderstood. Most programmers fail to think Object Oriented-ly (esp the ones coming from the procedural world) and end up building poorly architected systems, while blaming OOPs for its clumsiness. Similar is the case with SOA.

We use SOA extensively in the systems we build at Althea. In my future posts I plan to provide more practical insights into SOA.

boring meeting
I came across this article on a linkedin group. It talks about habits, breaking routines, and cultivating new ones. All of which I strongly subscribe and occasionally succumb to. Striving for continuous improvement (which has been referred to as the kaizen technique here) has been a guiding philosophy for me in life [for those of you who chuckled after reading that bit, hey I still have a long way to go.. :-)].

The fight-to-flight response when the fear of the unknown kicks in, which also the post speaks about, is something I see happening quite often around (and in) me. Another good point is made about the different approaches that people take while solving problems. It’s not a good idea to force-fit your approaches on others, and the make of a good team would be a nice blend of people with different approaches.

Article link: Can You Become a Creature of New Habits?