Has Software Development Improved?

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?"

Comments

Thinking about thinking..

[kslater]

I don't think there are any magic bullets. Software development (unlike most other engineering disciplines) is a build-it-yourself from the ground up everytime experience. Go read http://www.reciprocality.org/Reciprocality/r0/ (mentioned in the past on /.) to see a different view on what makes some folks way more productive than others.

Best tools, present and past

[MarkWatson]

I think that the quality of software development tools has increased, although I still miss the Xerox hardware Lisp Machine that I used in the early and mid 1980s.

Here is my take on the best environments available today (in order of best first) - I only include stuff that I use:

• Cincom VisualWorks Smalltalk - a really fast coding environment with support for SOAP/WSDL/UDDI/all possible database connectivity, built in web development tools, huge class library so often new applications are very little new code
• Microsoft VisualStudio.Net - I almost hate to include this one, but I am trying to be honest here :-). Last year when I was writing a J2EE (Java Enterprise) book, I took a good look at the competition and liked C# and .Net.
• Java with light weight web services - I am a HUGE fan of Java on the server side, done light. By light I mean that I like to just use servlets and JSPs, etc. and only use heavy weight J2EE stuff when I really need transaction support, etc. that EJBs provide
• Common Lisp - lots of great commercial tools from Xanalys and Franz, and lots of great free tools like CLisp, CMULisp, OpenMCL, etc.
• Python - Love it for small projects, munging text, etc.
• C++ - only use it when I must - great runtime perfromance, but a pain to code in

It seems like so much work today requires deploying web services so I appreciate tools that make it easy to develop basic application logic separately from any user interface, get it working, then write web and/or standalone GUI interfaces.

-Mark

Warnng: I am blogging now: http://radio.weblogs.com/0115954/

Re:Is it engineering, or not?

[smagoun]

If you want reliability, look at what NASA has produced. Those are some engineers. Ahh, but you said 'quickly', didn't you? :-) If you want something rock solid, you can't have it tomorrow, if you want it to do anything remotely complex.

I disagree. That might be true in many cases, but some of the truly great engineering feats were produced quickly by a small team of very, very good people. A classic example is the Lockheed Skunk Works under Kelly Johnson. The SR-71 was conceived in the late 1950s, yet has performance numbers that are unequalled even today. Even more amazing, it was designed and built by just a handful of people. Compare that with the thousands of people it takes to build a new military aircraft these days. Other examples of the Skunk Works' prowess include the P-80 (USA's first operational jet fighter), the U-2 (high-altitude spy plane), F-104 (first mach 2+ jet fighter), etc.

The moral of the story is you can perform very high quality engineering in a very short time (the P-80 took something like 140 days to design and prototype!!) if you have an incredible team with no red tape in the way. Unfortunately, this is rare.

Re:Functional languages

[PissingInTheWind]

Hi Ace,

ML is a functionnal, statically typed language. Lisp is dynamically typed, which means type is attached to values instead of to variables. The improvments in both cases over C might be that the language offer more support to the programmer. Of course it always depends on the task at hand: you would not program an OS in Lisp or ML, but a lot of other interesting things could reasonably be done in Lisp.

Take for example Web applications: with more powerful languages that allows you to manipulate continuations you can do really impressive stuff. Sometimes I'm laughing when I see how the 'industry' falls behind in term of cutting-edge technology. I know that what I use will be discovered in a few years (probably under some other name), and becomes the Big Thing.

What is sad in computer science is that every now and then something old reappears and is considered the new Big Thing: think Java (which is a dumb OO language), or think XML (which is just a painful syntax for S-expr).

Also, forget about proving correctness for practical software programs. They will always get too big to allow you to prove correctness. But if you really want to be able to prove 'partial' correctness, then yes: Functional Languages will be a *much* better choice than C, since you can abstract state from your tests. But the thing is that sometimes it is very convenient to use side effects, for such mundane tasks as outputing text for example ;-)

Purely functional languages might be scorned by some as toys, but they have their use in research. Hybrid languages like Common Lisp are somewhat more practical.

As for hugeness of source code, I see 2 reasons Lisp would help overcome the problem. First, you can write less code that do more (reducing the source volume). Secondly, Lisp allows for interactive development. You don't have to recompile anything if you change your application. Just reload the function you just changed, and there: everything is in place. Some bug? Correct it, resume execution. Want to try something? Try it, look at how your app is responding. The ability to change a program while it is running is really empowering for the programmer.

But anyway, I'm not saying anything new in here, it's just that people wont get it, or that they'll forget. But hey, should I care if my competitors still use half-assed languages and keep hiring 'Java-style' programmers?