I was recently watching a talk by Dan North. At one point he briefly talks about a project he worked on. For this project, the Ant build script was generated with an XSLT transform, producing a build script about 2 million lines long. Even though that is clearly horrible, my first fleeting thought was, Huh, I would have never thought to do that. That's pretty clever..
Dan North's Simplicity, the Way of the Unusual Architect, at the time of the story
That's pretty clever, is absolutely the wrong thought to have. I cannot fathom the monumental, wasted effort maintaining such a system. But I am also sure it started as someone's clever idea. There would be plenty out there who would say, Well, that project went wrong, but the idea itself isn't bad. It's pretty darn clever, really.
"Cleverness" like that always seems promising at first. It is a novel view of a problem at hand. Because clever ideas are novel in completely unexpected ways, they have unexpected consequences. Once in place, they become entrenched in the structure. Just implementing those ideas was an undertaking because of their cleverness. Throwing that all away is not an option. Keeping them working under evolving circumstances requires layering on additional cleverness. It all looks like a precarious game of Jenga. There are quirks to build around. There are blocks never to be touched.
Brian Kernighan said, Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? Those of us who are not clever enough are trapped. We plod through the complexity just trying not to break anything. Most importantly, we will all end up not being clever enough eventually.
We all seem to admire cleverness, despite its dark side. From a young age, we are praised for our cleverness. It becomes an admirable trait. Cleverness "on the computer" might even be why we do what we do. That's why we momentarily admire horrifying things, like XSLT transforming Ant scripts. Cleverness is not intelligence, though. We can be smart without doing clever things.
Smart people like to be challenged. Being clever is one sort of challenge, but there are others. A better challenge is to be dull. Think of the most boring, straightforward way of doing something. Make it just flexible enough, but don't over engineer. If it is simple enough for a brand new software developer to understand, you've achieved your goal. When you produce software that dull, you produce software that is maintainable, software that is able to evolve.
Recently I received a SunnyPeak Google Cardboard Viewer as a gift. The technology is pretty cool, allowing for any Android device to act as an inexpensive VR headset. There are a number of apps that provide interesting 3-D environments to explore. The challenge I ran into was that Google Cardboard does not work correctly on my Samsung Galaxy SIII. Instead of taking up the whole screen, the images take up only a part of the screen . A simple fix would be to change the settings in the Cardboard app, but Google made life way more "convenient" by allowing the settings to be changed only through scanning a QR code. After some Googling around, I came across a post where someone else was having the same problem. In the comments, someone had the answer . In short, the comment gives a link to a page to generate a settings QR code, and the settings to put in. After following the instructions, the app configured itself correctly and it worked great! If you are having the same probl
Magic numbers are considered such a scourge upon code bases that there tools out there to automatically find them and root them out. After all, who knows what setValue(6); really means? There are also many approaches to giving better names to magic numbers. Not all of them are good, though. For example, we have a callback that sets a completion percentage on a status: void callback(Status status) { status.updateProgress(0, "Starting"); // Do some stuff... status.updateProgress(25, "Some stuff done"); // Do some more stuff status.updateProgress(50, "More stuff done"); // Reticulating splines status.updateProgress(75, "Splines reticulated"); // Validate everything status.updateProgress(100, "Complete"); } Those percentages would get flagged as magic numbers by the automatic tools. The developer would need to extract those out to constants to make that tool happy. A thoughtful developer would create
Minification and compression of assets (JS and CSS) is a common practice across the Web today. It improves performance by reducing the amount of data that has to be transferred over the network, without changing the behavior of those assets. Because those assets are text, the size reductions can be dramatic, especially when we use both techniques together. Using these techniques, though, is not necessarily transparent. Generally, minified assets are referred to with a .min.* extension to indicate they are different (thus, minified jquery.js becomes jquery.min.js ). Because this convention is in the file name, it must also pass down into our references: <script src="jquery.min.js"></script> . To switch between the minified and un-minified versions, we have to actually change the code in the HTML. Source maps are a different, potentially more robust solution, but require support both in the browser and in build to generate those files. Compressed assets are e
Comments
Post a Comment