Owen's profileThe Transcendental Softw...PhotosBlog Tools Help

Blog


    June 13

    Not quite enough

    In a recent meeting, someone brought up the agile development topic of not quite enough (actually mocking it, something like, "there's a methodology out there where you actually don't do all of the work"). I took a few minutes to rant a correction.

    Not quite enough is a powerful concept that revolves around the idea that it is almost impossible to identify the 'enough' mark on a given development project. How much documentation is enough? How much testing? How abstract should the implementation be? These are all questions that are hard to answer until all the variables are known, and they can't all be known until the project is over with. The only way to deliver enough is to over deliver - and anything delivered that's more than enough is wasteful and inefficient.

    Not quite enough tells us to do as little as possible (comparatively speaking, please don't spin in your chair for hours and expect the software to code itself) and depend on frequent customer feedback. This allows us to develop exactly what is needed quickly, adapt to rapid change with ease, and deliver great software in the most optimum manner.

    May 30

    Qualities of a Successful Software Development Project

    So, I started doing a little brainstorming about what I feel are the qualities of a successful software development project.

    Qualities of a successful software development project:

    1. Solves the actual business problem.
    2. Reliably and repeatedly solves that business problem.
    3. Is elegant in its design and delivery.
    4. Was delivered on-time and on-budget, where those constraints were reasonable to begin with.
    5. Follows common, logical design practices where those practices are appropriate for the scope of the application.
    6. Has a level of code documentation appropriate for the scope of the application.
    7. Has user guidance appropriate for the level of end user.
    8. Was developed in a manner visible to the interested parties.
    9. Does not result in a high percentage of the team departing the company and/or project.
    10. Has high acceptance or buy in from end users.

    Many of these items correlate. For example, number 8 (high visibility) is almost always found in projects that achieve number 10 (high acceptance), but either one could occur without achieving the other.

    So, to ask the silly question, how often do you see these things in your projects? Did I miss any or are there any you disagree with?