Favor Deletable Code Over Reusable Code

As problem solvers who work primarily in the medium of software, we're sold reusability throughout our careers (and even, likely, in our educations). We're told that if we just think ahead, if we put forth more effort, we can jump to a new plane of abstraction and achieve a solution that will be usable in the future to more quickly and easily solve a similar problem. Although this sounds pretty awesome in theory, I don't buy it in practice.

Arguments against optimizing for reuse

The first real problem I have with premature abstraction (in the hope of reuse) is just that -- it's premature. We'd like to think we know how our system ought to flex in the future, but we just don't. We're not fortune tellers.

We mean well. We build a more general solution than needed to solve a real problem

Our hope, thinking and intention is that future, similar problems will fit nicely into our "framework"

This sounds great, but there's a lot that can go wrong.

Firstly, what happens if our expanded solution doesn't "fully" solve the problem at hand?

Do we rewrite our more general solution to accommodate the actual problem? I find, generally, we don't. Instead we extend and further abstract our large solution to make it encompass the areas we missed. If we do re-write the general solution entirely, the previous general solution was effectively a time sink.

There's a fair amount of regression headache here as well. If I decided to extend my prior abstraction, then I have to do without breaking the parts that partially solved the problem to begin with. Also, assuming I still believed parts of the original abstraction to be valuable to future solutions, I would be required to also keep those from breaking.

 Secondly, there's a question I try to ask myself before I solve future problems: what will happen if this problem is a one-off? I usually have a few different answers to this

• I will have wasted time building abstractions and tests that weren't actually needed
• I will have obfuscated the intent of the solution with unnecessary abstraction, forcing future maintainers (myself included) to understand a more general problem than the one actually being solved, and
• I will have introduced more actual code and tests to maintain (in many codebases this may be a drop in a bucket, but still, more is more)

The third and final consideration I have before thinking about reuse is really a few tightly-related questions, pertaining to reuse itself

1. If a future problem is solvable by my abstraction, how will developers know to use it?
2. If a future problem looks like it's solved by my abstraction, but it's actually a different problem, how will other developers know not to use my abstraction?
3. What happens when a future problem is 90% solved by my abstraction? Is it flexible enough that someone else will be able to extend it to fit that extra 10%, while maintaining its integrity?

In my fairly short exposure to professional software development, I find the answers are something along the lines of

1. They won't. They'll build another solution, and maybe their own abstraction framework to some degree.
2. See 1, they probably won't ever see my abstraction or understand it. Although, I have seen a good bit of the "copy the original source, and tweak to fit" pattern applied in response to this question
3. It won't be flexible enough. They'll build another solution.

Like I said, I'm a novice developer. So if you have solutions to these questions and problems, I'm eager to hear them!

Deletable code

Alright, honesty time. The above words are truly my take on some points made in Greg Young's the art of destroying software talk. At this point, I could spend paragraphs describing the value obtained by having code that, by nature, is easy to delete. But, to do so would be a waste of time when Greg has so well articulated the points. So, with that, I urge you to watch the linked talk, and rip my arguments to shreds in the comments section.

Baby Don't Fear the Code Review

Although I'm (at best) a novice in the software engineering industry, I've had the opportunity to provide and receive many code reviews. I don't know of many companies that allow their junior developers to perform code reviews, but I'm not complaining; reading others' code is an invaluable practice, in my opinion.

I wanted to share some of the dos and don'ts that are floating around in the back of my head, so here they are.

• Don't provide feedback without reason. "Because I said so" and "because that's how we do things" may have been acceptable reasons from our parents when we were 7, but they just don't stand up in any half-professional industry.
• Do ask questions as a reviewer. If something you are reviewing doesn't make sense to you, it probably won't make sense to others. You may very well be fumbling to understand some malformed abstraction, or trying to mentally unravel some code that will prove difficult to maintain. You are doing yourself and the coder a discredit by not making a sincere effort to understand what you are reviewing.
• Do ask question as the programmer whose code is being reviewed. The worst thing you can do is sheepishly accept feedback that you don't understand. Always dig deeper, try to find the reasons behind the reviewer's feedback, strive to uncover the Why.
• Do favor verbal, in-person reviews over reviews done in a tool (if possible). Actually walking through the code with a peer has the potential to make the process more of a discussion than a chat-room session. I have found, through my short experience, that in-person reviews also tend to be conductive to question asking, and help alleviate many of the communication and timing errors that are so prone to occur in tools.
• Don't take it personally -- you are not your code. Try to consider code reviews as learning experiences, as opportunities to gain insight from the feedback of your peers.
• Do get an informal review of your code review. I know that sounds strange, let me restate that differently. Ask the programmer whose code you are reviewing if your comments are clear, if you had comments that weren't really valuable, if some element of the process could be improved, etc.... Feedback need not be one-way, and there is generally room for improvement in any process. Seek improvement.

Software Engineering Lessons from Adventure Time

For the past year or so, I've really enjoyed the show Adventure Time. At first glance it seems like a wacky (very wacky) kids show. Eventually, after watching a few episodes, I found myself hooked and haven't strayed to another cartoon since.

Perhaps my enjoyment is generational (being a 90's kid and all) or perhaps the show transcends generational barriers. I truly don't know. All I know is that it's a truly enjoyable show filled with lessons about life, friendship and adventure.

Being one who enjoys software engineering, I will do my best to apply some of the themes found in Adventure Time to common themes of software development. So, here goes...

Don't Make an "Everything Burrito"

In the above photo, take from the episode "Conquest of Cuteness," we see Jake burying "everything burrito" (a burrito containing, well, everything). This made me think. Sometimes, when we write code, we want to make a huge system to solve a small problem, we want to use a crane to crush a fly.

Whether it's intentional or accidental, we have the best intentions. We know our abilities -- we can create truly amazing things. However, we need to keep the YAGNI principle in mind. Many times, our extra functionality becomes, simply, superfluous. We end up building software that will never be used and we have to bury it, similarly to Jake burying everything burrito.

You Have to Fail Before You Can Succeed

The above meme-d line, "Sucking at something is the first step to becoming sorta good at something" rings absolutely true for software engineering (as well as many other disciplines, I am sure). In many ways, software engineering is all about learning! In order to stay up-to-date, we must learn new tools, technologies, languages, and we must do so continuously!

Sometimes learning new things can be daunting. We must realize, as Jake points out, that sucking is the first step to becoming awesome! We will all fail at first, but as we struggle and work, we will persevere and we will grown in knowledge and wisdom.

Homies Help Homies

As the above, tee-shirt quote says, "Homies help homies" (taken from the episode titled "Her Parents"). The idea of collaboration, of sharing wisdom and experience, is paramount for software development. As a newer developer, I can say that, through the wisdom of more senior developers, I have advanced at a rate beyond my ability to advance privately.

Lone-wolfing can be stunting. Through pair-programming, collaboration, mentoring and simply asking questions we benefit from the experiences of those who have seen more.

Programming Languages Are Like Jake's Favorite Cup

This is a pretty simple point: languages come and go. As developers, as stakeholders in an advancing industry, we need to be able to realize when a technology has expired. More importantly, we need to be able to move on and learn new technologies. There's nothing wrong with having a "favorite language" but, like Jake's cup, we need to be willing to drop it and learn something new, especially if our situation demands it.

Be Incremental

In the episode "Susan Strong," Finn and Jake meet Susan, one of many human-like beings that live underground. Upon bringing Susan to the world above, Finn recognizes that Susan is having trouble adjusting to her new environment. Finn decides to incrementally introduce the above-ground realm to Susan (this is when the above, modified Adventure Time logo is flashed).

This example of incremental exposure reminds me of two concepts that are important to developers, today. Firstly, when we learn new technologies, we should do so incrementally, so that we don't get overwhelmed. Secondly, when we develop software, it's helpful to do so incrementally. Incremental development is useful because it forces us to tackle small, bite-sized problems, resulting in bite-sized solutions that are more easily understood than complex, large solutions.