It was late 2008, I was nearly finished writing an extension for the Windows 7 taskbar that would come with any Microsoft mouse or keyboard. It had passed all tests and was pretty much ready to release. My manager told me to write unit tests for it, because 95% of the deliverables in this group had unit tests and they wanted to check that box.
My work had been mostly feasibility studies and having proved it possible (it used the IAccessible COM interface instead of window handles) it had taken a few days to write and a few more to test. I explained that it was too small to have any layers, it was just a keystroke listener that called a handler. To apply unit testing would mean breaking it up, destabilizing it, and for no better purpose than to check a box. Unit tests are for components of larger projects, this really didn’t have components at all, unless you count tiny functions as components.
He wouldn’t relent, and before the conversation was over he suggested that I write separate code, completely outside the application, and write unit tests for those. It was at this point I decided to update my resume because there was something wrong with this guy’s mind. When he told me about Test Driven Development I made sure there was a clear path to an exit because I was talking to a lunatic. This was the first time I heard that litany “when the tests all pass, you’re done,” and decided that the Microsoft where I had been so proud to work in 1989 was completely gone.
I appealed to my manager’s manager, explained that the project would only be destabilized by making it amenable to unit testing. He swung his fist in an arc and intoned “gotta have those unit tests!”
Now, I’m all for regression testing, but since then I’ve worked with people who would write unit tests for one-line functions that added two constants. These are not engineers, these are fanatics with the outlook of teenagers who experiment with hair and clothing styles for three days. In short, fads.
The whole issue was interrupted by two events: record snowfall that made getting to work impossible, and the death of my father. When I returned from the funeral something had changed, and I had my first, and last, exposure to pair programming and resigned my contract the following day. I would rather be homeless than do pair programming again, and I will write about TDD and PP in another article. The PP followed the weirdest meeting I had ever attended anywhere, clearly meant to push me into a meltdown, which they figured would be easy given that I had just lost my father.
OK. I’m sure if anyone reads this and responds it will be to tell me that TDD is just wonderful and pair programming is really cool. I’m not interested. Those three hours of PP were the worst time of my life; I’ve been in, and forgotten, three major automobile accidents and the memories are bland compared to those three hours.
Fast forward. After years of doing iOS in Objective C I was introduced to Swift; I bought a course and started going through it. After a few hours the course introduced — I am not making this up — the use of emojis in variable and function names. Now, there may be people who think this is a cool feature but I wouldn’t work with them and were I a manager whose employee checked emoji names into a deliverable product I would call security have have him escorted from the building.
This is not engineering. This is Chewbacca figurines in code.
When I was writing code for medical devices I worked closely with real engineers, hardware and electrical and mechanical. Their work was sober and serious and not based on ephemera. They had standards. They did not develop “personal styles” whose success was measured by how difficult they were for others to read.
Example. About 20 years ago in one of those Microsoft magazines (MSJ? MSDN? I forget) someone used example code that introduced the trailblazing idea of putting spaces inside parentheses ( ( like this ) ). This looked so freaking goofy and weird that within a month half the development community was doing it. Again, like teenagers with scare-the-parents haircuts and ripped jeans. Many still do it. Given that I was charged with developing coding standards in many groups (I gave reasons based on studies of lexical parsing, not preferences based on giving coworkers headaches), I explicitly forbade it. Many objected, they “found it to be more readable.” Sure they did. Which is why they used as little whitespace as they could everywhere else.
Honestly, I don’t think software development is engineering any more than economics is science. Both have a really long way to go. In many gigs I was the first developer to write a design document, most companies regarded planning as a frivolity and preferred someone who just dove in and started slinging code, based on some hand-waving and vague descriptions.
Engineering is systematic, not playful.