Slashdot Mirror

← Back to Stories (view on slashdot.org)

Has Software Development Improved?

Posted by Cliff on from the code-from-today-better-than-code-from-yesterday dept.

earnest_deyoung asks: "Twenty-five years ago Frederick Brooks laid out a vision of the future of software engineering in "No Silver Bullet." At the time he thought improvements in the process of software creation were most likely to come from object-oriented programming, of-the-shelf components, rapid prototyping, and cultivation of truly great designers. I've found postings on /. where people tout all sorts of design tools, from languages like Java, Perl, Python, Ruby, and Smalltalk to design aids and processes like UML and eXtreme Programming. I'm in a Computer Science degree program, and I keep wondering what "improvements" over the last quarter century have actually brought progress to the key issue: more quickly and more inexpensively developing software that's more reliable?"

6 of 759 comments (clear)

  1. Functional languages by nick255 · · Score: 5, Interesting

    Not too sure if it an improvement, but I know some people use languages in which programs can be proven to work like ML. Of course if you actually want to write a program which *does* something it is probably not for you.

  2. Progress Balanced By More Demands on Developers by John_Booty · · Score: 5, Interesting

    While I'm only in my mid 20's and I'm no veteran by any stretch, it seems like there have been huge leaps in programmer productivity made possible by things like OOP and off-the-shelf components.

    However, I think they're equally balanced out by huger demands on programmers. Once it's realized that a programmer can do 2, 3, or 10 times as much work by using more efficient methods management is quick to pile on 2, 3, or 10 times as much work!

    This isn't really unique to programming either. I think it's universally applicable to any area where technology permits greater productivity.

    For example, look at all those ads from the 50's. Things like the microwave, the vaccuum, and the dishwasher were supposed to usher in a new era of leisure. Do we have more leisure? No, we have less, as those luxuries become necessities and we cram in more activities in out new-found time in order to stay competitive.

    --

    OtakuBooty.com: Smart, funny, sexy nerds.
    1. Re:Progress Balanced By More Demands on Developers by sphealey · · Score: 5, Interesting
      While I'm only in my mid 20's and I'm no veteran by any stretch, it seems like there have been huge leaps in programmer productivity made possible by things like OOP and off-the-shelf components.
      Hmmm. In 1980 we had ASK ManMan. Written in COBOL and FORTRAN. A full distribution (IIRC) was around 5 megabytes, which really put a strain on available storage. The function of ManMan was to provide accounting and manufacturing management support for manufacturing companies. It performed this function very well, and some orgs out there are still using the 1980s versions.

      Today we have JDEdwards OneWorld. Written in C++ and other state-of-the-art tools. The distribution runs about 10 GB, with a working set for development purposes of 1.5 GB. Its function? To provide accounting and manufacturing management support for manufacturing companies. How well does it do? Is it any better than ManMan? I will leave that for you to decide. But hey - you can cut-and-paste directly from OneWorld to Excel. That's a gain I guess.

      sPh

  3. One day... by pubjames · · Score: 5, Interesting


    I've always believed that one day some bright college kid is going to come up with a completely different style of computer language and interface, and when that happens we will all slap our heads and go "D'oh! So that's how we should be doing it! Obvious!"

    Like the web and P2P, the most influential ideas are often quite simple, and "obvious".

  4. Progress in software engineering by bfwebster · · Score: 5, Interesting
    Sad to say, there has been little such progress in the last 30 years. One of the things I do for a living is act as an expert witness in litigation over failed IT projects. In my research, I reviewed 120 such lawsuits that took place over a 25-year period and found (a) that they all fall into one (or two or three) of half a dozen fact patterns, and (b) the root causes are all the same. (I wrote a white paper summarizing my findings). The simple fact: we make the same mistakes over and over again, and these are mistakes that have been well-known and well-documented for 30 years.

    Brooks, in the "No Silver Bullet" essay referenced above, stated that there is both essential and accidential complexity in software development, and because of that there never would be a "silver bullet" to slay the software "monster". However, there are fundamental practices that increase the likelihood of success and fundamental pitfalls that every project faces. And, in the end, the root causes of most failed IT projects are human factors; in fact, you could just cite the "seven deadly sins"--pride, envy, gluttony, lust, anger, greed, sloth--and probably hit the nail on the head.

    In conjuction with that, far, far too many practitioners in the IT field lack one or more of the following:

    • Talent
    • Sufficient (or any) education in software engineering (or even computer science)
    • Any familiarity with the literature from the past 30+ years. I'm not talking about IEEE/ACM Transactions, I'm talking about standard classic works such as _The Mythical Man-Month_ (Fred Brooks), _The Psychology of Computer Programming_ (and everything else by Gerry Weinberg), _Principles of Software Engineering Management_ (Tom Gilb), _Peopleware_ (and everything else by Timothy Lister and/or Tom DeMarco), _Assessment and Control of Software Risks (and anything else by Capers Jones), _Death March_ (and anything else by Ed Yourdon), _Journey of the Software Professional_ (Luke Hohmann), and any of the 100 or so texts on software engineering on the bookshelf behind me.

    To quote George Santayana (who is often misquoted):

    Progress, far from consisting of change, depends upon retentiveness...Those who cannot remember the past are condemned to fulfil it.

    Software engineering is hard enough--with all the human issues--without further handicapping ourselves with ignorance of all that has been already discovered and documented. Yet that is exactly what most IT workers do. Until we find a way to solve _that_ problem, the failure rate for IT projects will remain high indeed. ..bruce..

    --
    Bruce F. Webster (brucefwebster.com)
  5. It isn't engineering yet, and won't be for a while by BigTom · · Score: 5, Interesting

    We don't know enough to do software engineering yet. If materials in the physical world were as poorly understood, and changed as fast as they do in the software world they couldn't do it there either.

    If requirements were as poorly understood and changed as fast in the physical world as they do in the software world construction would cost a fortune and most big buildings would never get finished (or would never be fit for purpose).

    People who say things like "Make sure the requirements don't change" are living in a fantasy world where they want to blame their inability to deliver on someone else.

    The rules haven't changed, get a high quality small team, get good access to a user who knows what they want and grow a system from small beginnings, checking at each stage that it all works and that quality is high.

    Its all there in Brooks.

    Its no surprise that the guys pushing the agile methodologies were all very succesful designers and developers anyway.