"Agile is treating the symptoms, not the disease"

Hmm…
This is an interesting perspective. Although I would have to say that is a 16 year old kid came up to me and asked me what language to use to write a simple app to track his Magic cards, I’d show him the .NET Framework without hesitation. I have coded in several languages and have found it to truly me the lesser of all evils.
I know what you’re thinking… It’s a Microsoft product. How could it be less evil.
Well, the simplicity IS there. I taught myself programming 5 years ago just by reading books and tutorials online and now I have a great job building enterprise software.
There are so many resources to learn .NET it’s ridiculous. Someone new to programming can just download VS Express, watch a couple of videos, and be building their Magic Card Tracking App in no time at all.
Yes, there are a wealth of technologies available from Microsoft, but they all address specific business problems. I have worked in ASP.NET, MVC, Silverlight, Linq, WCF, Winforms, Sharepoint, and a number of other technologies from Microsoft, and I didn’t learn any of them until I had a problem in which the technology addressed the issue.
My point is that if you want simplicity, like it or not, right now, .NET is where it’s at.

-Adam

Ted,

Thanks for a great article. I was expecting the anti-Agile conclusion, and instead you're voicing something that's been on my mind too.

Not only is the complexity (at least in Microsoft) making development less accessible, developers are learning the tools, not the code. Maybe that's a good thing, maybe it's a bad thing. If the tools produce the code for you at least it's consistent, and pretty reliable, but it's so dependent on expensive tools that demand frequent upgrades, with more learning curve each time. And instead of becoming faster and easier (as Microsoft always says will happen) it becomes slower and more expensive.

I used to think learning to program was going to be like learning to read and write. It's no longer so easy to just whip up some dumb program to quiz myself on new foreign language terms or sort the grocery list or whatever. That was FUN! When I teach high school kids how to program their web site (which I do on a volunteer basis), we do that in PHP with MySQL because it's free, and they're actually learning something, and they can update their site using a browser and notepad, from any computer with internet access. But, unfortunately, they're going to find out that simple yet powerful tools like these are rare in the real world, and they are also shunned. What a shame.

Our company is seeing a lot of small department-type apps being done in SharePoint. You need a quick list of widgets, then you can create a List in SharePoint, define your fields and data types in about 10 minutes. Obviously, there is some expertise in setting up and maintaining SharePoint, and its associated infrastructure, but once it is up, it is pretty easy.

After thirty plus years I have migrated to Silverlight 3 RIA. The Business Application has all you need.

You still need to learn entities, LINQ, C#, WPF subset, but with a little coaching I got one of my co-workers implementing an application to track training and it just took a week part time. It took me a couple of months to get up to speed, but it was all pretty new in July.

This is a nice focused subset and working from Visual Studio and Expression Blend make it fairly painless.

Very interesting article. I have long struggled with the sheer range of technologies being released, especially from Microsoft - and how can you decide if they best fit a problem if you have not used them in anger yet!

But it just common sense really isn't it?
Problem: Too complex
Solution: Make it simple

I guess Ruby On Rails is an attempt to make it more fun to program and easier to develop web applications, via convention-over-configuration etc. so it's fascinating to think that the Next Big Thing could be a simple, quick and easy-to-learn development studio or tool - effectively a MS Access replacement. That is in one way terrifying because the damage done by people who wrote Access DBs and then expected IT to support / rewrite them is long-lasting but it is interesting.

Good article.

Yes, agile "zealots". Zealots of any methodology are notoriously inflexible, including agile ones.

What is it about methodologies that attracts (or creates) these zealots? They were there for SSADM, ISO9000, 6 Sigma, XP. And they miss the point every time, which is "be flexible". Seems like they confuse the tool (methodology) with the goal (software delivery).

The best approach in life as well as software is a balanced approach that adapts to changes. Ask the dinosaurs.

I remember the first thing that attracted me to Scrum certification was the rule "don't follow this religiously; adapt it to your own problems." I follow this rule religiously. (Just kidding, zealots!!).

I don't believe Agile was meant to address code complexity - only good, pragmatic design and bloat-avoidance can do that - but I do think it addresses business requirements complexity -- particularly in sectors where the requirement tends to change before the product is released. It allows you hit a moving target.

Think of a bullet from a gun compared to a guided missile. The former goes exactly where you aimed (okay, it's software we're talking about here, but work with me on this one). If the target isn't there any more, you miss. In the latter, course corrections are made periodically to allow for the target's shift in position. There is a higher likelihood that a moving target will be hit.

If the target isn't moving, of course, a gun would do just fine, and a missile would be overkill (literally, in this example).

To summarize:
1. Agile = closer match to complex/changing business requirements.
2. Pragmatic = reduce complexity. Eliminate bloat.
3. Success = delivering what the customer needs, when they need it.
4. Failure = delivering what they needed three months ago, when they need something different now.

Best
Dave P

Agile has nothing to do with tools, frameworks, languages, and the rest. Complaining that Agile doesn't solve tool complexity is like complaining that grocery stores don't change your oil.

And... never listen to zealots.

I'm not sure how Agile practices have any bearing on choosing your technology. It doesn't seem like Agile has anything to say about your toolkit you choose other than the tools that effect your process. Agile is all about process not on tools. Although it would be insane to work on a team of 5 without source control, bug tracking, and something to keep track of requirements (note cards, paper, scrumworks, whatever). But all of these tools are easy to just for free or more effortlessly through a service.

If you only have two people you can be less about process, and I think you have to have less process between two people to get things done. But that same process must change when your team size changes. What works for two people doesn't work for 5. And that doesn't work for 10.

The sheer amount of tools out there is overwhelming. That's why I go through periods of paying attention and not paying attention. Periodically I pick my tools I like and shut up about it and get things done. I don't care if new tools show up. I'm busy. While I'm busy I get a feel for how my tools are working. If there's something that's not working well I keep that in mind, but I don't throw it out until the job is done. When the job is done I might start looking for alternatives, or contribute to open source to improve it.

Really I do lots of jobs with them, and I don't let up. After the start of the art has improved a bit I start to go shopping and trying out stuff. See what works better.

Much of the reason we have so much crap is because the nature our development. I think your final statement is the most important. The person who simplifies this is the next big thing. And I agree. If we had a more natural storage mechanism for our objects we wouldn't need SQL, hibernate, etc. Object mapping is a waste of time, and that's why we have big funky stuff to try and overcome the crap design. Simplify the stack and it would be simpler. If we had scalable web architectures that horizontally scaled without lots of architecture design up front then it'd be easier. Scalable storage, scalable databases (nosql?), servers that can be scaled without much thought upfront about how to spray traffic across them. Round robbin DNS, proxy servers, etc?

These are the problems of the future. Solving these will make our lives simpler. But, we'll still be doing it with teams of people.

I think I get what you define as the problem. And I agree that The Next Big Thing might very well be simple programming frameworks where you can slab out your idea day one with the tools. Isn't this where project like Shoes step in?

But I can't see that Agile has ever claimed it even targeted that problem? Let alone treat it's symptoms.

Or, perhaps, let me ask it this way: your 16-year-old wants to build a system to track
the cards in his Magic deck. What language do you teach him?

Lisp. Without a doubt. Okay, maybe Scheme. But definitely a Lisp of some sort.

Five or six weeks to get a college grad who completed Java courses producing code? You're experiences are a lot different than mine. I've spent months just on HTTP and web security issues, and years on relational databases. I've worked with programmers who can't figure out Subversion in five weeks. But that's just an aside.

My main observation is that a lot of those Access and FoxPro applications were developed by power users and people close to the business problem. They chose the only tool they had or could get their head around and ran with it to solve a real problem they knew about. The barrier to entry is so high now that aside from huge macro-ridden spreadsheets only professional programmers can produce workable programs. Sadly too many professional programmers are so obsessed with tools and technology that they don't bother to listen to the clients or learn the business they are working in.

As another commenter mentioned Agile is not intended to address tool complexity. It is intended to put the programmer closer to the user, so the programmer is solving a real business problem and not dicking around with new programming toys, and so the user can see iterative and (we hope) increasingly useful solutions. Like socialism, agile looks good on paper but is hard to achieve in real life. My own experience with agile teams has been unsatisfying. What I've seen is buzzword adoption and following some of the forms while getting none of the advertised benefits.

Teams of one or two power users with Access or a customer sitting next to a programmer using FoxPro or VB have always been agile in spirit, if not formally, because at that scale it's obvious that a waterfall approach is silly. Now I see heavy agile techniques sold to clients who need a ten-page web site and a three table database, by development shops who never bother to learn what the business problems are, because they mired in tools and languages. That's not agile and a week of Ant and a week of Hibernate won't help.

The point about 1,000 people using your app is about scalability. You can plan to scale at the beginning or you can pretend that it doesn't matter - which is planning to fail.

What everyone in this field except for Paremus and possibly VMWare fails to realize is that scalability requires automated agile deployment.

As far as agile development goes, if it works for you, great. We know the definition of insanity.

Or, perhaps, let me ask it this way: your 16-year-old wants to build a system to track
the cards in his Magic deck. What language do you teach him?

Javascript + jquery?

If you want "simple", go write some BASIC. Leave the building of the useful systems to those of use who can handle these "complex" technologies.

I used to be a Java "architect" at some point. It typically took months to get a person up to speed.

For a 16-year-old wanting a simple UI to a database, I'd use Rails. Toss it up on heroku. They'll need to learn some Ruby, html (css/JS/erb) and git to deploy.

Like any junior, you'd set up the app for them and have them focus on functionality they wanted.

The Rails stack has grown, but it still offers visible results very fast.

It is not to the benefit of the priesthood to teach the new guy how to perform magic.

This was a good read 3 years ago, take a look:

http://chadfowler.com/index.cgi/Computing/LongTailTriesToWagTheDog.rdoc,...

Good points. I would argue that this generation's toolset catering to the long-tail comes from the open-source community; most notably in the form of Python and it's wealth of modules.

The kid with the magic deck? How about a spreadsheet? How about pencil and paper?

Not everything is a programming problem, and in 95% of projects and 95% of languages the coding is the easiest bit to get rightworking.

The family of Agile methodologies are all really just aimed at treating non-programming problems with non-programming solutions, ie keeping such problems out of the codebase. Citing 'Communication' doesn't go far enough, half the time the people you talk to don't know what they need to communicate.

And another thing... people like to give zealots a bad rap. I can't think of one successful software company that doesn't have an identifiable zealot about something.