One thing to keep in mind is that software projects are not only complex because of the way developers write code, they are also complex because of the way these developers are given what to implement.

In a typical project, be that agile or traditional, understanding the customer (e.g. taking business requirements and mapping them to technical ones) and continuously adapting to the changes in requirements adds more overhead than development alone takes. This is then made worse by the general inability to write robust code and catching errors through testing.

Using functional programming you are closer to writing more robust code and depending less on testing. You are also closer to enabling your team to work more effectively: on one hand because code is easier to read and maintain, and on another because it's easier and quicker to write and adapt. Nevertheless, you still need to solve how to tame working with people who speak different languages about what you should implement and how. This is where DSLs can be of immense help: e.g. connecting business folks and technical ones.

By on 12/9/2011 2:32 PM ()

Thank you for your statement about DSLs - they empower us in such surprising ways!

I have to concede that agile is useful for capturing and reacting to changing requirements. But with sufficient refactoring, these should not increase the complexity of the project's artifacts overall. As a feature is displaced, all the dead code should be scrubbed out as if it never existed in the first place. However, I must then concede that no company I've participated in has used that level of refactoring. On my personal projects, which use a more ideal development process, I do always have that level of refactoring. But then, I am usually my only customer. So, I have to pose a few questions -

1) Should we expect teams working on commercial projects to use that level of refactoring, or at least make it a goal to pursue where possible?

2) If we don't clean up our messes, at least the big ones, will we fall back into the trap of combinatorial complexity?

3) Should we explicitly discuss, track (as in issue tracking), and finally act upon these threats to implementation simplicity as they arise?

These seem like very pressing questions to me. Here's a power point presentation I wrote up while trying to grapple with these larger, methodological issues - Agile Craftsmanship

By on 12/9/2011 3:01 PM ()

Naturally, 1) yes, 2) yes, 3) yes. But I don't see ordinary mortals do this (some can, but most won't) and in the longer term I would expect a shift towards synthesized code from high level specifications (say, in DSLs) instead of people writing code in universal languages.

By on 12/14/2011 2:42 PM ()

Cheers to that, man :) Could you expand on what you mean by 'synthesized' code, tho? I'm not familiar with that terminology.

By on 12/14/2011 3:42 PM ()

I mean generating ordinary programming language code.

By on 12/14/2011 5:07 PM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us
Built with WebSharper