Methodologies for solutions.

I keep using the expression “software engineer”. This is a term for describing the process on how things are built. The process and world view that builds bridges and signs that trucks upto 10tons may drive over them; the process and world view that build racing cars capable of slamming corners a 100MPH, and again signs that the car won't roll or ignite the tires is what I wish to apply. Engineering, not coding.

Good engineers can quote you costs and durations. Good engineers have a test plan, and will quote you fail cases and scenarios. This structured methodology may not be requested in all situations, but there are many cases where is it valuable. As a software engineer, I brindle at “get it work”, especially as this implies “and then get it to work again on the live box”. As the solution provider, we should have much better control than that.

This is what I was trying to express towards the end of the meeting, but thought brevity was more important than strict detail at that point. Formal notes are here, see also costings for change.

  1. Command and control focused
    1. This emphases profits not users or clients;
    2. This is separate to the waterfall model, although a quick glance will make it look the same;
    3. Strict attention to limiting changes;
    4. Refactoring is prohibited;
    5. “schooled”/ “house style” alterations;
  2. “Stupid” agile
    1. This emphases clients not profits or users;
    2. Write the simplest possible solution;
    3. Close the support ticket ~ making a support ticket is cheap;
    4. This style is to support a steady rate of changes in a controlled fashion, but may produce really “design by committee” outcomes;
  3. “Proper” agile
    1. This emphases users, not clients or profits;
    2. Write a use case ~ the business case for this is weather the systems works at all in your build environment. This is for “quick study” user interfaces 1 2;
    3. Create/ verify the use-case (iterate discussion here);
    4. Write a test-case against that use-case;
    5. Make the simplest change to implement it;
    6. Add relevant logging for refactor markers;
    7. Has many fewer tickets raised by the clients than the preceding version of Agile;