The Artima Developer Community
Sponsored Link

Weblogs Forum
Software Development Has Stalled

164 replies on 11 pages. Most recent reply: Mar 28, 2010 10:20 AM by Florin Jurcovici

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 164 replies on 11 pages [ « | 1 ... 2 3 4 5 6 7 8 9 10 ... 11  | » ]
Michele Simionato

Posts: 222
Nickname: micheles
Registered: Jun, 2008

Re: Software Development Has Stalled Posted: Feb 4, 2010 9:37 PM
Reply to this message Reply
Advertisement
> I once was helping someone with an issue in a production
> program and we finally determined that the program had
> never executed successfully. The contractors who wrote it
> were long gone and the users had continued to do
> everything on paper.

Why I am not surprised? Once we had an ill-designed importer in production which was not updating data and nobody noticed it for 14 months.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Software Development Has Stalled Posted: Feb 5, 2010 5:43 AM
Reply to this message Reply
From the technological point of view, modern software fails to handle the concept of information good enough that it can provide the required value to the managers. Software requires information to be strictly and formally defined, but reality requires information to be fuzzy, malleable, like putty.

The other big problem is that software cannot be built in a way that the programmer doesn't have to deal with technical details; most of the time spent in a project is not to satisfy customer requirements but to get around technical problems, limitations and details.

In order to solve the software crisis, two things must be done:

1) decouple information from programs.
2) decouple programs from technical details.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Software Development Has Stalled Posted: Feb 5, 2010 6:10 AM
Reply to this message Reply
With regard to innovation on the hardware side, which might be boring to the coders in the audience, I just came across this:

http://www.eetimes.eu/semi/222700010;jsessionid=WRT4YIXJPEPPZQE1GHPCKHWATMY32JVN

Turns out, there is life in the hardware side. The assumed effort is to build a _server_ chip. I've said for some years that the X-term/database paradigm has to win out in a rational world; it just could be long after I'm dead and gone.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Software Development Has Stalled Posted: Feb 5, 2010 7:50 AM
Reply to this message Reply
> > I once was helping someone with an issue in a
> production
> > program and we finally determined that the program had
> > never executed successfully. The contractors who wrote
> it
> > were long gone and the users had continued to do
> > everything on paper.
>
> Why I am not surprised? Once we had an ill-designed
> importer in production which was not updating data and
> nobody noticed it for 14 months.

The experiences I am relating are anecdotes but I don't think they are unusual. The reality is that a lot of the software in IT that is believed to work correctly does not. It's just that there is no independent confirmation of the results. What ever the software says is taken to be the 'truth'. A few years back, I would get a bill from a company saying I was delinquent for hundreds of dollars. I would call the company to ask about it and they would research it and tell me that I did not owe anything but they were unable remove the note from my statement. Eventually I had to request they send me an official document stating that I owed nothing despite what was in their system.

These kinds of issues are the norm. That's why I scoff when people suggest the big issues in IT have been 'solved'. They seem solved only if you aren't looking.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Software Development Has Stalled Posted: Feb 5, 2010 7:56 AM
Reply to this message Reply
> From the technological point of view, modern software
> fails to handle the concept of information good enough
> that it can provide the required value to the managers.
> Software requires information to be strictly and formally
> defined, but reality requires information to be fuzzy,
> malleable, like putty.
>
> The other big problem is that software cannot be built in
> a way that the programmer doesn't have to deal with
> technical details; most of the time spent in a project is
> not to satisfy customer requirements but to get around
> technical problems, limitations and details.
>
> In order to solve the software crisis, two things must be
> done:
>
> 1) decouple information from programs.
> 2) decouple programs from technical details.

If this could be achieved, it would be a huge advance in development tools. But if people believe that there's nothing left to do (see article title), I see little hope of this happening.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Software Development Has Stalled Posted: Feb 5, 2010 8:30 AM
Reply to this message Reply
> In order to solve the software crisis, two things must be
> done:
>
> 1) decouple information from programs.
> 2) decouple programs from technical details.

IIRC, these were/are the design goals of UML and tools which generate and manage "executable UML". I've never used any of them, and since I'd have to do a bit of work to find them today, I doubt that any of them delivered. But the effort has been made.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Software Development Has Stalled Posted: Feb 5, 2010 8:53 AM
Reply to this message Reply
> > In order to solve the software crisis, two things must
> be
> > done:
> >
> > 1) decouple information from programs.
> > 2) decouple programs from technical details.
>
> IIRC, these were/are the design goals of UML and tools
> which generate and manage "executable UML". I've never
> used any of them, and since I'd have to do a bit of work
> to find them today, I doubt that any of them delivered.
> But the effort has been made.

This is called model-driven-design now and no, it hasn't delivered.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Software Development Has Stalled Posted: Feb 5, 2010 10:01 AM
Reply to this message Reply
> > > In order to solve the software crisis, two things
> must
> > be
> > > done:
> > >
> > > 1) decouple information from programs.
> > > 2) decouple programs from technical details.
> >
> > IIRC, these were/are the design goals of UML and tools
> > which generate and manage "executable UML". I've never
> > used any of them, and since I'd have to do a bit of
> work
> > to find them today, I doubt that any of them delivered.
> > But the effort has been made.
>
> This is called model-driven-design now and no, it hasn't
> delivered.

I'm not sure how you achieve the above. I can't picture it. It would be like decoupling the ingredients from a recipe. If you need 1 lb of beef and 1/2 cup of finely chopped onions you can't just throw in 3/4 pound of mashed peas and 12 oz of beer and expect the same results. Hell, in some cases the fineness of the chop makes a difference, never mind what happens when you swap ingredients.

Sure, the recipe isn't the food, but there is a pretty strong link there. You can only decouple so far and have it still be useful.

Maybe this is too high a level for my poor little brain. There are some technical details I can see easily being decoupled (e.g. memory management, sort algorithms assuming you don't need one highly optimized, etc.) but at some point rubber needs to hit the road.

I'm all for abstraction but at some point, like when I'm going through seven layers of managers and interfaces before I actually get to something resembling working code, my feeling is that I'm wallowing through way too much of a good thing. In my experience that sort of code has been as brittle to maintain and update as code that was tightly coupled to its data/information. I think it's a fine line.

I'm well aware that I'm a little too far on the practical just get 'er done side for a lot of people's taste, but I've been neck deep in the over-abstracted over-architected overthought projects, too. My bias in this case is that in most cases I've had an easier time refactoring and re-architecting pieces in the code that would be closer to the metal vs. code that uses a lot of abstractions and interfaces. If the code is modeled at a very high level, it makes it hard to do incremental improvements.

That's my experience. I know that others differ.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Software Development Has Stalled Posted: Feb 5, 2010 10:44 AM
Reply to this message Reply
> I'm all for abstraction but at some point, like when I'm
> going through seven layers of managers and interfaces
> before I actually get to something resembling working
> code, my feeling is that I'm wallowing through way too
> much of a good thing. In my experience that sort of code
> has been as brittle to maintain and update as code that
> was tightly coupled to its data/information. I think it's
> a fine line.

I think a lot of this has to do with experience. When we start programming, we are just trying to get something to work. It's unclear what an abstraction is or why you need them. After a while you start seeing that you can't manage all the code and that abstractions are a good way to organize things. At this point many of us tend to start building abstractions for everything, even other abstractions. By the time we are done building all the abstractions, there's hardly any time to write the code that actually does something. Often many of these layers are just transparent facades to the underlying implementations and therefore fail to add value.

I think it's only when you get near expert level that you start to see that abstractions are really important but that not all abstractions are a good idea. One good level of abstraction is better than lots of abstraction layers.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Software Development Has Stalled Posted: Feb 5, 2010 12:44 PM
Reply to this message Reply
> I think a lot of this has to do with experience. When we
> start programming, we are just trying to get something to
> work. It's unclear what an abstraction is or why you need
> them. After a while you start seeing that you can't
> manage all the code and that abstractions are a good way
> to organize things. At this point many of us tend to
> start building abstractions for everything, even other
> abstractions. By the time we are done building all the
> abstractions, there's hardly any time to write the code
> that actually does something. Often many of these layers
> are just transparent facades to the underlying
> implementations and therefore fail to add value.
>
> I think it's only when you get near expert level that you
> start to see that abstractions are really important but
> that not all abstractions are a good idea. One good level
> of abstraction is better than lots of abstraction layers.

Great synopsis.

I think some of the abstraction is caused by the desire to force fit software development into the manufacturing model. If it could be done, then you'd need a small number of engineers/designers/architects/etc. producing a model that contract coders would implement. A business wouldn't need the overhead of having a staff of developers.

Then of course there are the people who just love abstraction as a mathematical self-pleasuring.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Software Development Has Stalled Posted: Feb 5, 2010 1:24 PM
Reply to this message Reply
>
> Then of course there are the people who just love
> abstraction as a mathematical self-pleasuring.

mathematical self-pleasuring == dirty thoughts :-)

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Software Development Has Stalled (slightly OT) Posted: Feb 5, 2010 5:17 PM
Reply to this message Reply
All Robert's talk about databases reminded me to ask this: what do people think of the new "NoSQL" databases? And how do they differ, in practice, from an OODB, which is another attempt to avoid the Vietnam of RDBs?

e.g. see http://justsomejavaguy.blogspot.com/2010/02/2010-is-year-developers-take-back.html

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Software Development Has Stalled (slightly OT) Posted: Feb 6, 2010 10:51 AM
Reply to this message Reply
If you believe that Sarah Palin has the qualifications to be (vice) president, then you likely feel that NoSql is an honest attempt to provide a shared datastore.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Software Development Has Stalled (slightly OT) Posted: Feb 6, 2010 9:27 PM
Reply to this message Reply
NoSql = Palin
Sql = Obama
Lisp = end of all innovations in programming
Future = Pascal i.e. separating code from data

Thanks to everyone for the inspiring discussion and those take away truths.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Software Development Has Stalled Posted: Feb 7, 2010 4:46 AM
Reply to this message Reply
> > In order to solve the software crisis, two things must
> be
> > done:
> >
> > 1) decouple information from programs.
> > 2) decouple programs from technical details.
>
> IIRC, these were/are the design goals of UML and tools
> which generate and manage "executable UML". I've never
> used any of them, and since I'd have to do a bit of work
> to find them today, I doubt that any of them delivered.
> But the effort has been made.

Actually UML fails at the 'data as putty' criterion. UML specs are mathematical in every sense of the word; they are strictly defined.

Flat View: This topic has 164 replies on 11 pages [ « | 2  3  4  5  6  7  8  9  10 | » ]
Topic: Heron Tackles the WideFinder Challenge Previous Topic   Next Topic Topic: Setting Multiple Inheritance Straight

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use