Agile Methods

Contest: Craig Larman - An Agile Evangelist

This is the second of a series of contest entires. Voting begins on Friday 08 September.

After some very serious pondering I have come to the conclusion that the person who has had the most profound impact on me has to be Craig Larman. Although there are of course several movers and shakers that have influenced me, Mr. Larman is the one that really has made me think differently about software development.

Craig Larman is the author of "Agile and Iterative Development: A Manager's Guide". At first the book title felt repelling since it was directed at managers and I certainly am not one. Fortunately for me I read the book - I devoured it in a few nights. The concepts of Agile software development seemed so perfectly sane and logical that I was shocked that I hadn't thought of them before. This image of a this-is-for-your-own-good kind of down-to-earth mentality was further enforced when I got to hear Craig speak at the second ever Agile Finland seminar.

Craig Larman has permanently shifted my brainwaves by such a degree that I will not - without influential coercion - go back to the Dark Age of Software Development from which I was once freed.

How to develop Micro-ISV software.

If you’re going to successfully fire up your micro-ISV, you need to fire your old ideas about software development, be they UML, RUP, agile, SCRUM, extreme or none: they fit like shoes on fish.

Every single methodology for developing software I’ve heard of in over 20 years in this business assumes you’re part of some vast team of programmers, never a programmer working alone. What’s more, each and every existing software development process assumes someone is going to hand you a nice gift-wrapped definition of the problem you’re going to solve via code. That is exactly what won’t happen when it comes to developing a micro-ISV app or web site.

Today’s software design theories are like using a power drill as an ear cleaner - they can be used, but it’s not a good idea. We need a better approach, one based in the reality of one or maybe two programmers who must also define the problem and its solution and who want to do so before their savings run out.

Don’t underestimate just how hard defining the problem domain is, or just how difficult it is to nail down in the absence of actual customers who will tell you what they want. Unless you plan to take a few years unpaid leave from your life to do intensive market research, endless focus groups and surveys, at best you are only going to have a very approximate idea of who is going to be using your software how to solve exactly which problem in what precise way at least all the way through to your public beta.

Planning your virtual future

If you've not been bitten by the Virtual Machine bug yet, it's time to give virtualization, and especially VMware your attention. VMware is out to change a few things in this world, one being how servers serve and the other how developers develop.

Flintstoning Toasters

Flintstones Record Player
I picked up the term "flintstoning" from my visit to Cambrian House. It's the practice of substituting a little human work for functionality until there's enough demand for the feature that it's worth the coder time to implement. Let me give you an example.

You're a web coder for a bank whose promotion this month is a free toaster to everyone who deposits $10,000 to open a new account. The bank realizes that toaster manufacture and delivery is not their core competency, so they outsouce the task the lowest-bidding toaster fufillment processing agency. Your job is to write the code to get toasters to web customers. You have two options:

  • Spend painful hours attempting to reconcile the inconsistencies between the toaster pimp's documentation and their Java-powered full-stack WSDL automated toaster delivery processing gateway until XML angle brackets gouge your eyes out.
  • Go Overboard on Features

    I realize I'm treading on dangerous waters with the title of this weeks post, but I'm tired of hearing about "Architecture Astronauts" and "Creeping Featurism" in response to questions I ask developers about specific features. First and foremost, program architecture is something that you should think about before you start coding! The reality is that, even if you don't formalize this step, the act of coding is based on your current mental framework of the problem at hand and your previous experience with software.

    Quick and dirty prototyping

    Quietly, under the cover of darkness and the Business of Software forums, I've been spreading the corrupting CodeSnipers influence to pull more people into the inner circle. I'm honored to have our latest victim aboard. The author of Agile Project Planning... Dave Churchville. - Editor.

    "Just tell me what you want and I'll build it!"

    What programmer hasn't uttered those fateful words? The problem is that even though users often know what problem they have, they are rarely the best people to tell you how to solve it.

    Enter the prototype. Developers either hate them or love them, depending on their experience. If you've ever built a sophisticated prototype that faithfully re-created the entire application, only to have it forced into production, you probably hate prototypes. Or worse, maybe no one even bothered to look at it!

    Stupidly Easy MVC - Group Membership Application - Part 2

    This is part two of an example of using my Stupid Easy MVC framework in PHP. In this example we will talk about the how to use the Model. Originally I thought I might make the Directory a separate controller, but at this point I decided not to. I have some more ideas that I haven't quite worked out yet for extending this even to be more like the Rails framework for Ruby (again I do not expect to totally implement RoR, spare the language wars please!).

    Process over programs

    Software development, at heart, is the discipline of modeling business logic (or il-logic, if you will). The classic steps go something like the following:

    1. Document the existing process, such as an accounting form or communication need between entities
    2. Determine if there are any existing IT system driving the process
    3. Build a prototype or story board a solution, accounting for #1 and #2
    4. Supposing that the prototype solves the problem (or least makes thing better), go ahead and build it using whatever design/code methodology that suits the project.
    5. Deploy the system to production and commit to caring and feeding for it until doomsday or the process needs revision, whichever comes first

    While this is a fine way to build software, it isn't a fine way to solve core problems. For that, I suggest we add step 1.5: evaluate the process.

    Stupidly Easy MVC - Directory Structure

    There are probably many ways to setup a structure using MVC and this article will talk about two of the ways I have done it and explain why I did it that way and how I think it works out after the fact.

    Structure 1
    For this project, I used Ruby On Rails as inspiration (Imitation is the best form of flattery, yes?) and used a separate directory for each of the Model, View and Controller. I knew I I was going to have multiple models as well. I used inline php/html for the view for this project since it was only a few forms and we didn't want to do a template system yet. It would be easy to change to templates later of course by just editing the view methods to call a template instead of spitting out html.

    More Stupidly Easy MVC in PHP

    If you've been living under a rock and missed the previous two articles about this EASY 3 class framework, go read Part1 and Part2.

    After my initial project where I first created the simple framework I have since used it on 2 other projects. I didn't even use a template solution for one of them, making it even MORE simple. So I've had a chance to really collect my thoughts on this and put it through the ringer. I've had requests for more examples on using this and hopefully this will answer some of your questions.