DaedTech

Stories about Software

Oct
17

By

The Myth of Quick Copy-And-Paste Programming

Category: Anti Patterns Tags: , , | 6 Comments

Quick and Dirty?

“We’re really busy right now–just copy that customer form and do a few find and replaces. I know it’s not a great approach, but we don’t have time to build the new form from scratch.”

Ever heard that one? Ever said it? Once, twice, dozens, or hundreds of times?

This has the conversational ring of, “I know I shouldn’t eat that brownie, but it’s okay. I’m planning to start exercising one of these days.” The subtext of the message is a willingness to settle–to trade self esteem for immediate gratification with the disclaimer “the outcome just isn’t important enough to me to do the hard thing.”

If that sounds harsh to you when put in the context of programming instead of diet and exercise, there’s a reason: you’re used to fooling yourself into believing that copy-and-paste programming sacrifices good design to save time. But the reality is that the “time savings” is a voluntary self-delusion and that it’s really trading good design for being able to “program” mindlessly for a few minutes or hours. Considered in this light, it’s actually pretty similar to gorging yourself on chocolate while thinking that you’ll exercise later when you can afford that gym membership and whatnot: “I’ll space out and fantasize about my upcoming vacation now while I’m programming and clean up the mess when I come back, refreshed.”

Hey, Wait a Minute

I know what you’re thinking. You’re probably indignant right now because you’re thinking of a time that you copied a 50,000 line file and you changed only two things in it.

Re-typing all 50,000 lines would have taken days, and you got the work done in minutes. The same number of minutes, in fact, that you’d have spent parameterizing those two differences and updating clients to call the new method, thus achieving good design and efficiency. Okay, so bad example.

Wait, Now I’ve Got It

Now, you’re thinking about the time that you copied that 50,000 line file and there were about 300 differences–no way you could easily have parameterized all of that. Only a copy, paste, and a bunch of find and replace could do the trick there.

After that, you were up and running in about an hour. And everything worked.

Oh, except for that one place where the text was a little different. You missed that one, but you found it after ten minutes of debugging.

Oh, and except for five more of those at ten or fifteen minutes a pop.

Oh, and then there was that twenty minutes you spent after the architect pointed out that a bunch of methods needed to be renamed because they made no sense named what they were in the new class. Then you were truly done.

Except, oh, crap, runtime binding was failing with that other module since you changed those method names to please the stupid architect. That was a doozy because no one noticed it until QA a week later, and then you spent a whole day debugging it and another day fixing it.

Oh, and then there was a crazy deadlock issue writing to the log file that some beta customer found three months later. As it turns out, you completely forgot that if the new and old code file methods executed in just the right interleaving, wackiness might ensue. Ugh, that took a week to reproduce and then another two weeks to figure out.

Okay, okay, so maybe that was a bad example of the copy-and-paste time savings.

Okay, Those Don’t Count

But you’re still mad at me. Maybe those weren’t the best examples, but all the other times you do it are good examples.

You’re getting things done and cranking out code. You’re doing things that get you 80% of the way there and making it so that you only have to do 20% of the work, rather than doing all 100% from scratch. Every time you copy and paste, you save 80% of the manpower (minus, of course, the time spent changing the parts of the 80% that turned out not to be part of the 80% after all).

The important point is that as long as you discount all of the things you miss while copying and pasting and all of the defects you introduce while doing it and all of the crushing technical debt you accrue while doing it and all of the downstream time fixing errors in several places, you’re saving a lot of time. I mean, it’s the same as how that brownie you were eating is actually pretty low in calories if you don’t count the flour, sugar, chocolate, butter, nuts, and oil.

Come to think of it, you’re practically losing weight by eating it.

We Love What We Have

Hmm…apparently, it’s easy to view an activity as a net positive when you make it a point to ignore any negatives. And it’s also understandable.

My flippant tone here is more for effect than it is meant to be a scathing indictment of people for cutting corners. There’s a bit of human psychology known as the Endowment Effect that explains a lot of this tendency. We have a cognitive bias to favor what we already have over what’s new, hypothetical, or in the possession of others.

Humans are loss averse (we feel the pain of a loss of an item more than we experience pleasure at acquiring the item, on average), and this leads to a situation in which we place higher economic value on things that we have than things that we don’t have. You may buy a tchotchke on vacation from a vendor for $10 and wouldn’t have paid a dollar more, yet when someone comes along and offers you $12 or $20 or even $30 for it, you suddenly get possessive and don’t want to part with it. This is the Endowment Effect in action.

We Love Our Copy Paste Code

What does this have to do with copying and pasting code? Well, if you substitute time/effort as your currency, there will be an innate cognitive bias toward adapting work that you’ve already done as opposed to creating some theoretical new implementation. In other words, you’re going to say, “This thing I already have is a source of more efficiency than whatever else someone might do.”

This means that, assuming each would take equal time and that time is the primary motivator, you’re going to favor doing something with what you already have over implementing something new from scratch (in spite of how much we all love greenfield coding). Unfortunately, it’s both easy and common to conflate the Endowment Effect’s cognitive bias toward reuse with the sloppy practice of copy and paste.

At the point of having decided to adapt existing code to the new situation, things can break one of two ways. You can achieve this reuse by abstracting and factoring common logic, or you can achieve it by copy and paste.

Once you’ve already decided on reuse versus blaze a new trail, the efficiency-as-currency version of the Endowment Effect has already played out in your mind–you’ve already, for better or for worse, opted to re-appropriate existing work. Now you’re just deciding between doing the favorable-but-hard thing or the sloppy-and-easy thing. This is why I said it’s more like opting to stuff your face with brownies for promises of later exercise than it is to save time at the expense of good design.

Copy Paste Programming as Empty Calories

Think about it. Copy and paste is satisfying the way those empty calories are satisfying. Doing busy-work looks a lot like doing mentally taxing work and is often valued similarly in suboptimally incentivized environments.

So, to copy and paste or not to copy and paste is often a matter of, “Do I want to listen to talk radio and space out while getting work done, or do I want to concentrate and bang my head against hard problems?” And if you do a real, honest self-evaluation, I’m pretty sure you’ll come to the same conclusion.

Copying and pasting is the reality television of programming–completely devoid of meaningful substance in favor of predictable, mindless repetition.

Quick and Dirty is Just Dirty

In the end, you make two decisions when you go the copy-and-paste route. You decide to adapt what you’ve got rather than invent something new, and that’s where the substance of the time/planning/efficiency decision takes place. And once you’ve made the (perfectly fine) decision to use what you’ve got, the next decision is whether to work (factor into a common location) or tune out and malinger (copy and paste).

And in the end, they’re going to be a wash for time. The up front time saved by not thinking through the design is going to be washed out by the time wasted on the defects that coding without thinking introduces, and you’re going to be left with extra technical debt even after the wash for a net time negative.

So, in the context of “quick and dirty,” the decision of whether new or reused is more efficient (“quick”) is in reality separated from and orthogonal to the decision of factor versus copy and paste (“dirty”). Next time someone tells you they’re going with the “quick and dirty” solution of copy and paste, tell them, “You’re not opting for quick and dirty–you’re just quickly opting for dirty.”

By the way, if you liked this post and you're new here, check out this page as a good place to start for more content that you might enjoy.

Oct
4

By

Favor Outcomes Over Rules

Category: Anti Patterns Tags: , , , | 3 Comments

Cargo Cults and Angry Monkeys

If you have never heard the term “Cargo Cult Programming“, it’s an it’s an excellent way to describe blindly following processes without understanding the theory behind them. The term originates from a story about aboriginal islanders during World War II. During the war, cargo planes regularly (and from their perspective, magically) arrived with supplies and food that benefited these islanders and then after the war the planes stopped coming. This apparently didn’t stop the aboriginals from building ad-hoc landing strips and the like in hopes of ‘summoning’ more planes with supplies. If that story isn’t to your liking, there is another one of questionable accuracy about monkeys and bananas.

I’ve made a fair number of posts lately that address subjects near and dear to programmers while still having broader reach and this is certainly another such subject. Doing things without understand why is generally the province of the incurious or the busy, but I think it’s worth generally forcing yourself to ask why you’re doing pretty much anything, particularly if you’re in a fairly cerebral line of work. As professionals, it behooves us to realize that we want supplies or that we want not to get sprayed rather than thinking that building landing strips and beating up monkeys are just things that we do and such is life.

In fact, I’d venture to say that we pride ourselves in this sort of thing as we advance in our careers. As programmers, we even help our users understand this concept. “I understand that you normally push the green button three times and hit the backspace key while pressing the mute button, but what are you actually trying to do when you do all that?” How often have you asked a user something like this? In essence you’re saying “forget the process for a minute — what’s the larger goal here?”

Do Unto Others

It then bears asking, if we pride ourselves on critical thinking and we seek to help users toward that end, why do we seem to encourage each other to dance for supplies and spray our team members with cold water? Why do we issue cryptic cargo cult orders to other programmers when we understand our own rationale? Let me give an example.

A few years back I was setting up a new machine for work on a project to which I was new, and the person guiding me through the setup told me that I needed to install KDiff, a spectacularly average comparison tool that even then hadn’t been revved or maintained in a few years. Now, I have nothing, per se, against KDiff, and the price is right, but this struck me as a very… specific… order. What difference did it make what I used for diff? I had used a paid version of Beyond Compare prior to that and always liked it, but when it comes to tooling I do enjoy poking around and so I didn’t mind trying a different tool.

I’m pickier about some things than others, so I just said “Bob’s Your Uncle,” installed KDiff and didn’t think about it again for a long time. It was actually many months later that I was sitting in on a code review for a developer who had just started on the project and found out the reasoning behind this cargo cult practice. The developer whose code was being reviewed casually opened BeyondCompare and one of the more tenured reviewers than me promptly freaked out that he wasn’t using KDiff. Bemused, I tuned in to hear the answer to a question that I’d completely forgotten about. The issue is that the project had a handful of XML files containing application meta-data that were source controlled and that some unnamed developer had, at some point, done something, presumably with some sort of diff tool, that had allegedly hosed one of these files by screwing up the text encoding. Nobody in the room, including the freaker-outer, knew who this was or exactly how or when it had happened, but nonetheless, it had been written in stone that from that day, Thou Shalt Use KDiff if you want to avoid punishment in the form of Biblical plagues.

This certainly wasn’t my only experience with such a thing. More recently, I overheard that the procedure for editing a particular file in source control was to grab the latest, edit it really fast and then check it in immediately. I was a bit perplexed by this until I learned that the goal was to avoid merge conflicts as this was a commonly edited file. I thought, why not just say in the first place that a lot of people edit this file and that merge conflicts are bad, in the same way that I had previously thought “why not just tell people that you’re worried about messed up encodings?”

And that line of questioning really drives to the heart of the matter here. Developers are generally quite skilled and pretty intelligent people and, more importantly, they tend to be be people that like to solve problems. So why not give them the benefit of the doubt when you’re working with them? Instead of giving your peers rote procedures to follow because they happened to work for you once, why not explain the problem and say “this is how I solved it, but if you have a better idea, I’m all ears!”

And you know what? They might. What if instead of forcing people to use KDiff, someone had written a validation script for the offending file that prevented checkins of a badly formed edit? What if instead of having flash edit-checkins of a file, the design of the application were altered to eliminate the contention and potential for error around that file? I suggest these things because I’m a fan of making the bad impossible. Are they the greatest ideas? Are they even practical in those situations? I honestly don’t know, but they might be approaches that have the advantage of placing fewer restrictions on developers or meaning one less thing to remember.

I would encourage you to trust your peers to grasp the bigger picture whenever possible (unless perhaps they’ve demonstrated that this trust isn’t warranted). As I say in the title, it seems like a good idea to favor describing desired outcomes over inventing rules to be memorized. With the former approach you free people you work with to be creative. With the latter approach, you constrain them and possibly even stress them out or frustrate them. And who knows, they may even surprise you with ideas and solutions that make your life easier.

Oct
2

By

How Software Groups Rot: Legacy of the Expert Beginner

Category: The Life of a Programmer Tags: , , , | 31 Comments

Expert Beginner Recap

In my last post I introduced the term “Expert Beginner” to describe someone who has capped out in their learning at some sort of local maximum, convinced that the local is global. Expert Beginners are developers who do not understand enough of the big picture to understand that they aren’t actually experts. What I mean by this is that they have a narrow enough perspective to think that whatever they have been exposed to is the best and only way to do things; examples would include a C# developer who pooh-poohs Java without ever having tried it, or a MySQL DBA who dismisses the NoSQL movement as a passing fad. This isn’t to say that not liking a technology or not having worked with one makes someone an Expert Beginner, but rather the vaguely solipsistic mindset that “if it’s not in my toolchest or something I’ve had experience with, it’s not worth doing.”

Another characteristic of the Expert Beginner, however, is that they have some position of relative authority or influence within a software group. In my last post, I proposed the term Expert Beginner without explaining the rationale, planning to discuss that here. The Advanced Beginner is someone who is in the advanced stage of being a beginner, whereas the Expert Beginner descriptor is both literal and intentionally ironic; it’s literal in that someone with that much practice at being a beginner could be said to be an expert and ironic in that the “expert” title is generally self-applied in earnest or else applied by managers or peers who don’t know any better.

The iconic example might be the “tech guy” at a small, non-technical firm. He “knows computers” so as the company grew and evolved to have some mild IT needs, he became a programming dilettante out of necessity. In going from being a power user to being a developer, his skills exceeded his expectations, so he became confident in his limited, untrained abilities. Absent any other peers in the field, the only people there to evaluate his skills are himself and non-technical users who offer such lofty praises as “it seems to work, kind of, I think.” He is the one-eyed man in the valley of the blind and, in a very real and unfortunate sense, a local expert. This is the iconic example because it has the fewest barriers to Expert Beginnerism–success is simple, standards are low, actual experts are absent, competition is non-existent, and external interaction is not a given.

A Single Point of Rot…

So far I’ve talked a lot about the Expert Beginner–his emergence, his makeup, his mindset, and a relatively sympathetic explanation of the pseudo-rationality, or at least understandability, of his outlook. But how does this translate into support of my original thesis that Expert Beginners cause professional toxicity and degeneration of software groups? To explain that, I’m going to return to my bowling analogy, and please bear with me if the metaphor is a touch strained. For those of you who didn’t read the first post, you might want to give the second section of it a read because this is a lot to rehash here.

Let’s say that bowling alleys make their money by how well their bowlers bowl and that I live in a small town with a little, startup bowling alley. Not being able to find any work as a software developer, I try my hand bowling at the local alley. I don’t really know what I’m doing, and neither do they, but we both see me improving rapidly as I start bowling there, in spite of my goofy style. My average goes up, the bowling alley makes money, and life is good–there’s no arguing with profit and success!

Around about the time my score was topping 150 and the sky seemed the limit, the bowling alley decided that it was time to expand and to hire a couple of entry-level bowlers to work under my tutelage. On the day they arrived, I showed them how to hold the ball just like I hold it and how to walk just like I do. When they ask what the thumb and finger holes are for, I respond by saying, “don’t worry about those–we don’t use them here.” Eager to please, they listen to me and see their averages increase the way mine had, even as I’m starting to top out at around a 160 average.

As time goes by, most of them are content to do things my way. But a couple are ambitious and start to practice during their spare time. They read books and watch shows on bowling technique. One day, these ambitious bowlers come in and say, “the guys on TV put their fingers in the ball, and they get some really high averages–over 200!” They expect me to be as interested as they are in the prospect of improvement and are crestfallen when I respond with, “No, that’s just not how we do things here. I’ve been bowling for longer than you’ve been alive and I know what I’m doing… besides, you can’t believe everything you see on TV.”

And thus, quickly and decisively, I squash innovation for the group by reminding them that I’m in charge by virtue of having been at the bowling alley for longer than they have. This is a broadly accepted yet totally inadequate non sequitur that stops discussion without satisfying. At this point, half of the ambitious developers abandon their “fingers in the ball” approach while the other half meet after bowling at another alley and practice it together in semi-secret. After a while, their averages reach and surpass mine, and they assume that this development–this objective demonstration of the superiority of their approach–will result in a change in the way things are done. When it instead results in anger and lectures and claims that the scores were a fluke and I, too, once bowled a 205 that one time, they evaporate and leave the residue behind. They leave my dead-end, backward bowling alley for a place where people don’t favor demonstrably inferior approaches out of stubbornness.

The bowling alley loses its highest average bowlers not to another alley, but to an Expert Beginner.

…That Poisons the Whole

The bowlers who don’t leave learn two interesting lessons from this. The first lesson they learn is that if they wait their turn, they can wield unquestioned authority regardless of merit. The second lesson they learn is that it’s okay and even preferred to be mediocre at this alley. So when new bowlers are hired, in the interests of toeing the company line and waiting their turn, they participate in the inculcation of bad practices to the newbies the same way as was done to them. The Expect Beginner has, through his actions and example, created additional Expert Beginners and, in fact, created a culture of Expert Beginnerism.

The other interesting development that results comes in the acquisition process. As the Expert-Beginner-in-Chief, I’ve learned a pointed lesson. Since I don’t like being shown up by ambitious young upstarts, I begin to alter my recruitment process to look for mediocre “team players” that won’t threaten my position with their pie-in-the-sky “fingers in the ball” ideas. Now, I know what you’re thinking–doesn’t this level of awareness belie the premise of the Expert Beginner being unaware of the big picture? The answer is no. This hiring decision is more subconscious and rationalized than overt. It isn’t, “I won’t hire people that are better than me,” but, “those people just aren’t a good fit here with my ‘outside the box’ and ‘expert’ way of doing things.” And it may even be that I’m so ensconced in Expert Beginnerism that I confuse Competent/Expert level work with incompetent work because I don’t know any better. (The bowling analogy breaks down a bit here, but it might be on par with a “bowling interview” where I just watched the form of the interviewee’s throw and not the results, and concluded that the form of a 220 bowler was bad because it was different than my own.) And, in doing all this, I’m reinforcing the culture for everyone including my new Expert Beginner lieutenants.

And now the bowling alley is losing all of its potentially high average bowlers to a cabal of Expert Beginners. Also notice that Bruce Webster’s “Dead Sea Effect” is fully mature and realized at this point.

Back in the Real World

That’s all well and good for bowling and bowling alleys, but how is this comparable to real software development practices? Well, it’s relatively simple. Perhaps it’s a lack of automated testing. Giant methods/classes. Lots of copy and paste coding. Use of outdated or poor tooling. Process. It can be any number of things, but the common thread is that you have a person or people in positions of authority that have the culturally lethal combination of not knowing much; not knowing what they don’t know; and assuming that, due to their own expertise, anything they don’t know isn’t worth knowing. This is a toxic professional culture in that it will force talented or ambitious people either to leave or to conform to mediocrity.

You may think that this is largely a function of individual personalities, that departments become this way by having arrogant or pushy incompetents in charge, but I think it’s more subtle than that. These Expert Beginners may not have such personality defects at all. I think it’s a natural conclusion of insular environments, low expectations, and ongoing rewards for mediocre and/or unquantifiable performances. And think about the nature of our industry. How many outfits have you worked at where there is some sort of release party, even (or especially) when the release is over budget, buggy and behind schedule? How many outfits have you worked at that gave up on maintaining some unruly beast of an application in favor of a complete rewrite, only to repeat that cycle later? And the people involved in this receive accolades and promotions, which would be like promoting rocket makers for making rockets that looked functional but simply stopped and fell back to Earth after a few hundred feet. “Well, that didn’t work, Jones, but you learned a lot from it, so we’re promoting you to Principal Rocket Builder and having you lead version two, you rock star, you!” Is it any wonder that Jones starts to think of himself as King Midas?

As an industry, we get away with this because people have a substantially lower expectation of software than they do of rockets. I’m not saying this to complain or to suggest sweeping change but rather to explain how it’s easy for us to think that we’re further along in our skills acquisition than we actually are, based on both our own perception and external feedback.

Create a Culture of Acquisition instead of Stagnation

Having identified a group-(de)forming attitude that could most effectively be described as a form of hubris, I would like to propose some relatively simple steps to limit or prevent this sort of blight.

First of all, to prevent yourself from falling into the Expect Beginner trap, the most important thing to do is not to believe your own hype. Take pride in your own accomplishments as appropriate, but never consider your education complete or your opinion above questioning regardless of your title, your years of experience, your awards and accomplishments, or anything else that isn’t rational argumentation or evidence. Retaining a healthy degree of humility, constantly striving for improvement, and valuing objective metrics above subjective considerations will go a long way to preventing yourself from becoming an Expert Beginner.

In terms of preventing this phenomenon from corrupting a software group, here is a list of things that can help:

  1. Give team members as much creative freedom as possible to let them showcase their approaches (and remember that you learn more from failures than successes).
  2. Provide incentives or rewards for learning a new language, approach, framework, pattern, style, etc.
  3. Avoid ever using number of years in the field or with the company as a justification for favoring or accepting anyone’s argument as superior.
  4. Put policies in place that force external perspectives into the company (lunch-and-learns, monthly training, independent audits, etc).
  5. Whenever possible, resolve disputes/disagreements with objective measures rather than subjective considerations like seniority or democratic vote.
  6. Create a “culture of proof”–opinions don’t matter unless they’re supported with independent accounts, statistics, facts, etc.
  7. Do a periodic poll of employees, junior and senior, and ask them to list a few of their strengths and an equal number of things they know nothing about or would like to know more about. This is to deflate ahead of time an air of “know-it-all-ism” around anyone–especially tenured team members.

This list is more aimed at managers and leaders of teams, but it’s also possible to affect these changes as a simple team member. The only difference is that you may have to solicit help from management or persuade rather than enforce. Lead by example if possible. If none of that is possible, and it seems like a lost cause, I’d say head off for greener pastures. In general, it’s important to create or to have a culture in which “I don’t know” is an acceptable answer, even for the most senior, longest-tenured leader in the group, if you want to avoid Expert Beginner fueled group rot. After all, an earnest “I don’t know” is something Expert Beginners never say, and it is the fundamental difference between a person who is acquiring skill and a person who has decided that they already know enough. If your group isn’t improving, it’s rotting.

Series is continued here: “How Stagnation is Justified: Language of the Expert Beginner”

No Fields Found.

Sep
28

By

You Can Tell a Lot About Developers From Their Scratchpads

Category: Language Agnostic, Uncategorized Tags: , | 14 Comments

What is a Scratchpad?

When you have a question like “what exception is thrown when I try to convert a long that is too big to an integer” or “what is the difference in performance between iterating over a list or a dictionary converted to a list” what do you do? Google it? Phone a friend? Open up an instance of your IDE and give it a try? I think that sooner or later, most developers ‘graduate’ to the latter, particularly for things that can’t be answered with a quick search or question of a coworker. And, if they wind up doing this enough times, they start creating a project or project(s) with titles like “dummy”, “scratchpad”, “throwaway”, “junk”, etc — you get the idea.

As this practice grows and flourishes, it starts to replace google searches and ask a coworker to a degree, even when those things might be quicker. If you get very used to setting up experiments in this fashion, it tends to be almost as quick as a search, and there’s less potential for wrong or misleading information. This is a very useful practice but, more interestingly for the purposes of this post, I think the makeup of this scratchpad (I’m using this term because it’s what I name mine) can tell you a lot about the developer using it. In fact, I believe strongly enough in this that I see a lot of value in the interview question “tell me about your scratchpad and how you use it.”

I’ll say in advance that I’m going to paint with some broad strokes here. So, please read the following while bearing in mind the caveat that there will, of course, be exceptions to the ‘rules’ that I’m describing. In the examples below that describe a single type of scratchpad, please note that I’m referring to situations where this is the primary or only scratchpad that the developer uses. I’ll describe the “arsenal” of scratchpads further down.

No Scratchpad

If someone doesn’t have something like this, they’re quite likely either not very seasoned as a developer or else not very inquisitive when it comes to understanding their craft. The lack of such a playpen project implies that they either don’t experiment or that they experiment in production code, which is pretty low rent and sloppy. (One possible exception is that they experiment in a project’s unit tests, which is actually a pretty reasonable thing to do, and an example of a reason for my “broad strokes” caveat). In either case, they’re lacking a place that they can go in and just throw some code around to see what happens.

Extrapolating out to the way a person with no scratchpad works, it seems very likely that you will observe a lot of “debugger driven development” and “programming by coincidence”. The reason I say this is that this person’s natural reaction to a lack of understanding of some facet of code will most likely be to try it in the production code, fire up the application, and hope it works. I mean, lacking a playpen and tests, what else can you really do? It’s all well and good to ask a coworker or read something on stack overflow, but at some point an implementation has to happen, and when it does, it’s going to be in the production code and it’s probably going to be copy-pasted in as a matter of faith.

I’d be leery of a programmer with no scratchpad. It might be lack of experience, lack of curiosity, or lack of interest, but I’d view this as most likely a lack of something.

Application Scratchpad

This is a scratchpad project that has the kitchen sink, from persistence on up to the GUI. In shops/groups that make a single product, it may be as simple as a duplicate of that project. In shops with more projects, it may be one of them or a composite of them. But, whatever it is, it’s a full fledged application.

Extra points here for being clever enough to have a consequence-free, dummy environment and for recognizing the value of experimentation. This is usually a sign of an inquisitive developer who wants to take things apart and poke at them, or at least a conscientious one who wants to try things out in dress-rehearsal before going live. I’d take some points away, however, for the monolithic approach here, assuming that this is the primary scratchpad and not an auxiliary or temporary approach. The reason I’m not such a fan of this is that it’s indicative of someone who hasn’t yet learned to think of an application in seams, components, modules, units, etc.

I mean, think about how this goes. “I wonder what happens if I use a string array instead of a string list here” leads to trying out the change and then firing up an entire application, complete with GUI bells and whistles, database access, file reads/writes, loggers, etc. This represents a view of the software that essentially says “it’s all or nothing, baby — here we go.” Good on them for the experimentation, but we can certainly do better.

Console Based Scratchpad

The console scratchpad (and this is a little Visual Studio specific, though it’s applicable to other IDE/environments as well) is one in which the main running application is one that writes to and reads from the console. If you wanted to time stuff you’d be doing so using a lot of System.out.println() or Console.WriteLine() or whatever the equivalent in your choice of language.

This correlates with the good characteristics of the GUI/application scratchpad (curiosity, judiciousness) but adds a bit more sophistication. A developer with a console based scratchpad understands how to decompose and abstract concepts and how to isolate problems. I think that this is potentially indicative of a competent and potentially great developer perhaps ready for a push.

Class Library Scratchpad

The most sophisticated scratchpad, in my mind, is the class library scratchpad. This is a scratchpad that has no program output of any sort and cannot be run independently. What this means is that the developer is used to reasoning about units and experimenting in very small, isolated fast feedback loops. Someone doing things this way clearly understands that increasingly complex applications are assembled from solutions to manageable problems rather than with some kind of irreducibly complex, inter-connected gestalt. Someone with this style of scratchpad is almost certainly a unit tester and most likely a practitioner of TDD (I certainly recognize my own bias here). But the most important thing here is the ultra fast and simple feedback loop, where answers to “how does this work” are provided right in the IDE itself (and extra points for anyone running a continuous integration tool like NCrunch.

Monolithic Scratchpad

A monolithic scratchpad is one that tends to be a developer’s only scratchpad. I think that this tends to be indicative of an architecturally minded developer capable of thinking in significant abstractions. The monolithic scratchpad is one that encompasses all of the projects above in one. It has test projects for fast feedback. It has a persistence model or two and a domain of sorts. It has a web front end and a desktop front end and mobile front end. In short, the developer organically evolves this scratchpad to suit whatever experimentation needs arise, demonstrating an ability to grow an application in response to whatever needs arise. Someone with this sort of scratchpad setup is someone I’d keep my eye on as a potential architect.

Arsenal of Scratchpads

An arsenal of scratchpads is indicative of a developer seasoned enough to understand that different questions call for different environments, but someone more silo-oriented and, perhaps, very well organized in a sense. While it may not occur to this person to blend scratchpad needs into an ad-hoc, decently architected application, the work nevertheless exists in such a way that it’s easy to find, access, and use. Since the response to new situations is new scratchpads, the critical fast feedback loop is there since they never get very big. I think that this practice is indicative of someone who might excel in small to medium sized picture development work or, who might do well on the path to project management. A monolith scratchpadder and an arsenal scratchpadder could probably form a pretty good leadership tandem on a project.

What Does your Scratchpad Look Like?

I’d like to reemphasize that this is a fairly lighthearted post that I fully acknowledge may completely miss the mark in categorizing some people. But, I do think there’s a grain of truth to it, and I stand by my assertion that this would make for an excellent interview question. If you have one of these types of scratchpads and either reinforce or poke holes in my premise, please weigh in. Same if you have a scratchpad setup I hadn’t thought of.

Sep
20

By

Changing My Personal Coding Standards

Category: The Life of a Programmer Tags: |

Many moons ago, I blogged about creating a DX Core plugin and admitted that one of my main motivations for doing this was to automate conversion of my code to conform to a standard that I didn’t particularly care for. One of the conversions I introduced, as explained in that post, is that I like to prepend “my” as a prefix on local, method level variables to distinguish them from method parameters (they’re already distinguished from class fields, which are pretended with an underscore). I think my reasoning here was and continues to be solid, but I also think that it’s time for me to say goodbye to this coding convention.

It will be tough to do, as I’ve been in the habit of doing this for years. But after a few weeks, or perhaps even days, I’m sure I’ll be used to the new way of doing things. But why do this? Well I was mulling over a problem in the shower the other day when the idea first took hold. Lately, I’ve been having a problem where the “my” creeps its way into method parameters, thus completely defeating the purpose of this convention. This happens because over the last couple of years, I’ve been relying ever-more heavily on the “extract method” refactoring. Between Code Rush making this very easy and convenient, the Uncle Bob, clean-coding approach of “refactor ’til you drop”, and my preference for TDD, I constantly refactor methods, and this often results in what were local variables becoming method parameters but retaining their form-describing (misleading) “my”.

What to do? My first thought was “just be diligent about renaming method parameters”, but that clearly violates my philosophy that we should make the bad impossible. My second thought was to write my own refactoring and perform some behind-the-scenes black magic with the DXCore libraries, but that seems like complete overkill (albeit a fun thing to do). My third thought bonked me in the head seemingly out of nowhere: why not just stop using “my”?

I realized that the reasons I had for using it had been slowly phased out by changes my approach to coding. I wanted to be able to tell what scope a member was instantly by looking at it, but that’s pretty easy to do regardless of what you name them when you’re writing methods that are only a few lines long. It also becomes easy to tell the scope of things when you give longer, more descriptive names to local, instead of using constants. And techniques like command query separation make it rare that you need to worry about the scope of something before you alter it since the small method’s purpose (alteration or querying) should be readily apparent. Add to that the fact that other people I collaborate with at times seem not to be a fan of this practice, and the reasons to do it have all kind of slipped away for me except for the “I’ve always done it that way” reason, which I abhor.

The lesson here for me and hopefully for anyone reading is that every now and then, it’s a good idea to examine something you do out of pure habit and decide whether that thing makes sense any longer. The fact that something was once a good idea doesn’t mean that it always will be.

« Older Posts
Newer Posts »