On.. The Future Of Development

Today I, like many others, read ReadWriteWeb‘s feature on the Future Of Software Development, whilst it was an interesting read I believe the picture it left was incomplete and inaccurate.

Continuous Waterfall

A lot it written about Agile methodologies, indeed I’ve written about them myself from time to time. It is interesting to note the derision piled upon the waterfall development methodology that often emanates from Agile evangelists. As someone who has implemented Agile on actual live projects with development teams I find that it can be best summed up by a phrase I heard Roy Osherove use; Continuous Waterfall. Whilst your actual implementation of Agile may vary, you are in effect reducing your version development times, so your specifications for your product are shorter and more current, your testing phase is shorter (through use of Unit Testing), your releases more often. However you are still maintaining the waterfall methodology of specification, estimate, develop, test, release, just in a compressed state.

Where was Microsoft in all this?

Another important point missing from the ReadWriteWeb feature was the presence of Microsoft and the .NET framework. When talking about current technology that is changing the way people program the article fails to mention the .NET 2.0, 3.0 and 3.5. Version 2.0 has enough contained within it to justify a article entitled “How .NET 2.0 can and has revolutionised the web and your development processes”. That is before we get onto the real show stealers of Workflow and LINQ (.NET 3.0 and 3.5 respectively). Whilst LINQ is looking like it is going to be a great use in the future, for me right now Workflow is the developer tool that I’d say is most likely to effect the future of development.

Workflow allows you to map a process, so all those flow charts you designed years ago can now literally be turned into a product, one that development wise looks exactly like it does on your bit of paper. What’s more, in business you can sit down with someone and map their processes straight into your IDE, straight into your code base. This is more than the “workflow” you see in some HR systems that are glorified database triggers, this is proper long state programming. It is also where developers can bring some of the most useful value to a company, when you have a business process turned into a workflow you can see, as a programmer, where it can be more efficient, by implementing changes you can effect your companies efficiency very directly.

Development demands are non-linear

The other slightly misleading statement is that libraries have helped make for small development teams. Sure this is sort of the case right now, libraries are great for efficiency gains within the development environment. However there is a flaw in the statement, development challenges are not linear. Each year the scope and complexity of the development worked asked of us becomes more and more complex. So whilst it may have taken twenty developers six months to do something six of seven years ago the same can now be achieved by five people in six months instead. The thing is that those twenty people will now be working on a product that is significantly more complex than the previous one they worked on.

The games industry is a great case in point for this, sure they now have the graphics engine as a library and their physics engine as a library and their audio engine as a library, but the games they are producing are so much more complex than the previous generation that they require as much, if not more overall development time.

The article is an interesting talking point, but I think it is wide of the mark in its vision of the future, and its estimation of the problems solved by agile and library based development. The future of web development may seem to be small teams for social sites, however social sites are not the only future for the web.


4 Responses to “On.. The Future Of Development”

  1. 1 Paul W Homer October 25, 2007 at 3:41 pm

    My suggestion is to not get lost in the “technology”. .NET looks like yet another attempt to build a working TP MONITOR infrastructure, an idea that dates back to CICS, but has seem many difference instances including Tuxedo, TopEnd and Corba.

    The “reoccurring” idea is that if we make it really easy to build little pieces, the complexity will go away and we can build bigger things. In practice, however, the complexity of all of the little pieces working (or not) together quickly swamps the system. You get one of those chaos-theory effects, where a little bug somewhere hard to find can bring the whole thing crashing to a halt.

    Our abstractions and paradigms limit our technological capabilities, creating a threshold that we can not exceed (we can get over it slowly in time, but only in the most limited ways). Without finding new and innovative ways to manage the complexity, we are just beating our heads against the limits of the past.

    The Microsoft culture is to dominate, not to innovate. Their past record of belting out mediocre technologies and bullying the market may mean they will gain a significant share, but don’t look to them to actually solve any real problems. They will always disappoint.

  2. 2 buzzsort October 30, 2007 at 6:06 pm

    Paul : It is true that an error buried deep in our technology can cause us massive headaches to fix, anyone that has worked with on a project with lots of levels of inheritance can validate that.

    However if libraries are trusted solutions then we can treat them in a black box manner. Something which is possibly against the nature of a lot of programmers. Suddenly we aren’t painting with detailed brushes, but in large swathes at a time. Of course if you are painting small canvases (applications) with a large brush then perhaps you would be better off using a more detailed approach as you won’t really be feeling the benefits of it. However if your canvas/application is huge then being able to paint with the larger brush can save you a lot of time and mean you can get more done in one go.

    If I didn’t stretch that analogy far enough I can have another stab at it until it breaks.

    Libraries aren’t a magic bullet that make the world great though, they are just a different way of doing things when you find yourself in a different environment, surely.

    What you say about Microsoft may be true about many things, but I’ll stand by the .NET Framework and tools we have around it. Sure some parts aren’t perfect, but I’ve never used a Framework or IDE that was. The current .NET team seem to be hitting it right more often than not though.

  1. 1 Is Agile the Future of Software Development? « Jim 2.0’s Blog Trackback on October 18, 2007 at 7:15 pm
  2. 2 Is Agile the Future of Software Development? « Jim's Blog Trackback on June 6, 2011 at 2:45 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: