Henry

Reinventing Offshore: We need poets, not just literate

One of the most discussed subject in offshore development, is bad code quality. various factors contribute to this problem, you can easily blame the developers. But the fundamental problem is with the way we groom individuals in an organization.

We used to have syntactical problems, today, these can be solved by automated code review tools like CheckStyle, FindBugs, FxCop, StyleCop, etc.

But does this enough? 

there is a huge difference between a quality code and syntactically correct code. A quality code is much bigger than syntactically correct code,

it is like a poetry.

right use of words, correctly structured, in a shortest form, without affecting the language grammar, conveys the message and make you feel great.

Most of the developers come out of college as literate, they know read and write java, or any language. we can't expect quality code from them, unless we groom and expose them to quality code in a systematic way.

Freakonomist: Craig Larman

In  Agile India 2006 conference, Craig Larman, presented an interesting keynote on History Evolution and Agile vs Waterfall. With a great amount historic data, he showed the hidden side of Waterfall methodologies. He almost traced back the traditional software development approach to the very first document on waterfall methodologies, and shown how it has evolved from a personal view of Dr Winston Royce. 

Great work, Graig.

Related Links:
Agile 2006: Another Perspective/Story

Let the requirement drive everything

Requirements are the important element in software development. At any point of the development, you either Identify, manage, or deliver requirements.

Unfortunately, these requirements are, like vehicles in Bangalore (some mad trucks, irresponsible autos, and lots of terrible two wheelers), no one knows from where and when they would come, everyone try to create their own roads, trying to go in 5 lanes where only one is possible,

The current systems have completely failed to control this, So the result is unpredictability and everyone enjoys jam and delay.

The only possible solution is to regulate these requirements.

This is what, most agile processes do, iteration is nothing but regulation, especially, SCRUM has a cop (Product Owner), and His job is to create the free flow of requirements by prioritizing and regulating the coming requirements.

The result is predictable progress.

Bangalore Traffic and Software Development

Living in Bangalore is not that easy as it looks, the traffic conditions are unimaginable. Experiencing this everyday, I realized that the problem we face in software development is not so different. 

Unpredictability and Delay

Interestingly, not just problem, even the solution is same.

Take a look at my Bangalore Traffic Analogy (pdf)

Also look at Vasanth post on Bangalore Traffic: The Human Touch

Bringing Innovation and Design

Though these words are spoken at every board room and described in every company’s vision statement, there is no clear process created so far to make that happen.

As Kjell Nordström and Jonas Ridderstråle describe in Funky Business

The ‘surplus society’ has a surplus of similar companies, employing similar people, with similar educational backgrounds, coming up with similar ideas, producing similar things, with similar prices and similar quality.

This truly applies to every organization big or small in the IT service industry, especially the Indian IT companies

The only way in which companies can differentiate themselves, is by bringing radical differences in what we offer to our customers in a proactive way.

This can be achieved only by brining a proactive culture which focuses on innovation and design.

Design Driven Development (D3), is one of the promising methodologies ever created to make this happen.

I will be speaking on this topic “Bringing Innovation and Design through D3” on the coming Agile India 2006 conference.

“Sign-off” syndrome

Change happens. Period

Nothing new about this statement, we all know this.

Yet, not understanding this in a real sense, still remains the single most reason for all software development failures.

so waht is stopping us from understanding and adapting changes?

it is, what i call “Sign-off” syndrome 

Side effects of this syndrome are

Failure 1: It forces us to understand everything and make all the design decisions upfront. It is unrealistic and impossible to do, because

• Incompleteness and inconsistencies of our ideas become clear only during implementation – Anonymous
• Majority of the customers doesn’t know what they want
• Our perception about the problem changes, sometimes the problem itself (Eureka! one more quote)

Only way to solve this issue, by understanding that software development is a continuous activity, and make the customer understand the evolutionary nature of software and be proactive partner in offering right solutions

Wanna be an Architect?

Many of my geek friends are in a kind of transition point in their career life, most of them worked on  specific technologies for last 5+ years, Now they have reached the crossroads where they get to choose either project management or technology specific roles. One of frequent question from them is "If I have to become an Architect, What should I do?",  Here is my answer for everyone, who are interested in becoming an Architect.

Learn to Comprehend:

First step to become an Architect is, understand the term "Architect"
In my definition, "Architect is one, who takes the major design decisions".

In today's world, developing software demands a greater number of decisions to be taken, most of them related to

> What to build?
> How to build?
> How to make our solution available 24/7?

software has become so complex that no single person can take all these decisions. Each one of the above questions, requires some specific skill, expertise and experience.

Based on the decisions they take, Architects can be categorized into Solution Architects, Technical Architects and Infrastructure Architects.

Solutions Architect - "Who decides on what to build". Solutions Architects work on the business, requirements and the behavior side of the application. They have multiple project experience spanned across different industries and problem areas. They also have experience in building broad range applications (desktop, mobile, enterprise, and embedded), etc.

Technical Architect - "Who decides on how to build", They decides on the implementation side of the system and how to integrate different technical components and other Open Source tools and technologies to implement a business requirement, Technical Architect also should have experience in various technology components, tools, OOAD, Design Patterns, understanding and building Framework, etc.

Infrastructure Architect - "Who decides on how to make our solution avialable 24/7, This role requires an outstanding, real time experience in configuration and fine tuning of specific tools and servers. Their main focus will be on Fault Tolerance, Load Balancing, Capacity Planning, etc.

These above roles compliment one another and are equally important roles. Based on the interest and experience, one can decide  the kind of Architect role, he/she wants to be.

Dare to Explore:

Apart from technology, an Architect should have a broad understanding of various things, including business, processes, development methodologies, implementation strategies, etc.

A common problem with the technical people is, they focus only on technology. I see very few go beyond technology and spend sometime in reading and understanding other topics.

Here is a list of books, I would recommand every one in software industry to read, especially Architects and Project Managers

> Crossing The Chasm By Geoffrey A Moore

> Breakthrough Consulting By Dembitz & Bessinger, Prentice Hall

> Selling Dreams By Longinotti-Buitoni

> Living On The Fault Line By Geoffrey A Moore

> The Circle Of Innovation By Tom Peters

> Project 50 By Tom Peters

> The Mythical Man Month By Frederick

> About Face 2 By Alan Cooper

> Beyond Software Architecture By Luke Hohmann Addison-Wesley.

> Patterns Of Enterprise Architecture By Martin Fowler

> Domain Driven Design By Eric Evans

> Ziglar On Selling By Zig Ziglar

> Secrets Of Power Marketing By Peter Urs Bender

> Leadership And The One-Minute Manager By Kenneth Blanchard

See my previous post  Am I a rare intellect? I think so! for the complete list of wonderful books from my library

Prepare to Experiment:

An old proverb says "I hear and I forget. I see and I remember. I do and I understand.", it's very much true in terms of learning anything new. We tend to forget everything, unless we actually use our knowledge in a real time.

Since software development is driven by the customers needs and chagning market dynamics, getting a right environment to experiment every technical decision is very difficult, unless you are part of the initial stage of software development.

The best possible option is, to team up with like minded people, and take three or four different problems, start architecting solutions from the scratch.

Other bloggers who has similar thoughts:

Role of a software architect - Fabrice Marguerie

Do you wanna be an Architect when you grow up? - Martin Fowler

What are the types of architect? - Michael Platt

Breaking Down the Software Development Roles - Robert Bogue

Enterprise Architecture is not Software Architecture - James McGovern

Software Development in 21st Century

"Making programming fundamentally better might be the single most important challenge we face -- and the most difficult one."

The practices of the software engineering community have changed very little over the last 30 years, and the mistakes being made then are still being made today.

Here is my questions to the reality and some solutions: Software Development in 21st Century (slides)