Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto G

April 15th, 2009 at 7:04 pm

Forget about requirements, Software Development is all about inputs, outputs and actions.

with 8 comments

One of the worst habits from traditional Software Development is to give different names to all the artifacts that somehow affect the software we have to deliver, Requirements, bugs, risks, constraints…  Are just the same, they all are inputs to the project, and they should be treated equally.

Inputs are the clues that leads us to find the best solution for our customer, their main goal is to help the stakeholders understand the problem they have to solve, they should be managed as an unique entity.

Let’s see a simple sample of some inputs working together:

  1. The customer wants the user to be able to pay with credit card in the checkout page of his e-commerce site.
  2. There’s an existing module for processing credit card payments in-house.
  3. The architect believes there’s a security risk in the credit card implementation in the in-house module for processing credit card payments.
  4. The development team is short on resources for the next month as they are helping another team fixing some priority 1 issues.
  5. The customer needs this functionality ready in the next month.

When enough inputs have been gathered an action is decided, an action is a sequence of tasks agreed by all the stakeholders which it’s only purpose is to overcome whatever the problem is expressed by the inputs. Most of the times this action will trigger some sort of software implementation.

For our previous inputs the following action is decided: “Implement a simple credit card payment mechanism based on the in-house module already created, keep an eye on testing the security risk”.

This inputs-action schema is actually in every single developer heart, it’s just because bad work habits, we keep having different documents for risks, requirements, design…  and we keep giving the requirements the main role.

  1. There’s no point to just have the requirements as base to our actions, they are just a type of inputs.
  2. All inputs should be seen and managed together making easy to see the whole picture of the problem.

As I said in my previous article about requirements, they are not likely to be clear at the beginning of the software development process, this applies not only to the requirements but to any type of inputs,  actually inputs have a very dynamic and simple life cycle which consists of the following stages.

  • Discovery. The input has been identified or moved back to this status and it’s  best description in plain English is being created.
  • Idle. The input has been described, no action has been taken yet to generate an output for it.
  • Generating output. An action or actions addressed to solve this input, (and probably some other inputs), have started and they are in it’s process to completion. In the “Generating output” status the inputs are refined and new inputs are discoverer, some others may be canceled.
  • Validated. The related output for this input has been completed, the stakeholders have agreed that the result is as expected.
  • Closed. There is enough confidence that the validated input is unlikely to change.
  • Canceled. The input has been canceled.

Let’s put this into some context, let’s take the 5 input samples scenario described above.

  1. The customer wants the user to be able to pay with credit card in the checkout page of his e-commerce site.
  2. There’s an existing module for processing credit card payments in-house.
  3. The architect believes there’s a security risk in the credit card implementation in the in-house module for processing credit card payments.
  4. The development team is short on resources for the next month as they are helping another team fixing some priority 1 issues.
  5. The customer needs this functionality ready in the next month.

The status for these 5 inputs will be “Discovery” while we are gathering them, then, once that we think the inputs are mature enough we will move them to the “Idle” status, when we are sure about the action we want to take and we start taking it, we move the status of the inputs to “Generating output”, once that the output is finished, some inputs can be canceled, some others can be called validated, some other can remain in Generating output, idle, or even can go back to Discovery.

As an example, let’s say that while we were generating the output for the previous 5 inputs, (they are in the status “Generating output”) , we found that:

  • The input number 3, about the risk in the in-house module,  doesn’t apply anymore because we have done some proofs of concept that shows that the module is completely reliable, so we decide to move its’ status to  “Canceled”,
  • New inputs are created regarding what is the best design approach to suit for this particular implementation
  • More inputs are created for every bug found during the test phase

Finally we complete the implementation and we show the results to the customer who’s happy about the output, so we decide to move their status to “Validated” and after a while, when all the changes to the checkout page are completed we decided that is safe enough to change the status of these inputs to “Closed”

Change always happens in a project, and not necessarily only on the requirements, but in any input, we need to have the ability to manage this changes and track them to make sure that we embrace change so we deliver the best solution.

The best way to find all the inputs is to understand that they are hidden to us until we don’t start working the outputs (normally software implementations, but could be documents…), we just have to make sure that before we start working our inputs are good enough.

8 Responses to 'Forget about requirements, Software Development is all about inputs, outputs and actions.'

Subscribe to comments with RSS or TrackBack to 'Forget about requirements, Software Development is all about inputs, outputs and actions.'.

  1. [...] Forget about requirements, Software Development is all about inputs, outputs and actions – Alberto G [...]

  2. [...] Forget about requirements, Software Development is all about inputs, outputs and actions. Making Good Software (tags: programming) Blogroll [...]

  3. [...] this with my previous article about inputs, outputs and actions, The programming skills will help creating better outputs, the Relevant non programming skills will [...]

  4. [...] explained in my previous article about inputs, outputs and actions, inputs are the clues that leads us to find the best solution, in order to take the best decision [...]

  5. [...] change. Main point of Agile, all the inputs change during the software development process, actually most of them are yet to be [...]

  6. [...] is about the execution. A good design always turns to be the design that complies with all the inputs of the application, and that can only be proved once that the code is [...]

  7. [...] stability of the pyramid is at danger. This means that the code created to implement the specified inputs is not good enough to ensure the reliability of the software, it is also likely that when will like [...]

  8. Let me begin by saying I have been a longtime fan, first time commenter. I thought I should probably say thanks for posting this piece (and all your others), and I’ll be back!

    Tammy Mattheis

    10 Mar 10 at 3:50 pm

Leave a Reply