Scenario and work flow driven development. The ‘Just Enough’ model.
I really must get back to the code I was working on but in the meantime, some thoughts on software development.
I am a developer, I code in (mostly) assembler on z/OS. I love it. I like 3270 green screens too and do a lot of my work using them. I also like the web 2.0 stuff (I don’t do Java though!) but mostly just for interest. I am used to looking at a problem and writing some code to address it. I want my code to be perfect and do everything (or it seems that way). I have spent my life looking at how to address a problem from the code perspective and it has worked fine for a long time.
I think the first revelation I had was the idea of forgetting about the interface to solve a problem. This may seem obvious but we (or I do anyway) spend so much time working with a particular framework, environment or UI that whenever we think about a problem we invariably tie any solution to the environment it will live in. As developers we (well, I) tend to think of solutions in terms of code. If the only tool you have is a hammer, everything starts to look like a nail. When you are a programmer, every solution involves code.
The automatic association between UI, framework etc and the problem may not be a conscious one but it colors everything we do. Now this next step may seem blindingly obvious but in fact I found it very hard to do, and that is to forget about code, the UI, the framework etc and just concentrate of the data and the problem.
It (sort of) works like this:
You have a problem to solve.
You have ‘some’ data related to that problem.
How would you use that data (lets say it’s printed out so no code here) to resolve the problem? During this phase you may discover that certain information you need is missing.
What you end up with is an understanding of how to work through the data to solve the problem (the work flow) and also, an understanding of what additional data you need in order to do that. You may find you need a certain piece of data in order to decide what piece of data to look at next.
Notice that this has nothing to do with code, data collection, frameworks, presentation etc. You are just looking at the data and how to use it to solve the problem.
What you DO NOT end up with are requirements for data that you do not need! Since collecting data requires additional coding, testing, documentation etc; anything you can do to reduce those requirements will reduce your development time and costs and also increase the quality of your code since the less code you write, the less there is to go wrong (another of those blindingly obvious facts!).
The next phase is to take the problem and using the UI (NOT the framework, NOT the code), that is just the presentation interface, be it 3270, web, java, whatever and using the UI services it would ‘reasonably ‘ have (eg check boxes, buttons on a web or PC type app) within the framework you develop for and come up with a work flow that lets you work through the data that you have already identified you need, in order to solve the problem.
The idea here is NOT to think “Oh, the UI only has this function so I have to do something this way or present the data this way”. UI’s can be changed, that’s the whole point of this. Instead think about how you WANT it to work, how you want the user to navigate through various screens etc to complete the task. You may find it makes more sense to move some of the data you identified earlier to different places. You may find the interface simply does not (currently) do what you need to implement the work flow.
The idea here is find the best way for the user to use the UI to work through the data you have already identified to complete the task. Regardless of whether it is actually possible today.
What you are going to end up with is a list or requirements for changes and additions to various components that, when done will enable you to use the interface work flow you came up withe to solve the problem. It will be ‘just enough’. It will do what it is supposed to do, not more. The code will be ‘just enough’, it will do what it needs to do, not more. the data will be ‘just enough’ to solve the problem. You won’t be collecting data you don’t need.
Well, that’s my thought for the day. None of this is really new and it may be blindingly obvious to some, it wasn’t for me. Maybe all I’ve done is express it in a simplistic way (simple is always good in my book). After thirty odd years as a developer I think I have realized that I’ve been doing it ‘wrong’ all these years.