Thursday, January 15, 2009

Why Software Projects Seem to Be Late?

Development Models
To answer this question, we have to get a basic understanding of the "what is it" of the software development process. What kind of a beast is it? The easiest way to understand is to model it. If we look at any development process, we find that roughly it is made up of three phases: the envisioning phase, the design phase and the implementation or construction phase. To simplify our discussion, let us merge the envisioning and design phases into one phase and call it the Inventing Phase. Some people call it discovery, others call it exploration, but let's just call it Inventing Phase. After we invent something, then we send it to the factory or what have you to be constructed, assembled or implemented etc... So we can break any development effort whether it is buildings, cars, spaceships etc... into two clearly distinct phases in development: Inventing Phase and Construction Phase.

The Nature of Software Development
Unlike any other domain, in the world of the software, the Construction Phase is highly efficient and optimized because of the fact that software can be easily "copied" and constructed in no time. Other domains, they cannot simply copy/construct their entities in such a fast way. Therefore, in other industries, the construction phase is highly visible. One doesn't just copy a car or a house. It takes time to construct a house or assemble a car. In software, you just copy or xcopy it, install it to deploy it. So we can safely conclude that Software development leans itself more heavily towards the first phase which is the Inventing Phase.

Comparing Apples To Oranges
The mistake that we make is that we compare Software Development which is mostly an "Inventing Phase" process to the "Construction Phase" of other domains and then we wonder, why do most software projects miss their deadlines. Of course there are other factors involved in the delay and it can definitely be remedied, but we won't be able to do that unless we understand the nature of and classify it in the right category. Only then we'll be able to deliver on time.

We've seen the ubiquitous analogy comparing software development to constructing building and now we can clearly see that this is the wrong analogy. This is because houses are already invented, explored and discovered. All what's left is to construct it in a deterministic way. On the other hand, every software project is unique in its kind and it involves a lot of discovery, exploration and back and forth with the customer to get it right. In short, it is safe to say that every software project is an invention. After it's been invented, then it is "constructed" or deployed many times over or copied to CDs which is a very fast and simple process compared to other domains such as constructing airplanes or buildings.

In summary, software projects seem to miss their deadlines because we are setting the expectation of the customer that developing software is like developing a house. Therefore, we're setting up the wrong analogy for the customer and in turn the wrong expectation because now the customer will compare that to the deterministic process of building houses. In other words, compare the Inventing Phase of software development to the Construction Phase of developing a house or a building.You can see how this could lead to trouble.

Helping Customers and Correcting the "Misunderstanding":
Software Development is a Inventing Process
Maybe we can help our customers understand the nature of software development by using the correct name for the process. Instead of calling it only the abstract "Software Development", we can probably also call it Software Invention or Solution Invention... something like that to make it clear that they are about to embark on an invention project type. Now how to accurately estimate an Invention project type will be the topic of another post. But at least we know what we're dealing with.

Software Development is Architecture-Centric by Design
As a last note and a future candidate for another article, since software projects are design and envisioning intensive, they lean heavily and by nature on a role to keep the conceptual integrity together, to keep the master design coherent, to make sure that the solution meets the high-level requirements (architectural qualities) and stand the test of time. This role is the Architect. The nature of software is architecture-centric by nature. Any other approach as we've witnessed, has the potential to bring trouble to the project, especially for complex, enterprise level projects. As Grady Booch said: "You don't build a sky rise like you build a dog house".

Wednesday, January 7, 2009

Architectural Analysis: How to Determine Architectural Drivers/Qualities

The Sea of Architectural Qualities
The main goal of an architecture is to satisfy architectural qualities. Architectural qualities are not limited to a specific set such as scalability, usability, maintainability, reliability etc... They are dictated by the business strategic objectives. Each system has its own set. For example, "Jam-ability" is a quality that the famous Kalashnikov rifle design was optimized for. An architectural quality or driver for a building in Japan where there are lots of earthquakes is a building architecture in Japan could be "Shake-ability" for instance. Software Architects should be open about determining the qualities to design for getting the inspiration for them from the business objectives.

Something Has to Give
An architect cannot simply optimize the architecture to satisfy all system qualities. He or she has to realize that architectural qualities could compete with on another. The choices of which qualities to optimize for should be done carefully to make sure they don't contradict each other. For example, Security and Usability are competing qualities.

Determining Architectural Qualities or Drivers
A starting point for an architect to find the architectural qualities or drivers is by analysing areas of change: external and internal, present and future. Ask yourself, what are the current areas that need flexibility or have variability in the system? What realistic changes the system will endure in the near future? Select those qualities and build your architecture to resolve them and guard against them. This approach will lower the total cost of ownership of the system and increase its longevity.

Elements of a Simple Plan

Saleh Najar
The content of this article might be changed without notice.

We here about plans everywhere. Project plan, business plan and it seems like it is scary or vague to most people and they shy away from it. If you don't plan, you don't deserve to succeed. Planning and writing your plan shows that you've matured professionally and you are playing on the same level to stakeholders. It enchances communication and your own understanding of the project at hand.

I see the elements of a good plan to be:

1- Purpose: Quick summary of the end goal of the project. This should be based on the vision.
2- Management: Who's in charge and accountable, there qualifications.
3- Scope: A list of tasks starting with a verb that would accomplish the purpose.
4- Specs: The parts that make up the project and their expected qualities.
5- Schedule: When will things happen?
6- Phases: Grouping of the tasks together to simplify management and assignment.
7- Providers: Who will do the what? Humans, machines, companies, specialists etc...
8- Money: How much does it cost and what will it return? At a minimum, this should include an itemized budget, sales and profit forecast.

This can be tabularized and almost each item becomes a column header.