Response: "Agile is treating the symptoms, not the disease" by Ted Neward

Ted Neward, whom I’ve known for about 4 years now, wrote a piece calling out all the complexity that is in the line of business software space these days.

This post is not to say that I agree or disagree, but it is a refreshing blog post to read.  I love discussion like this.  As the CTO of a consulting company that embraces Extreme Programming for project delivery, I’m continually trying to get better at delivering high-quality, maintainable software.

When reflecting on what Ted calls out that is necessary for my people to know, I’ll quickly add to the list:

  • · 7zip
  • · aspnetmvc
  • · AutoMapper
  • · cassini
  • · castle
  • · CruiseControl.NET
  • · exceptioneer
  • · FxCop
  • · gallio
  • · msdeploy
  • · mvccontrib
  • · naak
  • · nant
  • · nantcontrib-0.85
  • · nbehave
  • · ncover
  • · ndepend
  • · nhibernate
  • · nunit
  • · rhinomocks
  • · SourceMonitor
  • · structuremap
  • · subversion
  • · tarantino
  • · watin

The funny thing is, we are building tools to make delivering software easier, so we have other things added to the .Net framework.  At some point, Microsoft and Oracle need to take a good look at .Net and Java and see how they can raise the abstraction level a bit so that the technical business analyst can have a hope of a small program.

Just like DRM in the music business has found (>80% of music pirates could not be forced to pay for the music), >80% of technical business analysts will not use .Net or Java for their small little app.  They will walk away and not write the app.  They will instead add just a few more macros to that huge Excel spreadsheet.


Trackbacks

Time for simplicity? « Angel “Java” Lopez on Blog Posted on 10.14.2009 at 7:00 AM

Pingback from Time for simplicity? « Angel “Java” Lopez on Blog

The Desperate Need for Simplicity | Bob on Medical Device Software Posted on 10.14.2009 at 3:30 PM

Pingback from The Desperate Need for Simplicity | Bob on Medical Device Software

¿Es tiempo de volver a la simplicidad? Posted on 10.16.2009 at 11:17 AM

En estos días, Ted Neward escribió un interesante post “Agile is treating the symptons, not the disease

Comments

Adam D. said on 10.13.2009 at 11:49 AM

too many listed there.

# . 7zip - really?? Not worth mentioning if you have big items like aspnet mvc here

# . aspnetmvc - sure

# · AutoMapper - still ok

# · cassini - not needed

# · castle - be more specific. The whole stack including monorail?

# · CruiseControl.NET - TeamCity is easier

# · exceptioneer - not needed

# · FxCop - not needed, TDD w/ Resharper provides enough

# · gallio - Reshaper's test runner does the job

# · msdeploy - not using

# · mvccontrib - not using

# · naak - not using

# · nant - not using

# · nantcontrib-0.85 - not using

# · nbehave - not using

# · ncover - not using (false sense of security anyway)

# · ndepend - not using

# · nhibernate - mastering this completely makes all others not worth mentioning

# · nunit - using, but come on!

# · rhinomocks - using

# · SourceMonitor - not using

# · structuremap - if castle is there, why do you need this?

# · subversion - git with the times

# · tarantino - custom db scripts do just fine

# · watin - not using yet

About 15 of those items are not necessary for a team to be successful. There is also no mention of an issue tracker..

Jeffrey Palermo said on 10.13.2009 at 11:56 AM

@Adam,

I'd be interested to know the tools and libraries you are using that we are not.

Neville said on 10.13.2009 at 12:56 PM

I think IronPython starts coming close to a useful .Net abstraction for Technical BA's. I hope it continues to accumulate adopters.

Brendan Enrick said on 10.13.2009 at 12:59 PM

@Adam

I have to agree that this is quite a long list of requirements. I think it would be better to say what each item is and give some examples rather than giving the specifics as the answer.

Instead of CruiseControl.NET you might say that one should know how to use Continuous integration, but at Jeffrey's company the one they use is CruiseControl.NET so his team members do need to know that.

@Jeffrey for your next blog post I recommend using interfaces and use an IoC container to resolve all of your instances. This way when Adam visits the site he will see TeamCity and when you visit the site you will see CruiseControl.NET

joshua.ewer said on 10.13.2009 at 1:11 PM

@Adam: Out of curiosity, does "not using" imply

1) "I looked at it and didn't find a need for it"

2) "I've never needed it, so never looked at it."

3) something else?

While I agree that you don't have to have a mastery of each of these items to be successful, knowing them well *will* contribute to your effectiveness.

For example, I came across Gallio recently and realize that, while what I was doing manage test runs and some other tooling "worked fine" there was a lot of tooling I wasn't taking advantage of. I didn't know what I was missing....

James Hicks said on 10.13.2009 at 8:32 PM

While none of the items Jeffrey listed are "required", they sure do make developing complex systems in a team environment much easier.

Jay said on 10.30.2009 at 8:01 AM

First, it seems to me that if you are practicing XP correctly you wouldn't need an issue tracker. It would force your developers to really write bug free code and fix issues immediately as they occur.

Secondly, big businesses might not write the small app in .NET or Java but could write it fairly quickly in PHP, Python, or Ruby. There are plenty of frameworks out there that allow for small apps to be written very quickly that return a great value at a very low cost.