Software Development in a Recession – I

As a global recession looms large over the sunshine industry of the last decade, there is a big question mark on where Software Development is headed in the midst of all these gloom. Cost Cutting and Increased Productivity have emerged as the two favorite mantras of the IT corporate, so what does all this mean to the software development industry.

The History
A look at the last couple of decades and one can see the long way IT has covered. The swinging 90s was all about a boom, with investors investing blindly in anything that started with information and ended with “.com” or “2K”. Those were real good times, I remember one of my marketing colleagues once came to me and said can you add an XML file to the project. I told him that we do not need XML at all. He insisted that I should still keep an XML file, so that he can claim that the product used the latest XML technology!! How nostalgic the memories of the swinging 90s are!!

All these nostalgia came to a grinding halt with the dot com bust. This was the first reality check for the industry and people really started to look at the software products and the software development closely and identify and minimize the overheads associated with the industry. After a lot of head rolling, shutters lowering, the industry eased into the next phase of growth.
This phase was characterized by standardized processes, more stress on Quality and Process Control and shift from best-of-breed to standard solutions. In this phase software has consolidate and established itself as a core ingredient of any successful organization.
Now that the global recession looms large, Software Development is in a better position to take on this down trend compared to the bloodbath experienced during the Dot Com Bust. Even so, this is an opportunity for the IT companies to look at their portfolios and development processes and use this as an opportunity to improve on their strategies and processes so as to emerge stronger from this excercise.

Points to Ponder
Design/Architecture Cost
Now that Software Development is establishing itself as a standard industry, it is also the time for us to learn from the other industries. For example, for Manufacturing industries 60% of the product cost is determined by the concept/architecture phase alone, the rest of the product development and support activities cost around 40% of the product cost.

Now in the software development parlance the cost at the concept/architecture stage though not so lopsided, still has a very significant impact through the development cycle. By the time a product has been designed, only 8% of the total product budget has been spent (the incurred cost line). By that time, the design has determined 80% of the cost of the product!! This fact means that if we want to move towards a more cost effective structure, the effort begins right at this stage.

Concurrent Engineering
One of the keys to reduce the costs at this early stage lies in the basic engineering principle of Concurrent Engineering. In the Engineering Parlance, Concurrent Engineering is the practice of concurrently developing products and their manufacturing processes. In the Software Development context it is generally the development of similar products using similar processes and synergising the effort.

Essentially, suppose three projects are going on and all three of them need configuration management which requires some data to be read from an XML file, why not synergize the activities and design a common framework/library to perform the activity. This kind or synergy is notoriously low in the Software Development cycles, where each individual likes to come up with his/her own solution to a problem rather than re-using another existing solution. At a higher level the problem might be a question of one or two differently implemented feature while at lower levels it even goes down to the preference of the language in which the feature is implemented.

It is time for a reality check now. You as a techie might be interested in a new technology, the customer is only interested in a solution. It is high time the Software Development industry started looking at solutions they offer rather than the technologies they work with!!

Design for Manufacturability
Again an interesting manufacturing process, DFM is the process of proactively designing products to (1) optimize all the manufacturing functions: fabrication, assembly, test, procurement, shipping, delivery, service, and repair, and (2) assure the best cost, quality, reliability, regulatory compliance, safety, time-to-market, and customer satisfaction.

Put into the software context, it is about designing the products to (1) optimize the development, testability, shipping, delivery, service and (2) the best cost, quality, reliability, regulatory compliance, TTM and customer satisfaction. The key here is again designing components which are easy to implement (simplicity), yet reusable (major cost saver). The days of “I designed it; you build it!” are over. One way that development can be assured is by developing products in multi-functional teams with early and active participation from development, testing team, finance and the service teams.

DFM encourages standardization of components, maximum use of existing components, modular design, and standard design features. Designers will save time and money by not having to “re-invent the wheel.” The result is a broader product line that is responsive to customer needs.

Off the Shelf Components
There are two parts to this concept. One as a benefit of DFM, more and more components can be designed as Off the Shelf components. Second, as designers, you can choose more and more Off the Shelf components to suit the software development process. In many cases, the architecture may have to literally be designed around the off-the-shelf components, but this can provide substantial benefits to the product and the product development process.

Off-the-shelf parts are less expensive to design considering the cost of design, documentation, prototyping, testing, and the cost of non-core-competency development. Off-the-shelf parts save time considering the time to design, document, administer, and build, test, and fix prototype components.

Suppliers (both internal and external) of off-the-shelf components are more efficient at their specialty, because they are more experienced on their products, continuously improve quality, have proven track records on reliability, design better for DFM, dedicate production facilities, produce components at lower cost, offer standardized components, and sometimes pick up warrantee/service costs.

Software Development organizations have a good chance to take a hard look at their processes and use the Global Recession as a chance do away with the fat accumulated and emerge out of it more agile and more fit. The first step in this journey would be to look at the Design and Architecture costs.



One thought on “Software Development in a Recession – I

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s