Which came first; re-use or complexity?

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Quinton Wall's Blog | June 20, 2006   5:27 PM | Comments (1)

I was having a conversation with a friend last night about software development and the industry in general. My friend works as a VP of Engineering at Bay Area startup and has always been a big advocate of the LAMP (Linux Apache MySql Php) stack. A few years back, prior to joining BEA we both worked together building an engineering team for Deloitte in Australia. Our goal at that time was to reliably produce quality solutions on time and on budget. Much of our repeat business was also focused on maintenance of the systems developed so ease of maintenance was a key success factor.

During this time we were very focused on promoting re-use across projects and teams. The plan was to develop a set of core offerings and components that could be re-used on new projects. The goal of this re-use was to mitigate risk on projects and more accurately estimate effort (It is interesting that when I started in engineering and software development I I was very interested in coding but as time and seniority moved on cost-benefit analysis plays a much more important task.) leading to a more consistent delivery model which allows continual, shorter delivery of new features or maintenance of existing components.

We started discussing how the start up was going and in particular how his choice of technology, Ruby on Rails (RoR) was going. My friend was promoting the speed and efficiency of RoR when deliverying new functionality. The discussion turned, as it usually did to why I am focusing primarily on Java rather than something like RoR considering our previous history of re-engineering engineering teams to focus on speed and agility. My immediate answer was that I am more interested in designing simple, elegant solutions than one based on a particular technology, be it Java, .Net, RoR or anything in between. Experience has shown me that technology changes as such as rapid rate that components developed for re-use are often considered legacy shortly after they are completed. When you are tasked with running a profitable engineering team TCO is directly affected by the stack of technology you need to support going forward. One of the key design principles I try to follow in anything I do is to code to interfaces rather than implementations. This worked well wit hthe systems I developed in Deloitte and even more so in SOA type systems. Avoiding any change to the underlying implementation allows you focus on higher order needs of the business such as process modelling.

We chatted for a while longer about the idea of re-use being more important in modern IT due to increased complexity of systems. As systems, languages and development relying on more and more technical tools, IT departments can not afford to 're-invent the wheel' for each project. I started thinking about this a bit more and thought about the systemic issue we are trying to solve in IT:
business needs systems to operate efficiently, IT has limited resources to produce these systems with much of these resources being spent on maintaining existing code thus re-use is fundamental as IT departments can not afford to focus much of their effort on new systems.

Looking at this statement it made me think of the whole chicken and egg paradigm we are faced with. Take the problem (IMHO a good problem to have) of driving a porsche. A porsche by design is meant to be driven fast. If you have ever been stuck in peak hour traffic with a heavy clutch and 300+ horsepower on tap but not being able to use it you know what I mean!) you always want to go fast but there are certain restrictions on how fast you can go; the road may be windy, there may be traffic congestion or the speed limit is 45 miles per hour. The advantage of the porsche is lost quickly when a little hybrid passes you by getting 40 miles to the gallon! But then the road opens up, you hit a clear straight stretch of freeway and you floor it. Form meets function and you are off leaving the little hybrid in your rear view mirror dissapearing fast. The problem with this analogy is what caused the driver of the porsche to speed? Was it the clear stretch of road or was it the fact that he was driving a porsche? Given enough time the hybrid could also speed along the same stretch of highway.

So if both the hybrid and the porsche can take advantage of the right conditions to perform why is re-use an important strategy when potentially its primary reason for being is because things are difficult to build in the first place and thus code is something to be respected. Dont get me wrong, re-use is important to ensure that there is no code duplication, maturity of solutions etc but the driver for re-use should not be that code was too difficult to develop in the first place! If this is the catalyst of re-use discussions then some additional design, analysis and architectural practices should be promoted first to address the systemic issues. One such approach may be SOA and a clear categorization methodology for services. Remember even in a SOA solution re-use is focused on interfaces more than the implementations. Underlying implementations should be discrete enough at the the lower layers such as Information and Access services that, as requirements dictate should be able to be rewritten with no change to the interface. For composite services there is likely not going to be a great deal of custom code at this layer anyway as most of the functions should have been delegated to lower level serivces.

As always the conversation with my friend and I finished up with the cost of housing in Boston and the bay area. I guess in the rapidly changing world of IT there are still some constants we can rely on, cost of living is one. The other is the age old question of which came first the chicken or the egg. For us IT folks perhaps it should be Which came first, re-use or complexity?

Comments

• Hi, In my point of view.Today we most of the people are in need of the solution for a system.That system are mainly in need of due to the complexity arising in finding out the feasible solution.Hence i can clearly say that due to the comlexity arrival,we are in need of reusable components that leads to the fast production and feasible solution. Complexity came first and follows re-use.

  Posted by: omthiagu on June 21, 2006 at 10:30 PM