…then I watch it scroll away again! Have you ever wanted to do something with your software product that in all practicality was quite trivial? Have you later found out that to accomplish your task you had to entertain the entirety of a software ecosystem, most of which you didn’t create or have no control over? Hi, I’m Cliff. You’re here because you’re trapped behind a monitor watching cryptic text scroll up the screen at lightning speed. I’m here to remind you that you are not alone. Maybe you just wanted to patch a label on an app so that it aligned better with some other on-screen components. Maybe you merely wanted to borrow an algorithm that groups a bunch of stuff by individual days and labels them accordingly. Maybe you just wanted to run a code generator that promises to recreate a programming interface in a given language. Whatever the case you feel trapped because as the text scrolls by, you can smell your hard drive capacity nearing zero. You feel frustrated because you’re certain that the files currently downloading to your computer are identical to files in another location on the same machine but because of some cruel curse placed on you by the overlords of IT you are constrained to using them only with another product and not with the thing you are currently working on.
The correct use of software
I’d like to begin today’s topic by discussing use and reuse of software. As a developer, many of us are accustom to thinking in terms of source code. It is the primary means by which we communicate with the machines around us. I’d like to first highlight the one most overlooked principle of software design on the planet. Source code has only 2 uses. It’s primary use is to feed into the compiler and produce the thing we actually do use. It’s secondary use is a means of communicating with other like-minded developers what the overall flow and intent of a piece of software really is. I present this as overlooked and undervalued because the majority of us still believe software has other uses! Many believe that by placing source code on or scraping source code off of the clip board that they have somehow “used” it. While most will agree that copied code creates a problem some will argue that moving code solves the problem. In other words the argument goes, “you shouldn’t copy/paste, instead you should cut/paste!”
Whether you copy or cut source code you are not using or reusing a damned thing. Remembering what I started to explain above, using source code involves one of two actions, feeding a compiler or conveying the flow of logic. What gets often confused is the thing that comes from the source code is the thing we are really interested in. This is the thing that we really intend to use. When you copy or move text around in you’re editor you are merely altering the way in which you interact with your compiler. I’ll draw a line of abstraction here as well as you are actually changing the way you interact with your build toolchain. Think, for a moment, of a toolchain or better yet a tool. A screwdriver doesn’t care if you interact with it using your bare hands, some gloves, or a pair of pliers. Likewise your build toolchain doesn’t care if you’ve moved a snippet of source code from one file to another. The output will vary but you have not “used” that output.
If you can understand that cut/copy/paste relates to using your editor rather than your software then we can entertain the other thing that is often tied up in our misunderstanding of software use. Inserting or removing source code (by either cut/copy/paste) affects the “behavior” of the thing that your toll chain produces. Confusion comes from the thinking that application behavior is somehow tied to or the same as the source code it was created from. That idea is further reinforced by the use of debuggers that allow us to step through and execute lines of source code as if they were actual executables! To really understand the blur try the following exercise. The next time you feel as if you’ve successfully re-used an algorithm via the clipboard, take those same clipboard contents and place them into an empty text file. Save the text file using whatever extension and file system you like. start your stop watch (and ideally a video camera recording session). Execute the algorithm from the source file. Stop the stopwatch (and video recorder). Now measure the time (and effort if you video recorded yourself) between start and finish. The inverse of your measurement represents the total percentage of use you get out of that source code. The most prominent thing that would come from such an exercise is what is involved in replicating the behavior you hoped to achieve through the use of source code. The exercise is meant to illustrate behavior independent of and established software product. In even the most optimal cases where your source code is a scripting language you will see a disproportionate measurement of time and effort to recreate the behavior because of the other very overlooked and heavily misunderstood concept in software design…
Because many developers see the world through source code much is overlooked and underestimated in the way of dependencies. In all but the most obscure cases source code has dependencies. Unless you obsess over dependencies constantly you will not see them until they come crashing down on you. An exercise in agile software engineering is to reduce/remove as many of the dependencies as possible while still maintaining a true software component that illustrates the behavior you are after. The software component is not represented by source code (ignoring scripting languages for now). The software component is where the true use and reuse begins. The massive dependencies that unnecessarily sneak their way next to the behavior that you are after. I would go into a whole dissertation of dependency management, isolating components by exposing independent behaviors, and rapid feature based delivery but I feel the above exercise is enough to illustrate my current frustrations while proving a subtle point. When you go to exercise a piece of code or better, trigger a given behavior there exists a certain amount of dependencies. These dependencies are often mis-represented as more and more code is added to a given project. Time causes dependencies for other behaviors to obscure the dependencies of the behavior you are after. It is also these same dependencies that have me watching the text scroll in…