Youry's Blog

Youry's Blog

Can Engineering approach be used against of SW Development?

leave a comment »

This is very interesting and important question related to the SW Development and even to the Information Technology. I’ve met a lot of IT professionals and even SW Developers, who believes that Engineering approach never can be used against of SW Development. I couldn’t find a good and short answer for unbelievers. Just today I’ve read a post at ACM, which gave very short and good example(s)/answer(s) for this question. I did copy with the reference for this post at ACM:

“I have to disagree with you somewhat, Putcha. After a 40 year career in two major engineering companies, I would say that, first of all, the engineering approach to software development – what I would call genuine software engineering – DOES work and very well – but hardly anybody wants to use it because it is more expensive and time consuming during the product development phase. [It actually saves money over the long term and we had data to prove it.] Time after time I’ve seen people fail to use good engineering techniques with software because they can get the software running faster and cheaper (and with a lot less quality and a lot higher maintenance cost) by using other techniques. Or to put it another way, good engineering techniques produce excellent software, but hardly anybody uses them.
Secondly, on the projects I was involved in where they did good software engineering, the software was superior to the other engineered aspects of the system because the other engineers (mechanical, electrical, and systems in my case) were generally not as well disciplined as the software people. On several occasions, software came to the rescue of mechanical or electrical systems that had problems due to poor engineering discipline. An interesting example is the NASA space shuttle program. They never had a mission failure due to software but had several failures due to hardware, some of which were immensely catastrophic. The group that did their software (originally part of IBM, later a spin-off) used very competent software engineering techniques. As a simple example, when they found a bug they would trace back to the cause of the bug (not the coding error but back to the root cause – the requirement or design or process or training or other problem that led to the bug) and then would extrapolate forward to identify other likely bugs stemming from the same root cause that they had not yet found – and sure enough they would often find some. How many software development organizations would be willing to go to such lengths?” Posted by Dennis J Frailey on 14 July 2012

Another Gem from the same author, posted on 15 July 2012 (see my highlights in his text”  :
“You’ve identified a really important point: it depends on the skills of the developers. And, frankly, there are quite a few people in software development who are not as skilled as they like to think they are. Just because you can write good code and are well paid does not make you a truly skilled and experienced professional. And just because you are a skilled and talented and experienced professional in one field does not necessarily make you such in another. An good example is the software produced in research labs – often brilliant in concept but brittle and unreliable in execution.

Skill depends on education, training, talent and experience. Few have all of these. To get back to the original discussion, when I say that software can be engineered, I base my comments on my experience as well as that of others. I’ve been fortunate to have seen first hand what good engineering processes can do. And I know others with similar experience. I already mentioned the former-IBM group that did the space shuttle software. As another example, I know a person who worked for many years on software for nuclear missiles. She can tell you many ways in which the quality of modern software has deteriorated from what she did back then. The stuff she and others like her wrote 20-30 years ago is still in use, still highly maintainable and still functioning safely. By contrast, many modern products have software that is almost impossible to maintain because of such problems as heavy dependence on design and code generation tools that are no longer supported by their manufacturers, poorly documented design and code, and automatically generated code that has been modified during maintenance activities, making it all but impossible to re-generate.

One of the characteristics of the more effective software engineering processes is that they don’t depend so much on highly talented and skilled developers. Think of the difference between a snazzy, high performance automobile that needs extensive maintenance and a skilled driver vs a boring but highly reliable, low maintenance automobile that anyone can drive. The former may get all the attention but the latter is what you want for reliable transportation to support day to day living. And it takes a lot of talent and skill to design and build that boring but dependable car – but the talent and skill are more focused on making the car manufacturable in high volume, efficiently, by people with average skills. What good engineering processes do depend on is well trained and educated people – especially in software engineering where the tools and techniques are evolving so quickly. In my experience this is the first place where companies fail. Training is viewed as as an overhead expense that can be skimped on when money is tight. Things start to deteriorate because the new employees lack the knowledge and don’t get the training. This is why I have devoted much of my career (and now my retirement years) to promotion of better education and training in software engineering.

When “professionals” tell you that software cannot be engineered, I tend to conclude that they have not had the opportunity to see well engineered software development in action. That’s not surprising because you so seldom see it. But I’m not saying there’s no value in more contemporary approaches. There are nuggets of brilliance in some of the agile techniques so popular today. Two of my favorites are “test first” and “integrate every day” (techniques that happen to have been around long before agile came along). But when you evaluate cases where agile techniques fail, you generally find that the practitioners lack the training and/or discipline to apply the techniques properly, or that the managers and technical leads applied the agile techniques to problems where they were not appropriate (the “if you have a hammer, everything looks like a nail” effect).”
Posted by Dennis J Frailey
Go to complete discussion:


Another interesting post from ACM on 16 July 2012 (I cut some personal information):

“I left Bell Labs in 1996. At that time each project selected a the computer language, design process and methodology appropriate to their project. Most projects, especially critical ones, had to pass through two Architecture Reviews to discover holes in their approach. Mostly requirements short comings were found.

There was no single approach appropriate for all projects. There were many of them in many different business and communications areas.
Larry Bernstein NJIT Software Engineering Professor “


Written by youryblog

July 14, 2012 at 8:11 PM

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: