A normal engineering structure is designed for a specification. You say that a 5-floor building is needed. The design is done. The construction starts. Foundation is laid. The pillars come up. Then you can't come and say I need 50-floor building. It is NEVER accepted. You are laughed at. You can still ask for extra window or woodwork.

You ask for a 4-seater car. The design is done. Manufacturing starts. The engine is a 3 cylinder one. Now you can't come and ask for 7-seater car! It is NEVER accepted. You can't begin with design of a Maruti 800 and manufacture Toyota Qualis or Tata Safari. You can still ask for air cooler or stereo to be added on.

You start with 10 units of functionality for making software. You make it 30 units of functionality even before application release! It has to be accepted in software engineering. It has to survive at least 20 years of usage and such changes after release. Imagine all those legacy COBOL applications. What for they were designed and how they perform after 30 years! Those COBOL applications were still considered for Y2K (year 2000) conversion, to continue their usage.

In regular engineering disciplines once you begin 'construction', changes can only be minor to the super structure. On the other hand, in software discipline, even after construction is over, you ask for a different super structure! You want change in the foundation! It has to be accepted. Because, it is possible to incorporate such changes.

Because it is possible to ask for a change at any time, people have the luxury of asking for a change! In other words, they are lazy to think! Change Management is one of the integral parts of Software Development and it is a continuous process. In other words, software systems are evolutionary.

A software engineer has to absorb changes on a continuous basis. He/she has to design for change. That is why; "design patterns", "frameworks" exist. A civil engineer can't begin the design activity by thinking 'tomorrow if I am asked to make this a 50 story building instead of 5 stories, how do I design?' You can guess where he/she will end up! The design goals are distinctly different between conventional engineering and software engineering. A software designer has to think about all possible changes while doing design. An engineering designer has limited variations to consider, like the 5-floor versus 50-floor example. The skills demanded of software designer are different.

Look at the evolution from DOS to Windows 98. The foundation has been changed. The applications can continue to exist. Look at the evolution from IBM S/360 to z/900. Foundation has changed very much. The applications need to run as they were.

When you make a 2nd building or 2nd car, you will reuse the design and not the structure itself. You make software for one bank. When you make similar software for another bank, along with design, part of the structure is also reused. There is a difference.

Some people opine that software applications are not mission critical like launching a space vehicle. They don't require knowledge of various disciplines (like Mechanical Engineering, Electronics Engineering and Computer Science). The software projects are not large enough to demand collaborative effort that needs great project management skills.

These observations are not well founded. I agree that software engineers don't deal with hazardous propellants. But, they develop applications for various verticals like Insurance, Banking, Securities, Health Care and Transportation etc. They have to constantly learn these businesses to be able to develop applications. The presence of business analysts / consultants helps only to an extent. In addition, these businesses change with respect to space (from country to country) and time (Insurance 30 years ago was not done the same way as it is done now). From the application point of view, the other practices of engineering are same wherever you go in the world. But, the Insurance business changes drastically from USA to India. On the technology side, the rate of attrition of knowledge in other fields of engineering is much lower. Day before yesterday it was monolithic COBOL based application development, yesterday it was client-server technology and today it is network computing. To summarize, what affects other engineering fields is only 'time' and not 'space'.

Software applications that manage a stock exchange or a bank are mission critical. No one ever will pardon a software engineer if a stock exchange or a bank is not working because of a software glitch. Quite often software development projects are from a collaborative effort of people working from various technologies and geographic locations with effort running into 50 to 100 person years. Project management skill is one other basic need for software professional, without which survival is difficult.

Some people think that software development does not require any complicated mathematical knowledge. And therefore software development is easy. If you look at it carefully, the foundation of mathematics and programming is in 'logic' and without that 'logic' both can't survive even for a short while. Another trait that science and engineering require is 'abstraction'. For software designer 'abstraction' is one of the fundamentally expected qualities. The 'design patterns' and 'frameworks' breathe through 'abstraction'!

Civil / Mechanical / Aeronautical engineers can draw on hundred(s) of years of experimentation in design and construction. By contrast, software engineers have had only a few decades to explore their field [1]. The challenge is in keeping oneself updated with rapidly changing technology, without much knowledge base to look up.

... ... ... ...

In engineering, tools are very important, whether they are for design or construction. Design tools for example: design specification of a mechanical component / machine is done through a engineering drawing. There are drawing boards and graphic workstations to help the process. The parallel can be taken with class diagrams and sequence diagrams. However, typically designers and developers are not provided with workstations or monitors to view these artifacts better. Class diagrams are complex. But, we normally don't provide monitors to view them comfortably to improve productivity. Similarly we can't see many lines of code on a typical monitor. The amount of progress in computing power and disk memory has not paralleled in monitors.

In hardware engineering we have destructive and non-destructive testing. In software there is nothing to be really destroyed, even though a typical software system can fail under extreme load conditions.

Nature has given beautiful / fantastic properties like elasticity to many metals to yield and fail progressively under extreme load conditions. To give such properties like graceful degradation to software systems it takes enormous effort from humans.

In manufacturing typically fabrication happens in 24X7 model. Perhaps design is not done in 24X7 model. In software engineering mostly maintenance problems or break down situations are addressed 24X7. Building a new system does not typically happen in 24X7. Software construction is human intensive and typically requires certain functional knowledge. Subjectivity prevails in the output produced. The construction activity is logic intensive. Hence automation and productivity improvement are not equally easy / possible. It is not possible for 3 persons to work in 3 shifts and develop same computer program continuously!

Inspite of software engineering being decades old subject, the standards have not evolved in every aspect. Java Community Process has made significant effort towards standards definition / popularization. Even today integration of vairous software components / systems is not easy. Enterprise Application Integration is an evolving subject today and fairly young. That lead to increased role of systems integration space.

Even today in many businesses, 'ready made' software products are not in the main stay. Significant percentage of software systems in an enterprise today are 'custom built'. 'Ready made' software products are well established in some areas, i.e. operating systems, word processors, spread sheets, photo editors and the like. For running a stock exchange or a bank or an insurance company, there are no software systems that encompass entire functionality. Whatever 'ready made' systems are available they cater to specific functional areas of an organization. We can't buy a 'custom built' PC or printer or car or bike or washing machine for our home. Because that would be very expensive. Similarly 'ready made' clothes are common place since 'custom built' clothes are more expensive. 'Custom built' items can't achieve the quality of a 'ready made' product. Because 'ready made' product is engineered differently. There is always a trade off between 'ready made' versus 'custom built'. Availability of 'ready made' items for a purpose (printer or dress) indicates mature understanding of requirements and certain market conditions. On the otherhand in today's enterprise, 'custom built' software for business functions comprises of a great part of the IT landscape. 'Ready made' software products are mostly operating systems, RDBMSes and application servers etc. They are mostly technical and don't contain business functions. Even though ERP and CRM like packages are available today, they require significant customization / configuration effort as well. They are NOT fully 'ready made'! When will software engineering mature to produce all 'ready made' products meeting business / functional requirements, talking to each other without integration issues? Not in the near future. Having all 'ready made' software systems to run a business - is that possible? Is that a good thing to do? These are open questions.

References

1. Philippe Kruchten, The Rational Unified Process: An Introduction, Addison Wesley, 2000.

24 April 2002

Last updated on 10 May 2002

Last updated on 22 July 2006