Comments

(newest first)

  • someone | Thu, 23 Feb 2017 21:46:26 UTC

    "So, how do you introduce agility into software-engineering methods?"
    
    Waaaaaaaiiit a minute!  As the author has established, software "engineering" is yet another term thrown around in the "IT" industry to relabel the same old thing into something it is not.  Just look at all of the job tittles that could all be done with essentially the same training. Now anything remotely related to technology is "engineering" 
    
    Anyone can start calling their field "engineering," except those who work in fields that actually are related to engineering.  That is, where you actual have a core of knowledge and tools based in physical science and math- an actual defined discipline that someone could actually learn.   
    
    An electrical engineering writing code that is part of a system and is validating and testing the system in a formal way is doing the closest thing to software "engineering" 
    
    
    As the beginning of the article points out programming software is NOT engineering- so stop right there and do not misapply "engineering" again by saying "software-engineering methods,"  as there are none.  Quality programming methods, reliable programming methods, or whatever, but in truth NOT engineering.   
    
    It is amusing that there is such a disconnect between programming and computer science- yes, you need to "get it done"  but then do not try and fool us into thinking what you are doing is "engineering,"  and that you can say anything about the reliability of your product with any level of certainty.   
       
    If the formal approach in computer science is too hard for the software "engineers," and is tossed aside for yet another project management scheme, you are moving AWAY from engineering.  
    
    What is wrong with calling the job what it is- software programming???
    
  • David | Mon, 29 Dec 2014 18:54:25 UTC

    I think the bigger problem is that proper software engineering (using consistent, repeatable processes to construct software with minimal defects) requires time and planning that current development management simply is not willing to accommodate unless absolutely required by the use conditions. It costs more to do it right, and in this world, greater cost equals failure. 
    
    If we can address that problem -- by putting a premium on operating correctly vs minimum cost -- we might make some progress on this issue. Until we do, the method used to get to the finish line is pretty much irrelevant. 
  • Luis Orduz | Tue, 23 Dec 2014 04:27:13 UTC

    More than in building better software, this approach to SW Engineering seems more concerned in building better methods to build better Software. It oddly reminds me of abstraction or indirection levels.
    I think the Essence framework has merit, however, and better-built software will be, at least, one of its end products.
    But building good software is still more than (or not exactly) engineering, it will always have something akin to art involved so there's doubt about whether Software craftsmanship will evolve beyond that, or whether it even can evolve beyond that. Maybe the answer is to stop trying to see writing Software as something that can perfectly fill the engineering mold in the way something like construction does. Who knows.
    Nevertheless, more organization and consensus would definitely improve the situation for everyone, specially with all the different methodologies and their conflicting approaches and followers. So, even if SEMAT's approach doesn't catch on (here's hoping it does), something with at least a similar goal should.
  • Rafael Anschau | Mon, 08 Dec 2014 05:21:28 UTC

    I have found formal methods to be the best bet so far. Modules with pre/post conditions specified at the appropriate level of formality make them much easier to understand and modify and hence to work with. The fact that industry doesn´t use them, shows that the problem is with industry, not with the methods. No engineering discipline would accept working with undefined methods, but here, defined methods belong to CMMI level 3, while 80% of organizations operate bellow CMMI level 2!(McConnel, Software project survival guide). Whenever someone talks about formal methods being "to hard" I imagine a calculus enthusiast -just after calculus has been invented- talking to engineers about the potential of calculus to engineering, just to hear: "Oh, that´s too hard, it´s not practical." Software engineering will be engineering when all organizations operate at CMMI level 3 and use defined methods(formal and informal)  which by then should be simply called "the norm" not an exotic state of affairs well above average. 
  • Bob BInder | Sun, 07 Dec 2014 19:30:40 UTC

    The notion that whatever software engineering is should be informed by what works in practice is of course reasonable. But so much of software is mediocre at best and very often a dangerous money pit, as studies of technical debt bear out. So, why should we look for inspiration to those responsible for such uneven results?
    
    The identified problem is that "big design up front" and its henchmen trample software artisans, who would save the world if only given the chance. But the best available evidence indicates that Agile projects and their enshrinement of ad hoc development are not significantly better in any respect than the "waterfall" bogeyman. If anything, the value of the Agile point of view is that it assumes we're not as smart as we think, and therefore ought to take small steps to avoid big stumbles. But that's not a new idea. And, as software is the most complex technology the human race has produced, any claim to a "paradigm shift" should have a cogent and proven technical story. Like the rest of Agile, the SEMAT story is technology-free.  
    
    I've long argued that making software is most like making movies. Both involve high levels of skill, creativity, and collaboration among diverse technicians and artists to produce a unique artifact http://robertvbinder.com/is-making-movies-like-making-software/ The producer-director model works well for organization. Like programmers, actors are the most visible and certainly critical to success. But it is pointless to argue about who is more critical. Weakness in any on- or off-screen role is sufficient to produce a bad result. Of course, we don't depend on movies to run our vehicles, sustain global communications, or to manage our energy, money, health, and food infrastructure. 
    
    So, while I very much laud the intention of fixing software's well-known deficiencies and acknowledge that the approach has merit, I don't see any reason to consider the claims of a "paradigm shift" to be more than self-serving hype. Instead of making grandiose claims, presenting evidence that SEMAT's approach isn't yet another concept looking for mindshare would be much more persuasive. 
    
  • Don O'Neill | Fri, 05 Dec 2014 20:16:22 UTC

    My experience is mainly in mission critical large scale complex software systems, and I find the SEMAT Essence Kernel and its Alphas simple yet sufficiently powerful enough to reason straightforwardly about the Alpha state transitions at this scale. In fact, SEMAT is a giant step towards coping with the complexity of software engineering projects. It truly represents the re-founding of software engineering. The profession and perhaps the world will owe Ivars Jacobsen a debt of gratitude before it is all over.
  • Ian Sommerville | Thu, 04 Dec 2014 19:29:27 UTC

    Comparisons between software engineering and other engineering disciplines are dubious in my view as, unlike, engineered physical systems, software systems are abstract entities that are not subject to the laws of physics. The link is to a talk I gave in 2000 making this point. 
    
    https://www.dropbox.com/s/bm5saq7tuya89h4/21C-SE-Challenges.ppt?dl=0
  • scaringella | Thu, 04 Dec 2014 11:34:44 UTC

    All wrong article .... Software is all about the tool, the language to use in order to reach a goal.
    Language is the only one tool in software. For each software to create the chosen language must be
    as close as possible to the perfect one for the goal. The requirements must only drive to the 
    goal then the language tool. Then let the coders, you know, the guys who really do the work, create the software and that's it. How a project is organised is not software it is management. Something every industry has to deal with. Developers use only one tool, language and if listen to carefully would choose the right tool for the goal. But this means either give them time to learn languageS or specialize them
    in a smaller and smaller sector of software. Then either have devs for each goal or buy devs time
    for each area. 
    The rest is either management tasks or bullshit to make devs do themselves management work and 
    of course not paid for it (in fact the real goal of all the agile madness). 
    
  • Ahmed Chicktay | Wed, 03 Dec 2014 15:49:48 UTC

    The construction industry has always been a bad analogy for software development, until this changes I think the conclusions will always miss the problem.
  • RJ | Tue, 02 Dec 2014 03:49:01 UTC

    "Software is, by its very nature, malleable and (physically) easy to change"
    
    Errr..  not really.  
    
    If by easy to change you mean 'I can fire up an editor and commit a change right now'.. then yes.
    
    If by easy to change you mean 'I can fire up an editor and commit a change WITH GOOD QUALITY right now'.. then absolutely not.  
    
    Software, but its very nature, is a very time intensive activity.  If quality of the deliverable is of ANY INTEREST AT ALL, then software must be treated as a very very expensive investment, and not as a cheap throw away (I've met WAY too many non-computing types that pick #2 in this list).
    
    And if experience has taught me anything, literally 1% of the entire base of software management understands this.
    
    Note that I started in the 1980s.. so I'm no spring chicken talking here.. 
    
    I was an architect for Oracle.. and am now senior technical for an industrial software firm.
    
    At this stage, I've become extremely skeptical of ANY method meant to make things better.  There is literally no respect paid to ANY software engineering methods at 95% of the software companies extant.  In most places, management looks to tooling to create better software, rather than looking to how things are managed.  I'd say its the inmates running the asylum, but I literally don't want to insult asylums!  Until we've solved the (questionable) leadership component of software, no method will see real success.  And that is unfortunately not something the ACM can address, since its those imperfect humans running the show which mess things up.
    
    
  • Curt Rostenbach | Mon, 01 Dec 2014 20:04:12 UTC

    Software is vastly different from any manufacturing. A house, a skyscraper, a rocket, ... are built from identical items, or built multiple times.
    Any program (if done correctly) is composed of unique items. If a program requires an item "...just like..." it is already made (subroutines, objects) and does not have to be made again.
    Programming is closer to writing a book (being made of words/commands), but with the added requirement that it must work. Commas can be out of place in a book, but not in a program.
    So I've got to say anytime methodologies are mentioned, I break out in hives. I've worked too many places where the process becomes more important than the product and the people forcing methodologies just unplug their brains and expect the process to guarantee results.
  • Please | Mon, 01 Dec 2014 12:41:07 UTC

    Just another agile type hype. For instance: "Software is, by its very nature, malleable and (physically) easy to change." is provably false. Try changing something in the core of, let's say Windows, the Linux Kernel, or any OS. Or let's go with something less complicated, like a DB or appserver. Whoops, still too complicated? How about a web page? Yep, that's about the only place agile works, and I'm guessing this long-winded "new better, honest!" approach will too. 
    
    In short, if you're developing software that needs to be efficient, scale, and reliable, you're not going to be successful using anything other than that much derided design, architect, and requirements approach. 
Leave this field empty

Post a Comment:

(Required)
(Required)
(Required - 4,000 character limit - HTML syntax is not allowed and will be removed)