Below are two flowcharts that describe the thinking process of two types of programmers. On the left is what I would call 'good' and on the right is 'bad'.
Programming is not just coding. There are a lot of things to do. But what you normally see is what is on the right. The programmer is given a problem and they try to throw a technology at it.
On the left, there are a lot of things to do before you ever get to programming. Not saying that there isn't a little experimentation. This diagram is a summary, so there is some wiggle room, but the good developer does something related to each subject we have outlined.
You might ask why these two are so different? The first reason is time. Often a developer is assumed to be programming, not researching and designing. The second reason is that the first diagram does not have a lot of feedback to the customer and people in general are results oriented.
You might also say that the diagram on the right is Agile. Yes it is Agile, but it does not create any real design data other than the program and the testing is only done by the user.
You might also say that the second diagram is wrong because it is missing much of what defines Agile. This is a fair criticism, but again, this is just what most programmers do, not what they should do.
The first diagram could be expanded to be iterative, but I left that out for a reason. The fact is that these are tasks that should be required or verified if you are forced to do waterfall or you are ding XP or Agile. Each point should at least be considered or you rely on recorded information gathered on prior iterations.
What is the message? There are no shortcuts!
No comments:
Post a Comment