I don’t like what is happening to the software industry. I’ve been a developer since 1988 and at Microsoft wrote earliest versions of software that many of you use. In the late 80s and early 90s Microsoft had a management policy whose foundation was enabling concentration and focus, minimizing interruptions because they knew that doing so enabled our best work.
We called this “flow.”
That recognition has vanished entirely, from Microsoft and with few exceptions from the entire industry. It has been replaced with bizarre and ritualistic “methodologies” that from all I’ve seen add little or no value; on the contrary, they emphasize interruptions. We now have “masters,” managers, and executives who have never written code and who view any desire to reduce interruptions as effete. Meetings are seen as legitimately productive uses of time. They almost never are.
When people are constantly interrupted they cannot concentrate. When they can’t concentrate they write code with more bugs. The response to this is not to return what worked so well before but to further adulterate the experience with having developers write tests. WRITE tests. Not perform manual testing before tossing it over the wall to QA, who could do their testing however they wanted, unprejudiced by knowledge of the code and not having the developer’s blind spots. These blind spots are an important point that I rarely see recognized.
It’s vital to have other people do testing; some will agree with me on that but I’ve read a lot of verbiage arguing otherwise, that testing is solely the responsibility of the developer, and in my experience this verges on madness. I will achieve far better results by writing design documents because in doing so I will run across those blind spots before I start to write. Were I to write unit tests I would forget the same cases in the tests as I would later overlook in the code. And unit tests are a lot of work and often of little value.
When I read others’ writing on software practices I read more and more about testing, less and less about good coding practices. A third of a century in the industry and I see code is even less legible than it was in 1988, and even more poorly structured.
There is even an approach called test-driven development that regards development as a secondary practice; if you must cut corners to meet a deadline, cut them in the code, not the tests.
People have forgotten that the objective of software development is software development. Testing is a markedly different skill that not all developers do as well as they do designs.
Before this began I usually worked closely with testers, writing tracelogging instead of unit tests and spending substantial amounts of time in the tester’s office, without bug-tracking or triage. He finds a bug, we read the tracelogging, I fix and he retests, total elapsed time ten minutes. The time to do a bug-tracking entry was more than twice this, and that was just the beginning. We bypassed all that and worked very well together.
