By Popular Request: What my Approach Is

I’ve been asked on several occasions what my general approach is for software development.

Although I don’t have particular “hard rules” for how things must be done, I do have a number of general approaches which I tend to use on projects.

First, I tend to start with the best people. Using Senior, experienced Engineers, Project Managers, etc, is the foundation to a smooth running project, as well as harnessing their unique specialties. EG I perfer specialists over generalists.

I don’t ask HTML people to set up the database, nor vice versa.

I generally have some sort of written documentation/specification. This is usually 20-50 pages long, and includes screen mockups etc. This document may evolve over time, and does not need to be complete to start coding.

However, having a document in narrative (not wiki) form helps people stay on the same page as well as assists with the onboarding process.

For estimation, I tend to use a range estimation technique, using real time units (hours, days). I will generally take the low and hi estimate them and average them out; using range estimation has many benefits and is probably worthy of its own blog post.

I feel that great communication is key, but colocation is not necessarily a requirement; I work on many distributed projects. Screen sharing, skype, etc, can bring a team from around the country together as well and sometimes better than in person.

However, a certain amount of in person communication is always desirable, up to a point; ad hoc communication is not a substitute for written documentation.

I tend to involve the customer early, and try to shake out unknowns as described below; I try to get the customer to comment etc early and often, and keep a written (or email) paper trail. Written communications provide accountability and a reference and avoids miscommunication.

Since most “change” is readily apparent at the UI level, I will create mocks, prototypes, wireframes, etc, and work with the customer to refine things at this level; shaking out as much change/initially missed requirements early allows the team to avoid much needless refactoring once production level coding starts.

I use loose coupling throughout the system to avoid people synchronizing on changes; eg some production code could start while other aspects are still being shaken out using mocks.

I will generally do an initial architecture of a framework, set up interfaces, and then do performance and usability testing to insure that the framework is operating as expected; I will do at least a few vertical cases to make sure the end to end behavior is as expected; I refine as needed; having solidified the interfaces, aspects of the coding can then be refactored without synchronizing other developers since they obey the same interface.

I estimate in tasks and subtasks, not stories.

I categorize features into 4 main buckets:

  1. Known Knowns
  2. Known Unknowns
  3. Unknown Unknowns
  4. Unknown Knowns

Since the unknowns (can this be done on Android?) are the most difficult to estimate, and therefore have the biggest chance of blowing up the schedule, I tend to do those first. Having done them, the rest of the schedule becomes relatively predictable.

For the unknown unknowns (things we haven’t though of yet) I pad as appropriate. For the unknown knowns (things we havent thought of yet but are straightforward — eg, admin screens) I bring my experience and work with the customer to add in things they were missing in the requirements.

We adapt to change, but we manage the change and changing requirements, not let change for the sake of change, or even worse, change due to ineptitude or laziness, manage us.

Generally the work is performed and released in an incremental fashion, with as much parallelism taking place as possible.

I unit test as appropriate, but generally have more sophisticated “test harnesses” for performance testing than most simple “unit testers” would use for unit testing.

So, that is in general, my overall approach; while  it doesn’t touch on everything it at least should give the reader an idea of how I approach SW Development


About postagilist

Architect, Manager, Developer, Musician, Post-Agile thought leader
This entry was posted in Uncategorized and tagged , , , , , , , . Bookmark the permalink.

10 Responses to By Popular Request: What my Approach Is

  1. Agile Scout says:

    Sounds… “Agile-ly” to me… 🙂

    • PostAgilist says:

      I knew someone would say that so thanks Peter.

      Yes it is effective and nimble, and I started using this in the late 80s (before “Agile”).

      But what is notable is that none of the Agile dogma is there; no daily standups, no PO, no slogans.

      Much of what I do, however pragmatic is against “Agile” canon. Distributed teams, documentation, not all code being “potentially shippable”, using specialists including Project Managers, etc.

      I would call it nimble, common sense, possibly little a “agile” but I think what this post demonstrates is how little big A “Agile” practices really relate to the mission at hand.

      What I’m discussing here is much more technically related to actually getting sw projects done, whereas “Agile” is mostly fluffy slogans that in practice are harmful and at best tangential or unrelated to getting work done (“collocated teams”, “daily scrums”, “no titles”) etc.

      I plan ahead so I can afford to make changes; Agilists don’t plan ahead because they feel that life is completely unpredictable, including every aspect of the software project they are working on… I don’t agree with that, and to the extent that I do, I front load it, not let it fester during development or even worse encourage that to happen by failing to get obvious requirements solidifed up front because it’s “too much work” (although the Agile excuse given is usally “But it might change!”).

      Actually what I’m describing is an incremental version of a traditional process (“Waterfall”) that is actually very close to what was actually written in Royce’s paper.

      Agilists pretend that it doesn’t exist and doesn’t work — I don’t suffer that illusion. The only reason Agilists say that is because they want to sell the customer something different, and because they don’t have the skills and experience to make a traditional process work, so the pretend it never does and never did. Ironic.


  2. PostAgilist,

    Very interesting. It sounds like what you are doing works and is highly responsive. It certainly fits the yard stick of “if it works, don’t mess with it.”

    And… today, most people would call that “agile.” But then we all understand that agile is a new umbrella term that has captured a lot of ‘common sense’ ideas under a common language framework. I think I understand your dislike for agile a lot more now. It’s not that you’re opposed to effective, iterative development but more to the marketing ‘hype’ that’s grown up around the concepts. Am I capturing that right?

    You’re not alone. Jeff McKenna was a consultant/coach on the first “Scrum” team, before they called it Scrum (He was a Small Talk expert as well as good with team dynamics). If you listen to him speak, he’s pretty irreverent about the whole agile “buzz.” He uses the language because it allows others to easily understand him, but at the end of the day it’s the common sense approach he’s been using for fifty years of software development.

    Not everyone is an agile fundamentalist. Leading Answers did a blog last year on the “Periodic Table of Agile adoption.” ( Just like with any theories, there are people at all levels of belief. I personally probably fall into RE7 area. For me, agile is just another tool in my tool box of effective ways to manage a project. I use the current terminology because it has enough traction that people know what I’m talking about.

    Your style is your style. It works and that’s what matters. I’d say that’s more agile than a lot of fundamentalist agile people I’ve seen of late.


  3. Interested Observer says:

    Not sure I prefer a 20-50 page document over a well constructed, interactive (but printable) wiki, and think you’re splitting hairs trying to contrast “tasks & sub-tasks” with “stories” (in reality that’s just a different name), but I don’t think anything you’ve said is particularly controversial. I think your beef is mainly with Scrum, not agile, and many many agile practitioners share this beef.

    What’s your stance on the high quality, disciplined engineering techniques that were popularised as part of XP (Continuous Integration, Static Analysis, comprehensive unit testing, automated interaction testing, automated functional testing, TDD, etc)?

    • PostAgilist says:

      I think wiki’s suffer from the “ravioli” syndrome which I’ll be blogging about soon.

      Eg, start where, navigate which direction?

      Hence my preference for narrative.

      I’ve blogged about and/or will blog about those aspects but I think TDD is especially overrated.

      Ditto for automated testing.

      Today’s environments are too diverse for automated testing to be of real value, and unit, etc, tests don’t touch on the scalability, etc, tests that are really needed.

      Saying that tasks and user stories are equivalent is a stretch.

      “As a passenger, I want to fly anywhere in the world in 3 hours”.

      OK, and that will result in a lot of tasks….

      Build an engine that can… Build a wing that can… Find a metal that can…

      User stories, and their cousin, T-Shirt Estimations are a charade.

      Only the most simplistic apps could survive on user stories alone. For all other projects the said stories need to be broken down into tasks to be executed on.

      The only difference between a user story and a use case is the folksy literary style, and no that isn’t a defense of use cases.

      I want to stress yet again, that “My approach” is neither based on, nor a reaction, to Scrum, Agile, etc.

      It was developed before Scrum and Agile, and it serves me well today.

      I just don’t see anything of unique value in Scrum and Agile, and I don’t believe comparisons between my approach and Scrum, for instance, or Agile are appropriate.

      Many die hard Agilists were upset that I dare say anything negative about the sacred methodology so they challenged me to write about “my approach”.

      So I have done so.

      All it shows is there a lot of good approaches out there that have nothing to do with Agile and Scrum and I’d love to see more of them.


      • Casey Butterworth says:

        Have worked on many agile and non-agile projects over the last 10 years, and am not sure my experience is the same as yours:

        * Wikis – can be done atrociously for sure, but when done well, are substantially more valuable than a 20-50 page document that is only read up until page 10. The reality is people typically use this volume of information as a reference, not as a narrative, so the structure and direct linking on a well done wiki, not to mention realtime nature of the information (with automatic change logs), is imho far superior for this type of information. A few 10 page docs with a couple of powerpoints can certainly be useful when needed.

        * TDD etc – my experience is that if you want to surround yourself with the best people, then you want to find engineers who are passionate about designing their code to be easily tested. I’ve worked on plenty of projects where people “didn’t do TDD”, and almost invariably, they just weren’t very good engineers. As someone who has been a senior engineer and an architect in recent times, I am infinitely more comfortable working in a team that has a disciplined approach to cutting code, usually via strong TDD and static analysis. Have you perchance read Rob Martin’s Clean Code book, or Dave Thomas’ pragmatic programmer book? If you want to surround yourself with the best, you want people that treat this stuff as the bible.

        * Stories vs Tasks – almost invariably, agile project teams learn to think less about the ceremony of a “user story”, and more about “a piece of work that can be completed within 3 days”. This is a task. The process of identifying tasks might differ slightly, but if done well, you get a comprehensive work breakdown with fantastic transparency over progress. Typically stories are just features. The story narrative does help describe non-functional features to business customers when needed though.

        I think you’re approach is great, but I think you’re a bit close minded about accepting that some of your approach has been widely popularised as part of agile, and they might have picked up a couple more things over and above your approach that you might consider taking aboard.

        My 2c 🙂

      • PostAgilist says:


        First of all it seems like you are taking issue with a few things that really don’t need to be taken issue with.

        Eg, if you read my posting above, I say “I tend to…” not “I always” or “I never” or “Thou shalt”.

        For hard core Agilists such shades of gray may go unnoticed.

        Be that as it may, Wikis are not narratives…. End of Story.

        I think there needs to be a narrative…if people want to have wikis as well, that’s fine.

        Regarding TDD — I (re)”invented” Unit Testing — in 1992 shortly after Al Gore Invented the Internet and long before XP and Agile came about.

        Certainly my first exposure to Unit Testing was when I “invented” it for the FlowStream project based on a flakey ORM layer hosing all the UI code.

        There is a time and a place for Unit Testing, but I don’t believe in Test Driven Design.

        What most people fail to understand about unit tests are that:

        1) They were originally designed to defend weakly typed (smalltalk) code from refactoring where a simple spelling error could break the code base.

        Issues that are mostly not there when using strongly typed languages….

        2) The need to protect the code from refactoring is greatly reduced by traditional models, and strongly exacerbated by agile techniques

        3) If the “tests are the spec” then why isn’t the app the spec? one could simply run the app or compile the app to see if anything broke and

        4) unit tests are not the stress tests etc that are really needed.

        It doesnt matter if someone can insert a record in the database, it matters what happens when thousands of people try to do so at once.

        Creating such a significant test harness is often a lot of work in it’s own right and doing unit tests does very little to nothing to create the code necessary for such a stress test.

        To me unit tests are like driving your car to the hot dog stand and back to find out if you can drive it to the grand canyon and back.

        Certain things could and should be unit tested but many things are not worth the tradeoff in terms of opportunity cost that involves.

        I’m glad you’ve been doing things for 10 years, but I’ve been doing this for twice that long.

        Bob Martin has made many divisive and irresponsible statements on TDD and I’ll just leave it at that.

        I am not saying that Agilists do not do some of the same things that I do; I’m saying that my approach is not derived from or based on anything from Agile.

        I do the things that I do because they make sense, not because some manifesto says so or I read it in some methodology book.

        Ultimately I understand the process and why things are done — and what the tradeoffs are — something that cannot be said of all Agilists or their approaches.

        I’m more interested working with people who can think and innovate for themselves, not the ones who just do what some bible tells them too.

        But yes, I am a believer in cross pollination and learning from others. It just happens to be the case that I haven’t seen anything new or innovative (eg, Things I didn’t know already) — in Agile.

        Perhaps that will change in the future.

        In the meantime I hope the Agile crowd is as interested in learning from multiple approaches and understanding what various things optimize for as I am.



  4. Vin D'Amico says:


    I like your approach. It’s a hybrid approach combining some elements of waterfall development with some elements of agile development. Starting off with “the best people” is always important. I’m not a fan of lengthy documents but 20-50 pages isn’t bad and including screen mockups is a great idea.

    I like estimating in ranges — it let’s everyone know that there is some uncertainty. And, involving the customer early and often is always a good thing.

    I’d quibble a bit with “pad as appropriate” to manage the “unknown unknowns”. Padding can be a dangerous game because you never know how much padding is enough or too much. If you’re open and honest about the estimates and the unknowns, I suppose it can work.

    I think there is a lot more agreement between us than disagreement. Thanks for commenting at my blog and thanks for letting me comment at yours!


    • PostAgilist says:

      Hi Vin

      Thanks for your reply; I’m glad that we agree in many areas 🙂

      I’m not sure what you mean by hybrid — I certainly don’t consider my approach to be a combination of “Agile” and anything else — it predates (and post dates) agile.

      Also my focus on eliminating unknowns I feel is unique in the various approaches used.

      Lots of people think that “pad” (which I only use in 1 of the 4 unknown cases) is a four letter word. However, the time will not be zero, so some number must be used, and, I seek to narrow that uncertainty down as as soon as possible, versus just “delivering value” every iteration only to be eaten by the dragon at the end…


  5. Pingback: Post Agilism: Moving beyond the outdated and misdirected aspects of “Agile” | Post Agilist

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s