Yesterday I’ve attended my daughter’s “Curriculum Night” (yes, I am a very good and responsible dad, I even managed not only to recall where the school is, but also to successfully follow my wife’s instructions on how to find the classroom).

Listening to the teacher’s presentation, I was surprised by how process-oriented the education is (not having US education experience myself). Here is one of the processes that were presented by the teacher as a part of 5th grade curriculum:

Design Process

1. State the Problem
2. Gather Information
3. Explore Ideas
4. Select a Solution
5. Test and Evaluate
6. Redesign

And this is taught in elementary school! One question that I have now is: did most of software engineers skip the 5th grade? Or this is something new that was added to curriculum less than twenty-something years ago? The “Design Process” I see again and again, not only with interns or junior engineers, but also with some experienced people:

1. Pick the Task (or Get Assignment)
2. Pick a Solution
3. Implement
4. Try if it Works (sometimes)
5. Implement Whitebox Tests (only if forced to do testing. In a lot of cases tests are matching implementation one-to-one; if code has bugs – tests are ensuring that bugs are there)

Sometimes it even extends to:

6. Restlessly Defend Picked Solution as the Best One

Nope. Please, go back to elementaruy school. They can teach you how to do your job!

All right, all right, I agree, we do not have time for this, and, more important, our school district is not funded enough to bring you back to school. But I hope you did not skip classes when they tought reading. Or did you? If not, please read what these steps mean (or, at least, how I want you to understand them):

Design Process for Engineers

1. State the Problem

Describe in your words what is the problem you are trying to address. If you cannot clearly describe the problem – you do not understand it. If your friend does not understand your description - you do not understand it.

2. Gather Information

Starting with the most important one – are you really stating the right problem? Or even: did the person that originally stated it understand what she wanted? Is there already a solution for either directly the problem or something similar? How well does it fit your case?

3. Explore Ideas

There is a very high probablility that the first idea that comes to your mind is the wrong one. And do not forget to continue exploring on all steps. And please, PLEASE, do not limit yourself to your ideas only. There are a lot of smart people around.

4. Select a Solution

Remember: there is no selection if you have only one solution.

5. Test and Evaluate

Test not what you did, but whether the problem was solved. Evaluate all steps that were done before – starting from restating the problem. Quite possible that with all new information you have now your understanding of the problem may change.

And one of the most important evaluation aspects – decision whether you have to go to the step #6 or not. Understanding of what is “good enough” comes with experience, so do not trust yourself if you lack one.

6. Redesign

Return to #1. Always. Yes, I know, you think you are ready for #4. Forget what you see at this moment as a “better solution” – you are wrong (even if you are right!).

Bonus #1: Investigation Process (Elementary School Edition)

1. Question
2. Prediction
3. Materials
4. Procedure
5. Data/Results
6. Conclusion

Bonus #2: Writing Process (Elemenatry School Edition)

1. Prewrite
2. Rough Draft
3. Revise
4. Edit
5. Publish