Denise‘s company formed a new team. They had a lot of low-quality legacy code, and it had gotten where it was, in terms of quality, because the company had no real policy or procedures which encouraged good code. “If it works, it ships,” was basically the motto. They wanted to change that, and the first step was creating a new software team to kick of green-field projects with an eye towards software craftsmanship.
Enter Jack. Jack was the technical lead, and Jack had a vision of good software. This started with banning ORM-generated database models. But it also didn’t involve writing raw SQL either- Jack hand-forged their tables with the Visual Table Designer feature of SQL Server Management Studio.
“The advantage,” he happily explained to Denise, “is that we can then just generate our ORM layer right off the database. And when the database changes, we just regenerate- it’s way easier than trying to build migrations.”
“Right, but even if we’re not using ORM migrations, we still want to write migration scripts for our changes to our database. We need to version control them and test them.”
“We test them by making the change and running the test suite,” Jack said.
And what a test suite it was. There was 100% test coverage. There was test coverage on simple getter/setter methods. There was test coverage on the data transfer objects, which had no methods but getters and setters. There were unit tests for functions that did nothing more than dispatch to built-in functions. Many of the tests just verified that a result was returned, but never checked what the result was. There were unit tests on the auto-generated ORM objects.
The last one, of course, meant that any time they changed the database, there was a significant risk that the test suite would fail on code that they hadn’t written. Not only did they need to update the code consuming the data, the tests on that code, they also had to update the tests on the autogenerated code.
Jack’s magnum opus, in the whole thing, was that he designed the software with a plugin architecture. Instead of tightly coupling different implementations of various modules together, there was a plugin loader which could fetch an assembly at runtime and use that. Unfortunately, while the whole thing could have plugins, all of the abstractions leaked across module boundaries so you couldn’t reasonably swap out plugins without rewriting the entire application. Instead of making a modular architecture, Jack just made starting the application wildly inefficient.
Denise and her team brought their concerns to management. Conversations were had, and it fell upon Jack to school them all. Cheerfully, he said: “Look, not everyone gets software craftsmanship, so I’m going to implement a new feature as sort of a reference implementation. If you follow the pattern I lay out, you’ll have an easy time building good code!”
The new feature was an identity verification system which called for end users to upload photographs of their IDs- drivers’ licenses, passports, etc. It was not a feature which should have had one developer driving the whole thing, and Jack was not implementing the entire lifecycle of data management for this; instead he was just implementing the upload feature.
Jack pushed it through, out and up into production. Somehow, he short-cut past any code reviews, feature reviews, or getting anyone else to test it. He went straight to a demo in production, where he uploaded his passport and license. “So, there you go, a reference implementation for you all.”
Denise went ahead and ran her own test, with a synthetic ID for a test user, which didn’t contain any real humans’ information. The file upload crashed. In fact, in an ultimate variation of “it works on my machine,” the only person who ever successfully used the upload feature was Jack. Of course, since the upload never worked, none of the other features, like retention policies, ever got implemented either.
Now, this didn’t mean the company couldn’t do identity verification- they had an existing system, so they just kept redirecting users to that, instead of the new version, which didn’t work.
Jack went on to other features, though, because he was a clever craftsman and needed to bring his wisdom to the rest of their project. So the file upload just languished, never getting fixed. Somehow, this wasn’t Jack’s fault, management didn’t hold him responsible, and everyone was still expected to follow the patterns he used in designing the feature to guide their own work.
Until, one day, the system was breached by hackers. This, surprisingly, had nothing to do with Jack’s choices- one of the admins got phished. This meant that the company needed to send out an announcement, informing users that they were breached. “We deeply regret the breach in our identity verification system, but can confirm that no personal data for any of our customers was affected.”
Jack, of course, was not a customer, so he got a private disclosure that his passport and ID had been compromised.
[Advertisement]Source: Read MoreÂ