BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Software – Is it "Engineering" Yet?

Software – Is it "Engineering" Yet?

Bookmarks

At the GOTO Amsterdam 2015 conference Mary Shaw talked about progress towards an engineering discipline of software. She explored what it means to have an engineering discipline, how far we have progressed toward having one for software, and what can be the next steps.

According to Shaw the characteristics of engineering are:

  • limited time, knowledge, and resources force decisions on tradeoffs
  • best-codified knowledge, preferentially science, shapes design decisions
  • reference materials make knowledge and experience available
  • analysis of design predicts properties of implementation

Engineering evolves from craft and commercial practice through interaction between commercial practice and science, especially through codification of practice. Commercial practice in turn depends on production and management techniques. Exploiting technology therefore requires both management techniques and a body of systematic codified knowledge.

When engineers make design decisions they want to be able to predict what the properties of the product will be. Engineering implies that you will take confident decisions of what your systems will do.

Engineers don’t rely fully on science. If established science is not available they will look for experience or other things that will help them to decide.

Shaw uses civil engineering as a model to understand software engineering. When the Romans were building bridges, learnings from the repairs were incorporated into the design of next objects. They made empirical progress via failure and repair said Shaw. Their process was not science based but experience based, decisions were made based on what they knew worked. It took until 18th century to develop general theory based upon formal analysis that supports building bridges. Nowadays the use of software for automated design is required.

Shaw defines engineering as "creating cost-effective solutions to practical problems by applying codified knowledge, building things in the service of mankind". She presented a definition of software engineering that refined the general definition of engineering:

The branch of computer science that creates cost-effective solutions to practical computing problems by applying codified knowledge [for] developing software systems in the service of mankind.

According to Shaw software is design intensive, manufacturing costs are low. Software is symbolic, abstract, and constrained more by intellectual complexity than by fundamental physical laws. Software is not that much limited by what computers can do, there’s a mental limit on what can be made by humans.

The term software engineering was first used in 1968 NATO conference. It was intended to be provocative to make people aware of the problems that were being faced in software development.

There has been a lot of effort over the years in software development methods. This established the production methods that support commercial practice. However, it did not establish the codified basis for technology that is required for engineering practice, said Shaw.

Science is driven by commerce, scientist are responding to solve commercial problems. For instance, to be able to develop large systems architectural patterns were invented and model checking has been developed to design systems with large state spaces.

Software architecture is the principled understanding of the large-scale structure of software systems as collections of interacting elements. It emerged in the 1990s from informal roots, initially by codifying the common informal vocabulary for software system structures, based on types of components and connectors. It now provides guidance for the explicit design choices that bridge from requirements to code.

Shaw questioned if software development has become engineering, by checking the characteristics:

Characteristics of Engineering (Shaw)

According to her we are not there yet. She showed headlines from recent major incidents with software on health care, safety and welfare.

The greatest need for an engineering disciple exists for software systems that are fully automated and are operating unattended and where the consequences of failure are catastrophic. Examples are nuclear safety devices, medical implants, self driving cars and stock trading programs. The need for engineering in software depend upon how serious the consequences are when things go wrong and whether human beings can take action in time to minimize the consequences says Shaw.

Things also tend to move. When automation increases the opportunity for oversight goes down, which increases the need for software engineering in developing systems. Software engineering will have to keep up to satisfy the increasing needs.

There are lots of casual developers said Shaw. She quoted the stackoverflow 2015 developer survey which states that "48% of respondents never received a degree in computer science". There are even more people who are not principally software developers but who develop computing applications such as web pages, spreadsheets, and small databases. The computing industry has not done a very good job of supporting these people for whom software development is a secondary activity.

"The greatest need for engineering is in the most critical applications" said Shaw. We are in some respects an engineering discipline, but we cannot yet consistently achieve a level of practice that assures computing systems of a quality that satisfies the social contract associated with engineering. We need to continue to infuse scientific and codified knowledge into design and analysis of software.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • No

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    No

  • Re: No

    by Richard Richter,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Ah, someone faster than me. If we want to be "clever" we can even say: Yes and no.

    Funny thing is that the projects that applied most of the developed engineering practices (enterprise software with any kind of waterfall in silo-based organization) are probably least successful. Building a SW analogy of the house - that we can do already. Building something like Burj Khalifa... and so quicky! - no way.

  • You cannot apply engineering to everything

    by Javier Paniza,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    We could apply engineering to music too. Have you listened Xenakis?

  • The usual false dichotomy rubbish

    by Gerhard Kessell-Haak,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I have to say that I'm becoming increasingly tired of this question. To raise the issue as to whether software development is engineering is akin to asking whether "building with physical materials" is engineering.

    Research in software development has identified techniques, models, and methods that can be used to create products of quality and suitable reliability. The waterfall model that keeps on being quoted was introduced in the original paper as a method that should NOT be used (see “Managing the Development of Large Software Systems”, by Dr. Winston W. Royce, published way back in 1970). And yet we continue to read again and freakin' again that "it doesn't work". Of course it doesn't freakin' work - it was never meant to!

    Software is used in a staggering number of fields, and the fact is that most software development projects simply don't need the overhead of engineering; an artisan approach is perfectly acceptable.

    What is not acceptable is that most developers are not aware of these processes, and are instead lead along by so-called process guru's preaching that their way is the one true way. What is also not acceptable is that our industry then applies broken methods and processes to projects that do require a proper engineering approach, and is then surprised when things go awry.

    Rant over.

    Bah humbug.

  • Physics doesn't change, Hardware and Software constantly does

    by Hermann Schmidt,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    As opposed to engineering disciplines, whose virtues are based on understanding physics, the software business stands on ever changing and floating foundations. There are a couple of solid things we have learned, but nevertheless, we continuosly invent new ways to do the same thing. Not always because it is strictly necessary or useful.

    The physics we depend on is far abstracted. Capacity, throughput and latency is basically all we have. And that's just a little piece of the whole complex we call software development. The rest is more like social spirit, not physics :-)

    The software industry has become a throw-away industry like typical consumer-oriented industries today. New shiny products need to be sold. Old products need to go. The "innovation" speed has become ridiculous.

    A bridge, a Mars Lander, a nuclear plant are not consumer products. Most software products are.

    So, no, we generally can't be compared to classic ("honest") engineering. Especially the over-stretched building construction analogy doesn't fit at all.

  • No, it isn't

    by Charles Gallo,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It won't be Engineering until the department head (or whomever is technically responsible) has the LEGAL requirement to sign off on the code, and is putting his legal and financial skin on the line, and the LACK of said signature prevents the code's release to the public (think the stamp/signature of a Civil/Mechanical engineer puts on his work). When any Sr Developer in the stack can say "NO, I won't sign" and it stops the process, LEGALLY, it isn't engineering

  • Engineering is about exposure

    by Skip Sailors,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There may be many who do everything an engineer does, but behaving like an engineer is not enough to be an engineer. This article is about if the industry has the character that would support an engineer. Engineering is about shifting responsibility for work product from the owners of the organization producing the product to a group of people who take responsibility for design, creation, and delivery of the product. If a Union Pacific train explodes in Chicago, killing thousands, you don't arrest the CEO of UP for murder, you arrest the engineer(s) who built the train. In exchange, the CEO of UP is not allowed to tell the engineers to do anything that will put them in that position.

    There are, as far as I know, no such agreements between owners and programmers. There may be people who act like it, and this is laudable, but acting like an engineer is not the same as being an engineer.

  • .

    by Skip Sailors,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    .

  • It won't be for some time

    by Will Hartung,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Not because it can't be, it just won't be.

    There's simply no requirements for it.

    The real story of the lack of engineering that we hear about today is security lapses. All these hacks that come through in the complicated software systems we have today.

    The funny thing is of course that it's not as if actual, "engineered" hardware is any better, rather it's just not as easy to do.

    Save for few exceptions, the users don't want engineered software, and the developers don't want it either. Because it's a lot of work. The users think they want it, but when presented with the costs and timelines necessary to actually do it? No, they're not willing to wait or pay for it.

    Developers don't want to do it simply because it's not very fun or interesting work. As we can see from the over abundance of specifications, documentation and unit tests in world today, these aspects of system design are clearly the most popular.

    The malleability of software, the ease of change makes endless feature requests, endless bug fixes, endless deploys the norm. If you see a software project that is stable and has few bugs, most folks will consider it a "dead project". With software, systems rarely reach a steady state on their own, rather money runs out. It's almost impossible to just leave software alone. It's almost never "this software is done", put it in a box, wrap a bow around it.

    Very difficult for those kinds of systems to be "engineered". That's why we focus on "architecture", architecture and techniques that deal with dynamic change readily, rather than on "engineering".

    Consider, a bridge is engineered, and does not have "technical debt". Because, once the bridge is built, it works, or it doesn't. It can be BADLY engineered, it can be pushed to outside it's limits, etc. But a bridge is a bridge. As long as it's carrying traffic, that's pretty much it. The closest that a bridge has to "technical debt" is how difficult the ongoing maintenance is, when it gets painted over each year, or whatever.

    Software is constantly in a state of technical debt, because it never stops changing. Consider, a video game burned on a ROM cartridge, this has no technical debt. Because once it's shipped, once the investment is made to burn 1M game cartridges, that's pretty much done. Whatever debt is left, is of no value, because it's unlikely anyone will ever dig in that code again. Rather, the developers will learn from it, and change their ways in the future.

    But a normal software system, which isn't burned in to a million, non-updateable units, we focus on debt, because we're always elbows deep in it. The patient is never off the table.

    There was a great observation once: That natural state of a racing motorcycle is to be disassembled. The bike is only assembled for the short time that the bike is at the track and being ridden, otherwise it's taken apart and tuned, and replaced, etc.

    Software is very similar. Always open to change. The difference is that software can run, and have it's wheels changed on the fly. Very difficult to engineer the entire system. Rather try to engineer the individual parts that you put in to it.

  • Dup, sorry

    by Will Hartung,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    .

  • Re: The usual false dichotomy rubbish

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for your reply Gerhard.

    You mentioned that we should be aware of the processes that we use, and use proper ones. Wouldn't an engineering view help us in doing this?

    Ben Linders

  • Re: Physics doesn't change, Hardware and Software constantly does

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for reacting Hermann.

    My view is that engineering can help us to understand practices and processes. So even when circumstances are changing, customer needs are unclear, they can help us to find better ways to deal with that.

    Your thoughts on this?

  • Re: No, it isn't

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Charles, can you elaborate why in your opinion signing off software would make it engineering?

  • Re: Engineering is about exposure

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Skip, my Impression is that many software engineers take responsibility and want to develop quality products. If their software fails they take it personally and make it work, even if that involves long days and nights to do it.

    Are engineers taking engineering more seriously than managers? What do you think?

  • Re: It won't be for some time

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree with you Will that customers don't ask for engineering, although it might deliver them a better product.

    But I think it matters for the industry. Engineering should support them to do a better job. Faster and cheaper. That would matter to customers too!

  • Re: No

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Richard, I would like to challenge your thoughts. Agile software development has lot's of practices, like TDD, pair programming, CI, etc. Isn't that engineering too?

  • Re: You cannot apply engineering to everything

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Not yet but I will Google it and listen :-)

  • Re: No

    by Richard Richter,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    That's why I said yes and no. Agile, TDD and all the automation are definitely the way to go - and yes, they are clearly engineering practices (not necessarily killing any kind of magic or creativity the best people can still bring into the product). "No" part mostly relates to comparisons to other industries, typically construction engineering. There are just so many differences, that we have to come up with our own kind of engineering.

    But consider SW kind of Burj Khalifa. (BTW: never was at developing anything that big.) They could visualize it before they started. We virtually never can visualize what we really would create in the end, very rarely it is what was analyzed - and if it is, it often doesn't satisfy customers. (I hope we agree on these typical symptoms.) Except for the most novel kind of structures they know how to do it, there are little Galloping Gerties - how many do we have them in our industry? When they are in the construction phase, they may have pretty precise plans. Sure, there is weather and logistic problems, but it's not normal that it takes 2x longer and is 5x more expensive.

    I firmly believe in growing software (I was 8 when Brooks mentioned that in No Silver Bullet), of course with any tool and discipline support we can get. But SW are still projects. Try Agile all the way to the customer, when the customer is ministry of something in the country where I live (Slovakia). And then there are fail rates of SW projects where agile is not doing that much better according to some research.

    I think there is a way, but it must be our way, not other engineering way. We may adopt the good parts (lean from manufacturing is a good example), but the rest is upon us. And we will be misunderstood by people who actually lead the projects. Because "growing" is scary for them. They want plans 5 years ahead with ROI figures. They want blueprints (construction again)! Because that's their idea of SW engineering. Our part? Just get as good as you can within the areas where we can (craftsmanship), learn the tools and soft-skills, and sometimes we can try agile within non-agile company. And we can try to persuade.

    And there is more, but it is tl/dr already and you know most of the stuff from your position, I'm sure. :-) But TDD and automated continuous anything surely are our most engineering-ish practices and the way to go.

  • Re: Engineering is about exposure

    by Skip Sailors,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It is true that many developers try to take responsibility for their work. There are also some shareholders that expect this level of commitment. That is good. My point, though, is that the social contract of engineering is codified in civil and criminal law. If a building collapses, I can sue the engineer that built it, possibly have him arrested. I can't sue the company that hired the engineer, as long as the company followed the rules and abided the engineering decisions made.

    The software industry has taken a different approach. The industry absolves itself of any responsibility for errors made. Engineers are not needed to take legal (and ethical) responsibility, because nobody takes responsibility. There can't be engineers in this environment. At best, we can have people who act like engineers.

  • Re: No

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for your extensive reaction Richard!

    I too find that the analogies with other engineering disciplines often do not help us. There are some general engineering aspects that can help us though. I'm thinking of the way that we learn and build an understanding of something. Like designing experiments, stating a hypothesis and verifying it or coming to the conclusion that it isn't valid.

    I also believe metrics can help us. If you can define a measurement for something, you have some understanding. And discussing measurement results helps to increase that.

    Finally I think that we are never done with learning, so I always encourage people to reflect. See how things are going, decide on what you want to do next and how to do it.

    Is this engineering? I'm not sure, but I think it helps us to do our wiek professionally.

  • Re: Engineering is about exposure

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for explaining your point Skip.

    I tend to disagree though. In recent years we have seen large projects, non software, that failed to meet the requirements of their stakeholders. For instance infrastructural projects. They were followed by law suits. In my opinion the focus has been on protecting the guilty from being fined or sent to jail. But did we learn from these failures? Are we doing better now. I have some doubts there.

    That is why I think that legal responsibility won't help to become better in developing software.

  • Re: Engineering is about exposure

    by Dean Schulze,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Skip Sailors - When has an engineer ever been arrested over an accident?

  • Re: No

    by Dean Schulze,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Ben Linders - Practices like TDD, pair programming, and CI are fads. There are no metrics showing that they work better than anything else. The consultants pushing them hate when someone mentions metrics because they don't have them.

  • Engineering or discovery?

    by Dean Schulze,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A former colleague was a nuclear engineer turned software developer. He said that enterprise software projects are more like commissioning the Lewis & Clark expedition than like building a bridge. When you build a bridge you at least know what the variables are going to be. In large software projects you don't know what you are going to run into when you start.

    The number of unknowns and the complexity (e.g. number of states involved) are one major thing separating software development from other forms of engineering.

  • Engineering or discovery?

    by Dean Schulze,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Sorry for the dup. The software for this discussion forum is poorly "engineered". It appears that your posts haven't succeeded when they have.

  • Re: Engineering is about exposure

    by Skip Sailors,

    Your message is awaiting moderation. Thank you for participating in the discussion.

  • Re: No

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Is that true Dean? I've seen several studies on the benefits and ROI of agile practices, there is data although I have to admit that it is limited.

    I collected some Evidence of Success of Agile Projects and Capers Jones investigated software development practices and quantified their results in Evaluating Agile and Scrum with Other Software Methodologies. More recently there was a study by Larry Maccherone together with the Software Engineering Institute, see Quantifying the Impact of Agile Software Development Practices.

    Measuring software practices, agile or not, is hard. That is the main reason why there isn't much data. My expectation is that an engineering approach would help us to get better insight in what works when, and help us to more effectively apply practices.

  • Re: Engineering or discovery?

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree with you, we don't know the "variables" of the software development process well enough to decide how to do it in a given situation. That makes it difficult to decide which practice to apply when. Which in my opinion is something that an engineer would they. They know what works when.

    Do you agree Dean?

  • Re: The usual false dichotomy rubbish

    by Gerhard Kessell-Haak,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Firstly, a quick apology for the title of my response; I got a little hot under the collar as I've seen this question so many times in my career, and I strongly believe that it is the wrong question to ask.

    Unfortunately, it'll take me at least several pages to explain why this is the case, so I'm not even going to try here ...

    Coming back to your question though; yes, an engineering view certainly helps - but only for a limited number of cases (such as those identified by Mary Shaw). The fact that it only applies to a limited number of cases is partly the reason why I think it's the wrong question to ask.

  • Re: The usual false dichotomy rubbish

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I've asked Mary to join the discussion since it is based on the write-up of her session. Think it would be better if she answers you on this one.

    One question that I have to you. If "engineering" is the wrong question to ask, what would be the right one? What can help us to do a better job?

    BTW: If you want to write "several pages" on that, feel free to contact me, so that we can explore the possibility of writing an article on it for InfoQ.

  • Re: No

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    To add to my "no". How about all the people coding in MS Access, Excel, SharePoint, SSIS, [any Stored Proc language], [any coding in a window system language] or etc? They are writing software/code/whatever you want to call it. And there is a TON of it. Some companies run on Excel. Will those people ever come close to be considered engineers? (No)

  • Re: No

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks Mark for your addition. Mary also mentioned the people for who programming is a secondary activity, for instance those who maintain excel sheets and webpages. They will not call themselves software engineers, I agree with you on that.

  • Reaction from Mary Shaw on the comments

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Mary has sent me her reaction by email after reading the comments. Here it is:

    =============================
    It's hard to know whether "no" means "we don't have engineering disciplines but need it" or "I'm happy just hacking around, leave me alone"

    Some of the comments seem to assume that engineering is antithetical to creativity. Nothing could be further from the case. Engineering demands commitment to finding cost-effective solutions, and this often demands creativity. However engineering also demands respect for and knowledge of solutions that have worked or not worked in the past. Calls for "artisan" approaches are too often excuses for not learning what developers before you have already discovered.

    Comments about process and methodology are largely off point. Any kind of development method can be a means toward the end of quality in software, but the process itself isn't the objective. Rather, engineering is about systematically applying established knowledge to the task at hand for the purpose of getting a cost-effective result.

    Security isn't like pixie dust that you sprinkle on a mess of code after the fact. Security needs to be built in from the ground up, and that requires systematic design and diligent application of established knowledge. There is no excuse any longer for well-known vulnerabilities such as SQL injection.

    But security isn't the only area where engineering is required. The headlines regularly show that software that should have been engineered was not. Toyota recently settled a class action lawsuit about electronic throttle control for over a billion dollars, and much of the case was based on poor engineering of software.

    Reliability and performance also require engineering approaches. You should be able to predict such properties from the design and architecture, before you begin coding or hooking up components.

    Even noncritical systems can be brought to their knees if the developer doesn't understand the reliability or performance implications of his decisions. A friend of mine hosts a web site for a small organization. Someone in the organization built the site with an artisan approach; he recently complained about dreadfully slow load times. Inspection of the site showed 75% of images larger than 200MB with frequent refreshes, typical pages of 350B studded with plug-ins and additional file downloads, and anticopy software that clears the clipboard every 20ms. If the developer had thought about typical bandwidths of his users and done a little arithmetic, he would probably have been more restrained -- and he wouldn't be asking to split the web site into two separate sites in order to "solve" the problem.
    This isn't a "false dichotomy" because there's no dichotomy or forced choice in play. The question is to what extent we have achieved a level of practice that satisfies the promises implicit in calling the discipline "engineering'.

    A large part of our problem is that we aren't consistently using the knowledge we actually have. This is partly because too many people would rather re-invent than refer to the prior art. And it's partly because we're pretty bad at capturing that knowledge in such a way that people can find it. We can't call it "engineering" until we (a) have an achievable level of practice that satisfies the social contract of engineering and (b) we regularly achieve that in practice.
    ==================================

  • Re: Physics doesn't change, Hardware and Software constantly does

    by Hermann Schmidt,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Well, in my opinion, THE engineering does not exist. Let me look at it from another angle. When I design software, I let myself be guided by the constraints of a project. A good SW architect puts emphasis on the important constraints and pushes the less important ones down in the priority list.

    We can learn from all disciplines, which have similar constraints for a specific project. Doesn't even have to be a technical discipline. Now, to successfully produce a consumer product for example, it makes more sense to look how other consumer products are made.

    Take a TV set for example (a know a little about them, because I repair them as a hobby). They are engineered, yes, but they also show signs of budget restrictions everywhere. The engineers would have loved to do it better and more robust, but the market is tough. And the devices do fail. Some randomly, some series even have 100% failure. I can see similar constraints in the software projects I work in.

    If the project is a one-time thing with no second chance (hardware worth millions gets lost or lives are at stake), the constraints are radically different. Projects need to be run way different. More formal, much stricter, slower.

  • Re: No

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    And those people are the ones who need "certification" the most. They make the biggest messes and cause the most issues. Yeah, someone might not die but ... i know (guess how) a VERY LARGE company that was using MS Access and Excel to manage the payments they received. They had like $1 million dollars they didn't know what group to allocate to. LOL.

    The big problem is where is the line drawn? People will bypass rules anyway they can. They already do it today by using end user tools. They are not really coding (yeah right) and thus don't need to use Change Management or the SDLC or... . And what is funny is that the very same people in charge of these things are using tools to bypass their own process.

  • The Software Industry needs Standardization

    by Rollin Shultz,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Right now software development is very academic and political. Everyone and their brother who thinks they no better than the people they learned their craft from, wants to go down in history as the one who wrote the ultimate language to beat all languages.

    In Mechanical engineering there are standards like SAE, ASTME, and others. This prevents such things as fasteners, welds, tubes, angles, channels, and other items from getting out of hand in respect to sizes and threads etc. You don't have 100s of professors and professional writers all vying for their ideas to become the New hot idea. The manufacturers and engineers worked together realizing you don't need 50 different kinds of railroad rails criss crossing the country and then different trains to run on them, because it would cause more trouble not less. Just imagine of the transportation industry was like the software industry of today.

    How many languages are there today, that are based off the original "C" language, and why make so many to solve some small problem or attempt to make the language self writable and secure instead of teaching programmers to be responsible and learn the basic rules. Instead of inventing many languages based on "C" very good processes could have been developed to enhance programmers abilities, and tools, such as libraries could have served as the fasteners in mechanical design. A bolt on approach could be developed, instead of re designing the engine just for some small performance increases.

  • Re: No

    by Will Hartung,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Absolute nonsense. The choice of tools and materials isn't what deems an engineer. Are most folks using Access et al end users? Of course. But that doesn't mean sound principles of design can not be applied by folks leveraging these tools.

    The down side from an engineering perspective of using these tools is simply risk. The foundation that the software is built upon is so large, it presents a large area of uncertainty to the point that many may well not trust it, since it can't be reliably tested. I once wrote a software system, in house, in MS Access. I chose it consciously, and the net result was a solid piece of work. However, for some never to be determined reason, it would. not. install and run on one persons workstation. The myriad of dependencies and options that manifested on her machine made the system unreliable. "Works here, must be you." and the aspects of where it was failing were outside of my control, as they were deeper in the system than just what I wrote.

    When you buy a piece of junk "imported from china", odds are very good that it was engineered to be a piece of junk. Engineered for a limited work life, with a focus on cost reduction more-so than applicability. Or it was actually engineered to the limits of the function of the material, and just "seems cheap", even though it fulfills its actual role quite well. It just doesn't "feel good" in the hand, or some other non-requirement.

    But the mention of MS Access brings up another reason engineering in the large does not happen in this community. If you read most every single license for software, one of the first things it tells you is that the software isn't warranted to do anything at all. Vendors may as well put "If this software doesn't cost you untold time and money in lost data, rejoice, because that's just dumb luck."

    How can I engineer against software that provides no guarantees itself?

  • Re: The usual false dichotomy rubbish

    by John M,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In the public sector, which is the life blood of my career here in the DC Maryland Virginia area, these principles, practices, protocols, techniques are very important.

    The government wants to plan at least a year in advance, and yet in software things don't always allow that. Educating the general populace as well as other developers helps us achieve a common language and understanding of expectations.

    But in the public sector, I would say the majority of the projects fall under that "limited number of cases" you referenced. And that has a huge impact on the government and then the citizens.

    I was on several projects where the government needed X, Y, and Z done in order and on a certain timeline. We had to educate them on the Agile principles and continuous delivery workflow (despite them refusing CD, while demanding new releases of older version of the software, essentially CD on an unpredictable schedule).

    And there's always the issue of more people means more work done in a smaller amount of time. You wouldn't expect that on a construction job, because those people need to be brought up to speed as any new employee should.

    Maybe in the private sector such cases are smaller, but government projects need an engineering approach in order to address security, stability, accessibility, and maintainability. Public sector projects are often dealing with, if not directly accessing, the support of sensitive data critical for a government agency's work, a mission, and or the government's communication with and within the Intelligence Community.

  • Re: The Software Industry needs Standardization

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks you for sharing your thoughts Rollin.

    Standardization can prevent reinventing the wheel. I see standardizing, sometimes based on industry standard product by providing add-ons or libraries, sometimes as an initiative driven by the industry. But I tend to agree that it is done very little.

    Some say that standardization limits creativity, which is important to developing software solutions for the problems that need to be solved. Rollin, what are your ideas about that?

  • Re: Physics doesn't change, Hardware and Software constantly does

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, we have to work within constraints, which is a fact of life. Good engineering tries to find the best solution that will work given the circumstances.

    Hermann, you stated that projects need to run "more formal, much stricter, slower". Agile software development takes a different approach here, with professionalism, less (but clear) rules and fast feedback. Is Agile the wrong answer to solve our problems?

  • Re: Reaction from Mary Shaw on the comments

    by Gerhard Kessell-Haak,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Please thank Mary for her very considered reply. She considered all responses, so I'll focus on those that relate to my original point, which is that the wrong question is being posed as to whether software development can be called engineering (yet), and that to ask this question is to force a false choice.

    Mary notes that we "... can't call it 'engineering' until we (a) have an achievable level of practice that satisfies the social contract of engineering and (b) we regularly achieve that in practice." I would argue that, after 70-odd years of research and halting progress we now know enough about software design and development to achieve this. There are countless research papers on estimation, development practices and methodologies. Seminal books have been written on software and system architecture and good design practice based on the authors' experiences and/or research background. The OWASP organisation continues to do good work on disseminating information to ensure software is developed in a secure manner.

    This information is out there, it is being taught, and it is being practiced by a small minority of software development teams. Consequently, well-trained and practiced development teams can already engineer (yes, engineer) good solutions that appropriately consider the constraints and requirements.

    Why, despite good practices and codified knowledge being out there and available, do we continue to have cases such as the example given by Mary? I think the answer revolves around a number of factors -

    <ol>

  • Software is abstract. Unlike the construction industry or civil engineering, where large complex projects *look* large and complex, the public can't see the difference between building a dynamic website in PHP that can handle 5 concurrent sessions, and one that needs to handle 30 million concurrent sessions spread across the globe. John Doe would never believe that he could build a skyscraper or massive suspension bridge after attending a "Learn concrete, steel and structural load mechanics in 21 Days" course.

  • Programming (not software development) is easy to learn. I taught myself when I was 9 back in the eighties on a programmable calculator, learnt Z81 assembly language when I was a little older, and I'm sure there are many who are possibly reading this now who were much younger. Clearly you don't need to be a genius.

  • The Dunning–Kruger effect - see en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_ef...

  • The tendency for software development to be driven by trends, not evidence, much like the fashion industry. This is probably due to a combination of (2) and (3).

  • </ol>

    Combine (1) - (4), throw in a lack of enforced oversight, and you have a recipe for disaster for projects where an engineering approach is required for its critical elements.

    So, given these issues, what can we do to ensure that the products presented in the top-right quadrant of Mary's slide on page 80 of her presentation are produced using the rigour that they require. Surely that is the question?

  • Re: Reaction from Mary Shaw on the comments

    by Gerhard Kessell-Haak,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Oops - that should be "Z80" ...was thinking about the old ZX81 ;-)

  • Re: Physics doesn't change, Hardware and Software constantly does

    by Hermann Schmidt,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It is not an exclusive trait of engineering to find the best solution for the given circumstances. Everyone with at least a minimum of competition out there must do that. It is the nature of the constraints, which I find interesting, not so much a specific discipline.

    Is Agile our saviour? Heck, I dunno :-) I know for sure that short feedback loops and small amounts of work in progress (buffers) are helpful. When they are possible. A bridge as such has no feedback loop. The design process has, the final product has not. Once deployed, the bridge is finished. No loop. No user feedback.

    SW is different. It needs feedback. Along its entire life. It emerges incrementally, if done right. There it is: the constraint, which changes the whole game.

  • Re: Reaction from Mary Shaw on the comments

    by Hermann Schmidt,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The tendency for software development to be driven by trends, not evidence, much like the fashion industry. This is probably due to a combination of (2) and (3).


    Yes, yes, and yes!

    Programming (not software development) is easy to learn.


    Small-scale programming is (Fibonacci numbers, calculating PI, what have you). Large-scale programming is difficult up to extremely difficult. Not everyone is fit for this job. That's a fact. These two very different tasks are too often confused by management people. They don't understand.

  • Re: No

    by Dean Schulze,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Ben Linders - The InfoQ article you refer to relies primarily on a paper by Rico on "Agile Project Management" and the Columbus study on agile software development.

    The Rico paper is about project management, not software development. In fact the word "software" does not appear in that paper (except in the title of one reference). He does not say what makes a project agile. That paper is irrelevant to software development.

    The Columbus "study" makes some dramatic claims for agile software development, but lacks specifics. How many "agile" projects did they compare to the projects in the QSM database? Were any of the projects in the QSM dataabase also "agile" projects?

    The biggest problem with the Columbus article is that they don't say what an "agile" software project is. Is agile software development Extreme Programming? Is it XP2? Is it TDD? Is it pair programming? Is it Scrum, Feature Development, or Lean? I remember a quote from when XP was in its heyday: "If you are not doing all of the XP practices, you're not doing XP." (What ever happened to the XP craze anyway? If XP was as good as the hype it would have won dominant mindshare.)

    Here is a quote from the article showing the lack of any definition of what an "agile" project is:

    "Early results do show that concepts embraced by Agile deliver remarkable results in areas of compressing a schedule and reducing defects. Some of these approaches include acceptance-test-driven development (TDD), pair programming, and co-location. But even participants that had not adopted all of these techniques achieved better-than-average results.""

    A big emphasis is put on co-location, but I have not heard co-location mentioned as an agile practice before. Is co-location a new agile practice?

    The kind of metrics we need would compare the various practices like TDD, XP, pair programming, and co-location to each other and to traditional practices that don't use any of those. The Columbus study doesn't say which practices the "agile" projects used. If a project used TDD, pair programming, and co-location, which of those practices was responsible for its performance compared to the QSM database? None of these issues are addressed in this paper. The Columbus "study" isn't really a study because it doesn't clearly identify what it is studying.

    The Columbus study claims 75% fewer defects and 30% quicker schedules compared to the QSM database. Those are dramatic claims. If they were true in actual practice businesses would be jumping all over the Columbus "agile" method, except that the paper doesn't say what it means to be agile.

    The Columbus paper shows how far away from being an engineering discipline software development is.

  • Re: No

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There isn't am abundance on studies that cover results from agile as I mentioned earlier Dean. And yes, you can debate them. For me that's an indication that we are not at the engineering stage.

    I have listed studies that I know in a (Dutch) blogpost on my own website: www.benlinders.com/2012/agile-werkt-maar-is-daa...">agile werkt.

    The only person I know that looked at agile practices is Larry Macherrone.

  • Re: Reaction from Mary Shaw on the comments

    by Gerhard Kessell-Haak,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Small-scale programming is (Fibonacci numbers, calculating PI, what have you). Large-scale programming is difficult up to extremely difficult. Not everyone is fit for this job. That's a fact. These two very different tasks are too often confused by management people. They don't understand.



    Which is why I separate programming from software development (or software engineering, for that matter). Programming, to me, is just the ability to speak the language. Creating a complex application or system, on the other hand, is akin to writing a novel. Just because you can write an English paragraph doesn't mean you have the skills to create a great English novel.

  • Re: Reaction from Mary Shaw on the comments

    by Hermann Schmidt,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Totally agree. I just wouldn't seperate the two terms as much. That could be too confusing in discussions. A 200 lines program is also software, thus, producing it can be called SW development.

  • Re: No

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Something went wrong with the link. This is the correct one: www.benlinders.com/2012/agile-werkt-maar-is-daa...

  • Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    BT