Stories about Software


Factory Method

Quick Information/Overview

Pattern Type Creational
Applicable Language/Framework Agnostic OOP
Pattern Source Gang of Four
Difficulty Moderate — slightly easier than Abstract Factory

Image courtesy of dofactory

Up Front Definitions

  1. Creator: This is the basic, abstract factory interface.
  2. Concrete Creator: Inheritor factory classes that implement some actual object creation scheme.
  3. Product: This is the base/abstract polymorphic object that gets created by the factories.

The Problem

Let’s say that you’re coding up some kind of game and in this game a character navigates a world and encounters various entities with which to interact, including enemies. You’re starting out with a very bare bones proof of concept, and here is your sketch of some enemies:

The concrete enemies return a string representation of their attack, which you will, no-doubt, later transform into some kind of first class attack object or even graphic as the game moves along, but for now, you just want to get the concept right. To get things going, you create the following class:

You want to keep things clean, so you abstract an interaction method, knowing that at some point this will probably mean something different than dumping to Console. From there, you’re now left to figure out the enemy situation based on where the character goes and you’re off to a good start since gators tend to hang out in swamps. Let’s add in a few more scenarios:

Now you’re off and running. You decide that HouseFly is a good enemy to use in this case, since it seems like a good stock enemy ala the “Goombas” in Super Mario Brothers or Foot Soldiers in the Teenage Mutant Ninja Turtles (I’m probably dating myself a bit here). But wait a minute — house flies could happen anywhere. Let’s say that they’re the else condition, but they also have a 50/50 chance of appearing in the other places. Hmmm… let’s introduce an abstraction to hide the ugly and annoying details of randomization and do this:

Ew, that’s starting to smell a bit, but no time to worry about that now. Your efforts here have led to some angel investment capital and now the pressure is on. You use that money to hire a UX/gameplay expert so that he can worry about the gaming decisions while you focus on architecture. He tells you that you need to introduce the concept of difficulty and that Chuck Norris can be anywhere except Middle Earth but only if the difficulty level is set to 5 or more. But Chuck Norris is a family man himself, so he’ll only attack you at a family reunion on a really high difficulty level like 10. Otherwise, he’ll wait until you leave. Hmmm….

You look at this and realize that you’re definitely whipping up some spaghetti code here, but no time for that now. Your game designer tells you that you need a new mode of the game where instead of interacting with the enemies you talk with them first. The logic for encountering the enemies is exactly the same and you still need your old code, but you need it in a new module. Oh, and you should probably add a few new enemies that you find in a few new places. And house flies should probably stop appearing after difficulty level 7. Oh, and dragons can appear in Starbucks sometimes after a successful battle with MotherInLaw. Oh, and gators can appear at your family reunion if you have it in Florida.

Here’s the code for that… just kidding. You’re probably not going to read subsequent posts if I destroy your eyesight with the code I’m describing.

So, What to Do?

As has become customary in this section, let’s examine what went wrong. Most of the time it’s the point at which copying and pasting start, but not in this case. Another good tell in this series of posts where things go off the rail is when I start trotting out excuses for what ‘you’ are doing in the second person narrative. As soon as things are a little ugly because ‘you’ have a deadline or ‘your’ project manager is riding you, that’s usually when things went wrong. Here is no exception. Let’s rewind to the second code snippet, representative of a simpler time:

This is alright, though I would argue that we can make a nice improvement here. Notice that we’re following a pretty consistent pattern here: we check place name and then we invoke the same method on a polymorphic object that varies with place name. It might seem like a trivial bit of redundancy, but these add up as you leave them in and, I would argue, poison the well when it comes to future design decisions. Broken Window Theory and all that. So let’s change the code to this:

Notice that there’s now only one call to “InteractWithEnemy” and we’ve split the functionality of mapping place name to en enemy instance from the functionality of interacting with the enemy in a nod to the SRP. You also might notice that we have implemented what has come to be a common variant of the original Factory Method pattern, which is the static factory method. A static factory method is a stateless method that takes in some criteria and spits back a matching polymorphic instance of the common base return type. For instance, this method says “if the place is middle earth, we need a dragon enemy.”

With this refactoring accomplished, let’s take on the next requirement, which is that house flies can occur anywhere with a 50% probability. Before our heads start rushing with design patterns and complex implementations, let’s consider what might be the easiest way to get this working. Didja think of this:

Notice how easy that is with a little bit of logic separation. But, if that implementation strategy were going to hold up, there’d be no meat to this post, so let’s press on. Chuck Norris can be anywhere except for Middle Earth and a family reunion if the difficulty level is at least 5 and anywhere except Middle Earth if the difficulty level is at least 10. At this point it’s important to recognize what’s happening here and it’s easier to do so now with this factored road down which we’ve started. What’s happening is that what was originally a simple mapping from place name to enemy inheritor is becoming muddied by a growing number of additional factors. And what’s a good way to handle additional complexity in an object oriented programming language? Well, encapsulate it in an object.

The idea of centering the enemy generation around places is appealing since that’s how we originally conceived of it, so let’s stick with that. The family reunion one seems to be the most complicated, so let’s take a look at that:

(I added a “choose at random” method to the interface of signature T ChooseAtRandom<T>(params T[] thingsToChoose) to keep the emphasis on the factory class as much as possible rather than distracting with worries about random implementation. I acknowledge that this would have made the problem code a little less noisy, but it still would have been headed down a bad street with creeping complexity)

Cool! Now the GameNarrative class doesn’t need to worry about the creeping complexity around what goes into the decision of which enemy to generate beside the place name. We have a class with the single responsibility of figuring out how enemies get generated for the family reunion location. But how does this fit with the original class? Well, let’s take a look at an interim solution. Here is an updated, no-longer-static factory method:

Notice that instead of directly instantiating an enemy when we’re at the family reunion, we delegate that task to our newly created factory. Let’s make a factory for each place now so that we can remove that awkward GetEnemy call and keep this method clean. In order to do this and return a factory instead of an enemey, we’re also going to need to make these factories polymorphic cousins of one another, by defining an interface (could also be an abstract base, which is less decoupled but allows implementation of a common constructor).

And, with that in place and all of the other factories defined (elided), here is the new narrative class:

That’s looking pretty darn legible now. But it’s not just that the code is easy to read or even that it’s separated into factored methods and classes. The important thing here is conformance to SRP and the fact that it’s easy to find what needs to change and change it independently of other concerns. Think back to the change request that broke our spirit earlier. Adding new enemies? Piece of cake — just add classes for them and then add them to the random generation in the factories that are eligible to generate them. Porting enemy generation? Just make the GetEnemyGeneration method (or some variant of it) publicly accessible and call it elsewhere. All of the new enemy generation business rules? Put them in their appropriate factories. Cross cutting rules? Create a base factory class. These tasks are now quite manageable.

A More Official Explanation

The stated purpose of the Factory Method design pattern (from dofactory) is:

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

This creational pattern is also sometimes referred to as “virtual constructor” because of the way it separates the promise of object creation from the implementation via polymorphism. Be it an interface or abstract base class, the abstract definition defines a contract for the generation of polymorphic entities and then delegates that work to implementers/inheritors.

This has the powerful benefit of allowing flexibility and following of the open/closed principle not just for creation of objects but for strategies for object creation. In our example above, the IEnemyFactory is the Creator, the various factories are the Concrete Creators and the enemies are Products. We have the ability with this implementation to seamlessly add new enemies but also to seamlessly add new schemes for generating enemies. If we wanted to add a location called “mountains” with its own unique set of denizens to the game, this would be straightforward and have nearly 0 bearing on existing code.

It is worth noting the conceptual similarity to Abstract Factory at this point and pointing out that the jump from Factory Method to Abstract Factory is just the addition of more polymorph families. For instance, if each location had enemies, terrain, and allies, Abstract Factory would be a good fit. That said, the transition from Factory Method to Abstract Factory is extremely violent to the code base since the addition of methods to the factory require changes to all implementers. Thus it is probably good to spend some effort up front reasoning about what the factory should do, particularly if the concrete factories are spread far and wide (unless you are using an abstract base class and then there is some reprieve here as you can specify default behavior).

Other Quick Examples

  1. An enterprise application capable of pulling information from multiple persistence models (factory methods to create DAOs).
  2. A GUI intensive application that generates controls/forms/pages on the fly depending on user interaction.

A Good Fit – When to Use

This is an interesting one circa 2012 because it seems like a decent amount of the heavy lifting that I used to see this pattern do has been replaced by IoC containers or plugin architectures. In other words, the Gang of Four made it fashionable to move complex instance creation into its own place in your code, and the Unit Test/TDD crowd later made it fashionable to move it out of your code altogether. It’s also been squeezed on the other side, so to speak, by the prevalence of the “poor man’s factory method” — a simple static method that returns polymorphs representing a common interface or base class.

But in reality, this pattern has its own niche not covered by either of these situations. IoC containers and, to some extent, plugin architectures are really about decisions made at application start time. The point of abstracting them out of the codebase is to allow application behavior to be changed without rebuilding and re-deploying. Factory Method as I would advocate covers a subtly different usage scenario wherein the polymorphic type is not known at application startup. An obvious example (and the one we covered in this post) is where the user supplies input that governs which object should be created in some way.

But this could still mean using the static method rather than the class hierarchy of Factory Method. I would recommend the latter specifically in situations where the logic surrounding instance creation is more complex than switching over a simple argument or two and/or likely to grow and change with time (the aforementioned Open/Closed Principle). If you find that you have a static factory method that’s ballooning in size and cyclomatic complexity it’s probably time to consider a factory method hierarchy.

Square Peg, Round Hole – When Not to Use

The inverse of various situations described in the previous section is a good place to start. You probably don’t want to use this pattern for very simple scenarios (say, switching over an enum or character to create instances) and you probably don’t want to use it for decision that can be made prior to runtime as that introduces more complexity and indirection to your application than necessary. Another place that you’d avoid this is when you need an abstract factory because you’re creating object families.

As always, YAGNI applies, and factories are sort of iconic in representing over-engineering in OOP. I once heard a cynical but funny quote (don’t recall who originally said it, but if you know, please comment): “some people think they’ll use java to solve their problems — now they have a problem factory.” This is obviously tongue in cheek, but the implied point about pattern happy enterprise development shines through. It’s easy to get pretty elaborate when abstracting instance creation out of plumbing and service code (and I love the practice) but there’s a fine line between this and creating too many levels of indirection. Be careful that you actually need these factories and aren’t just speculatively abstracting. As a rule of thumb, I’d say that you should be able to look at them and think “man, it’s a good thing I pulled that into a class.”

So What? Why is this Better?

As show in the example, when judiciously used, the Factory Method pattern can transform what would have been a snarl of instantiation spaghetti into a well separated, maintainable set of classes. The “after” in this picture shows code that conforms to established OOP principles such as the Open/Closed Principle and the Single Responsibility Principle (you can throw Liskov in there too since there’s a lot of polymorphism here).

Once this is in place, adding new target/product objects for creation is a segregated and approachable problem and adding new creation schemes becomes quite easy. It’s also straightforward to separate creation from use in your code as well, leading to a lot of architectural flexibility. And, properly applied, it’s a good mechanism for avoiding the bane of programming existence — copy and paste coding.


Practical Math for Programmers: DeMorgan’s and Other Logical Equivalences

The “Why This Should Matter to You” Story

TL;DR: You read my post about conditional bloopers and thought, “what’s wrong with that?!?”

Let’s say that you recall the lesson from last time and you make sure that you also avoid statements like “if(A && (A || B))”. You draw out truth tables whenever you feel you have time (and when no one is looking because, if you’re honest with yourself, you feel a little awkward doing it when people are watching). And yet things like this still happen to code you’ve written:

gets refactored to:

When you notice this in the source history, you check with your truth tables, and sure enough, it’s right. You kind of get it, in the end, but you always feel like you’re a step behind.

Math Background

In Boolean algebra, truth tables are sort of the equivalent of rote arithmetic memorization such as learning multiplication tables and using them to perform long-hand multiplication of larger numbers. It’s a rote, brainless, and time-consuming algorithm that you follow when there isn’t something better to use to get you to the answer more quickly. But the good news is that if you memorize a different set of information — some axiomatic laws of equivalence — you can get a lot of answers more quickly and easily. Here is the series of equivalences paired with explanations that will really help you understand the finer points of simplifying your conditional logic.

Identity Laws:  (A ^ TRUE) = A and also (A v FALSE) = A.  These identity laws simply point out the identity of variables compared with special constants.  This is like talking about additive identity (x + 0 = x) or multiplicative identity (x*1 = x) in elementary algebra (i.e. what you learn in junior high).

Domination Laws:  (A ^ FALSE) = FALSE and also (A v TRUE) = TRUE.  These are the opposites of the identity laws and have elementary algebra annihilator equivalent (x*0=0) or (x/x = 1).  These operate simply in that any false in a conjunction or any true in a disjunction renders the entire expression false or true, respectively.

Double Negative:  ~~A = A.  (Probably more formally known as “double negation” or negation of negation, but I think this easier to remember).  This quite simply says that if something is not not there, then it is there or, in Boolean logic, two falses make a true.

Commutativity:  (A v B) = (B v A) and (A ^ B) = (B ^ A).  This simple but important law    shows that the order of arguments to the conjunction and disjunction operators do not matter.  Think back to your arithmetic days when you learned that 4+3 = 3+4.  Same principle.

Associativity:  (A v B) v C = A v (B v C) and (A ^ B) ^ C = A ^ (B ^ C).  You can think of this as demonstrating that the location of parantheses is irrelevant when all operations are conjunction or disjunction operations.  If you reach ever further back in your brain from arithmetic, you may remember this guy as 3 + (4 + 5) = (3 + 4) + 5.

Tautology:  (A v ~A) = True and (A ^ ~A) = False.  We went over this in more detail last time, but suffice it to say that conjunction and disjunction with a variable’s negation leads to vacuously true or false results.

Idempotence:  (A v A) = A and also (A ^ A) = A.  Idempotence in general is the idea that an operation can be applied multiple times but only have a single effect.  For a rather practical example, consider turning a light switch on; the first time you push up a light turns on, but subsequent pushes up don’t turn the light somehow “more on”.  Idempotence in Boolean expressions means that redundant conjunctions and disjunctions simply have no effect.

Distribution:  A ^ (B v C) = (A ^ B) v (A ^ C) and A v (B ^ C) = (A v B) ^ (A v C).  This is a powerful equivalence because it provides a means to “move” parentheses around in Boolean expressions and retain their exact truth values.  Consider this in English and there is sense to it: “If A is true and also either B or C is true then A or C is true and A or B is true.”  Should that be a little abstract for your taste, think of it conversationally “It’s raining and either I’m inside or I’m wet” is the same as “It’s raining and I’m wet or it’s raining and I’m inside.”

De Morgan’s Laws:  ~(A ^ B) = (~A v ~B) and ~(A v B) = (~A ^ ~B).  This is another heavy hitter like distribution except that this one allows us to “move” negations when simplifying Boolean expressions.  This one also makes sense conversationally: “If it’s not true that person X is male and person x is female, then either person X is not male or person X is not female.”  De Morgan’s Laws also have an interesting incarnation in higher order logics like first order logic, but that’s probably going to be beyond the scope of this series for quite some time.

Absorption: A v (A ^ B) = A and A ^ (A v B) = A.  This was the main example we covered last time, so you can work out the truth table if you like.  As it turns out, this is a formally defined equivalence as well.

How It Helps You

In the last post in this series, I covered truth tables, which are sort of like the Boolean algebra equivalent of long division.  They’re a mechanical, inelegant process by which you can brute force a correct answer.  Logical equivalences are algebraic axioms that provide you with the building blocks for deductive reasoning — the building blocks for really thinking things through and critically solving problems.

You don’t necessarily need to memorize these, but I would study them enough at least to have something tickle the back of your mind the next time that you’re staring at an incredibly complex looking conditional.  That something will be “I think we can do better than this” and then, even if you don’t have the equivalences memorized, at least you’ll know enough to go look them up.  Armed only with truth tables, this can feel like flailing around in the dark while looking for a pattern.  But armed with logical equivalences you’ll say “oh, that’s right — I can eliminate the not here and I can turn these ors into ands over here, and… yeah, much better.”

Memorizing these equivalence laws would be even better, but not for the sake of pedantry or winning obscure trivia games.  I say that memorizing them is better because if you memorize them, you will practice them and conditionals, particularly complex ones, will start to work themselves into simpler forms automatically in your mind.  You will see things like Neo in the Matrix when he’s about to defeat Agent Smith, if the movie were a lot more boring.  Point is, though, you’ll develop an extremely good sense for when conditional logic could be simplified, corrected, or clarified and that has powerful ramifications for the readability, correctness and maintainability of the code you work with.

To circle back to the small example of a real world situation, understanding these Boolean laws of inference is likely to put you ahead of the curve, rather than behind it, when it comes to understanding conditional simplification.  Rather than the person whose code is always getting refactored, you’ll be the one doing the refactoring and doing it confidently.

Further Reading

  1. Wikipedia
  2. A bit more circuit flavored, but with some applied examples at the bottom.
  3. An introduction to the idea of proofs in Boolean algebra
  4. Very theoretical, with formal proof for most of the inference laws.


One Singleton to Rule Them All

I would like to preface this post by saying that I don’t like the Singleton design pattern at all. There are some who love it, others who view it as a sometimes-useful, often-abused tool in the toolbox, and then there are people like me who believe that it’s extremely rare to see a use of it that isn’t an abuse — so rare that I consider it better to avoid the pattern altogether. I won’t go into much more detail on my thoughts on the Singleton (stay tuned for that when I get to this pattern in my design patterns series), but here is some further reading that expounds a lot on reasons not to like this pattern:

  1. Scott Densmore: Why Singletons are Evil
  2. Misko Hevery: Singletons are Pathological Liars
  3. Alex Miller: Patterns I Hate
  4. Steve Yegge: Singleton Considered Stupid

With all of those arguments against Singleton in mind, and considering the damage that abuse (and I would argue use) of the pattern causes in code bases, I found myself thinking of code bases I’ve heard of or encountered where the code was littered with Singletons. In these code bases, refactoring becomes daunting for a variety of reasons: the hidden dependencies, the complex temporal dependencies, the sheer volume of references to the Singleton instances, the almost obligatory Law of Demeter violations, etc. Singletons cause/encourage a rich variety of problems in code bases. But I think that something could be done about two such problems: the redundant Singleton implementation logic and the Single Responsibility Principle (SRP) violation of which Singleton classes are prima facie guilty.

Take a look at how the Singleton is implemented (as recommended by Microsoft, here). The basic implementation initializes the static instance in the property accessor while variants use field initializing syntax and introduce thread safety.

The basic implementation is here:

More specific even to C# is James Michael Hare’s implementation using the Lazy<T> class to eliminate the redundant if-instance-null-instantiate logic needed in each Singleton class. But that still leaves the redundant Instance property, the redundant _instance field, and the awkwardness (SRP violation) of an object managing its own cardinality. What if we got rid of both of those issues?

Using generics, this implementation allows an instance of every Singleton to be expressed in the code of a single class. In this fashion, any type can be implemented as a Singleton without the type being coupled to an internal Singleton implementation. It also standardizes the Singleton implementation by making sure it exists only once in the code base. With this pattern, there is a similar feel to IoC containers — classes can be implemented without concern for who will instantiate them and how.

Here is my take on the disadvantages and potential disadvantages of this approach:

  1. You still have Singletons in your code base.
  2. This might actually encourage more Singleton usage (though fewer actual Singleton implementations) by removing responsibility for implementation.
  3. Since constructor of object in question must have public default constructor, removes the Singleton gimmick of making the constructor private and thus the safeguard against additional instances being created is also removed.
  4. A natural extension of the previous item is that it remains a matter of documentation or convention to use Singleton<T> and not instantiate rather than it being impossible to instantiate.

But the advantages that I see:

  1. Only one class implements cardinality management, meaning refactoring away from Singleton is nominally easier.
  2. No Singleton SRP violations
  3. Singleton implementation (initialization, lazy load, thread-safety) is standardized to prevent inconsistent approach.
  4. I actually consider preventing the private constructor gimmick to be a plus — particularly where potential refactoring may be needed (and it pretty much always is when Singletons exist).
  5. With this pattern in your code base developers are less likely to be come comfortable/familiar with implementing the Singleton pattern.
  6. No need to introduce interfaces for Singletons to inject instance into classes using dependency injection — just inject a non-Singleton managed instance.
  7. A code base with nothing but normal instances is very easy to reason about and test, so the closer you get to that, the better.

I would like to reiterate that I’m not suggesting that you run out and start doing this everywhere. It mitigates some of the natural problems with the Singleton design pattern but “mitigates some” is a long way from “fixes all”. But, if you have a code base littered with Singletons this could potentially be a nice intermediate refactoring step to at least standardize the singleton implementation and provide slightly more friendly seams to testing legacy code. Or if you’re faced with and outvoted by a group of other developers that love their global variables (er, excuse me, Singletons), this might be a decent compromise to limit the damage they cause to the code’s maintainability. On balance, I’d say that this is an interesting tool to add to your arsenal, but with the caveat that something is probably wrong if you find that you have a use for it.

I’d be curious to hear others’ takes on this as well. I just kind of dreamed this up off the top of my head without taking a lot of time to explore all potential ramifications of it use. If you’ve implemented something like this before or if you have opinions on the advantages/disadvantages that are different than mine or if you see ways it could be improved, I’d be interested to hear about it in the comments.


Happy Thanksgiving!

Here’s wishing all DaedTech readers who celebrate Thanksgiving today a safe and happy holiday. I will most likely not make anymore posts this week as I celebrate the holiday over this long weekend. Posts will resume as per normal next Monday.



A Tale of Two Web Stacks: Java vs .NET

For the last few years, I’ve focused largely on desktop development doing WPF and C#. I’ve dabbled a little here and there in web development, but the lion’s share of my web development up until the last few months occurred several years ago or earlier. Recently, I’ve been doing nothing but web development, in the form of webforms primarily, but also with Java and my home automation projects here at home. One weekend several weeks ago (it was “last weekend” when I started this post) I decided to upgrade my main machine at home from XP to Windows 7, and this required me to wipe everything and start fresh. Part of this meant that I’d have to port my IntelliJ/Spring/Maven/Java setup to a new machine.

I had ported my project from Eclipse to IntelliJ (which went very smoothly — compliments to IntelliJ), so it had been a long time since I’d actually set up a web development project in Java. Interestingly, it had also been a long time since I’d done the same in the ASP world since the work I’ve been doing the last several months had already been setup from a project structure perspective. However, given my situation with the home automation project and the fact that I’m starting on FeedPaper, I’m in a unique position to document my comparative experiences with both, being in the position of generally experienced developer and relatively familiar with the technologies, but not practiced at setting up these specific types of projects. I’ve done this documentation below.

Before you read on, please note that I’m not in the tank for anyone or a fanboy of any technology, company or platform. I’ve spent years developing in both Java and .NET and there are things that I like about both. I’m a happy, equal opportunist polyglot and hope to stay that way. But for me to do so (with Java and .NET at least) would require both technologies to succeed, and I see trouble on the horizon for Java. I don’t like this because I like Java. It was a nice alternative for web development when Microsoft wanted to charge me $500 for Visual Studio and who knows what for whatever else I would have needed to write web applications. I like it because it was real, big boy server side code, capable of expansion to enterprise sites and not sloppy (I’m looking at you PHP). I like it because of the vibrant and inventive community of developers committed to improving it. But, I still think dragons be coming and Java might have a fight on its hands not to become COBOL.

Setting up For Java Web Development in 158 Easy Steps

Here’s why I say there’s trouble. I wanted to set up a minimally functional site with both Java and .NET web technologies — “hello world” in concept. My steps to set up Hello World with Java are detailed here (if you get tired of reading, feel free to skip to the bottom of the list as it is incredibly long):

  1. I download and install IntelliJ Community Edition.
  2. I download and install JDK 7 and create a “JAVA_HOME” environment variable.
  3. I download Tomcat and unzip it in C:\program files\Tomcat.
  4. I set “CATALINA_HOME” environment variable and point it here.
  5. I go to Tomcat’s “webapps” directory and set its permissions to allow anyone to modify since that’s where I’ll be deploying my projects and I don’t want UAC messages each time I do.
  6. I run Tomcat’s “startup.bat” and fire up localhost:8080 to manage tomcat. Fail. HTTP Status 500 – java.lang.ClassNotFoundException: org.apache.jsp.index_jsp.
  7. I refresh and get a different error: HTTP Status 404 – /.
  8. I try going to the manager URL directly. Error: HTTP Status 500 – java.lang.IllegalStateException: No output folder
  9. I google, but don’t really know what to google, and don’t have much luck.
  10. I try running random bat files in the Tomcat directory with names like “setclasspath.bat”. No joy.
  11. I put quotes around my environment variables since Windows directory names and their spaces are kinda screwy.
  12. Oops, now startup.bat in the Tomcat folder does nothing. So much for that. I put the environment variables back.
  13. I open the file “RUNNING.txt” in Tomcat root directory and see if it has anything helpful to say. It does, but it only covers the stuff I already know (all this environment variable crap and that I should start the web server with startup.sh)
  14. I google again and find nothing useful.
  15. I start looking through the Tomcat output to the Console and see a bunch of exceptions about a log file not existing because access is denied. This doesn’t seem like it ought to be critical, but you never know.
  16. In a scorched Earth approach, I make the entire Tomcat directory writeable by any user and restart Tomcat where I see no more log errors.
  17. Joy! Half an hour in, I have the web server running.
  18. Time to make sure I can see what apps there are — I remember I can do that from the manager.
  19. Tomcat 7 helpfully tells me that I need to configure security for the web server (previous versions didn’t) so I do that by editing tomcat-users.xml.
  20. I uncomment the examples in the file to use and that doesn’t work, I get a 401. But, the 401 is pretty helpful (another improvement) and I follow the directions in it, which unfortunately don’t work.
  21. I try restarting the web server.
  22. Joy! That was my stupid mistake — assuming that the roles were processed at login time rather than startup. 45 minutes in I can manage the web server.
  23. Going back to IntelliJ, I try to create the project I need, but can’t because I don’t have a web template available.
  24. I google and discover I should use Maven.
  25. I read and try to understand what Maven was and where it came from. Don’t really understand (kinda like NuGet I think), but apparently IntelliJ has it so I don’t need to install it or anything.
  26. I try to create a Maven project, which goes fine except for the “Finish” screen, which tells me that the Maven Home Directory is not specified.
  27. I specify it as the directory with the user settings file, but apparently that isn’t right because the Maven Home Directory is “invalid” (no mention of why or where I might find one that isn’t).
  28. I google this error message, wondering why I have to bother with this and why it doesn’t just work. Epic fail. I’m apparently the only one that’s ever had this problem.
  29. I do a search on my hard drive for “maven” and find that there are a few hits in the folder C:\users\erik\.IdeaIC11, so I figure, what they hey, I’ll give that a try. Nope.
  30. I look at the “user settings file” and “local repositories” specified by default and notice they don’t exist, so I create them, figuring that this might make the directory a valid maven directory. It doesn’t.
  31. I google and find this stack overflow post that leads me to an example settings.xml file and I try adding the xml I find there into mine, hoping this might at least result in a new error message. It doesn’t.
  32. I go downstairs and get some soda and take a break.
  33. I come back, wondering whether I have to install maven separately.
  34. Apparently not, according to Jetbrains as it “ships with” IntelliJ. I testily wonder “if it ships with IntelliJ, why the %&$# is it asking me where the Maven directory is?!?”
  35. Back to google. I find this post telling me that “opening maven project is as easy as pie”. I chuckle.
  36. Back to google. Nothing helpful after another 5 or 10 minutes. At this point, I’m 1:15 into this effort.
  37. I decide that I’ll install Maven anyway, whether or not it “ships with” IntelliJ. What can it hurt at this point?
  38. I go to the maven download page and am a bit concerned that IntelliJ says that it integrates with Maven 2 and that a third of the roughly 17,400 options I have for downloading Maven are for a version 3. And which of the version 2’s on there does IntelliJ integrate with. I abandon this plan.
  39. I google again for a while and discover that most problems with the M2_Home/Maven Home seem to be for Linux and Mac users. Apparently there is some sort of known issue there. I wonder if that’s true on Windows at all.
  40. I go get another soda. I’m about 1:45 minutes in now.
  41. I download Apache Maven v2.2.1, reasoning that even messing things up badly at this point would be better than no change (and it takes less time to format my drive, re-install Windows 7 and get all my drivers going than setting up this hello world web project anyway, so how bad can it be?)
  42. I unzip Maven to C:\program files\maven.
  43. I look in the conf folder and see “settings.xml” so, having learned my lesson from Tomcat, I decide to move the whole operation to C:\users\erik\.m2
  44. I try again and it fails using M2_HOME, but when I “override” and type the directory in manually, it works. I guess “defaults to M2_HOME” is a bit of a fib, but that doesn’t matter at this point, since I’ve won.
  45. Joy! About 1:50 in, I have a web server installed and I’ve created my project!
  46. My joy is short-lived as I see that there is no Web-Inf or welcome JSP page or index or anything to indicate that this is a web app. Sigh.
  47. Whatever, let’s at least get what we have building.
  48. I do a “make project” and get an error: “Cannot find home directory C:\program files\java\jdk1.7.0. Update Project Configuration.” I’m actually pretty pumped about this error message since it offers some kind of actionable feedback. My standards, as you can tell, are now pretty low. I mean, you’d think this could be inferred from my “JAVA_HOME”, but whatever.
  49. I go into settings and look under “Compiler” and see nothing about the JDK to user, so back to google.
  50. I find nothing helpful there, so I start randomly looking at menus and context options.
  51. I right click on my module and see “open module settings”, which looks promising. I go to the “Project” under “Project Settings” and see that there is a SDK specified, but it just says “1.7” and it’s red. I click the dropdown and see there’s also 1.7 (1) and that’s red too. Apparently the default is not 1, but 2 copies of a nonexistent JDK. I delete both of those and manually browse to the actual JDK.
  52. Now, I build and nothing happens, which is an improvement. I’m just told “all files are up to date.”
  53. I’m not going to worry too much about that now because I don’t actually seem to have any files, so it stands to reason that there’s nothing to compile.
  54. I’m not sure what the Maven “web-app” goal or archtype or whatever actually did for me, but I did notice something interesting when clicking around called “Add Framework Support”, so I’ll try that.
  55. Bummer, my only option is “Groovy”. Back to the drawing board.
  56. At this point, 2:15 in, I knock off for the day. I’m doing this on nights and weekends and so clearly hello world web app is going to need to be a longer term project than just one day. I have chores and bills and occasionally a life, I’ll have to resume setting up the simplest, most basic web setup imaginable later when I can really devote a lot of time to it. I’ve managed to install the web server and create a project that doesn’t do anything, compile, or even have any files. Quite a productive day, I guess…
  57. I pick back up the next day and, having slept on it, I remember something about adding things to pom.xml. Perhaps if I add Spring stuff to it, the “Add Framework Support” thing will work.
  58. I google and find this stackoverflow post. It’s not particularly helpful, and I consider “add this bunch of random crap to this XML file” to be an enormous framework fail, but misery loves company, and I can see that most people that do this are also confused and that you can “learn the basics of Maven in a few days” if you read a book. I’m not really clear on why this Maven is better than downloading Jars on my own, which wouldn’t take me a few days, but I’m trying to do things the “right way”.
  59. I google some more and find this from Spring, and it looks promising. I still think it’s utterly preposterous that the way to get dependencies is by hunting down blobs of random XML from the internet to copy and paste into a file, but I seem to be making progress. I copy and paste.
  60. I then right click and click “sync Pom.xml” because I seem to remember doing that before and it seems to make sense for some reason.
  61. I try “Add Framework Support” again, but no joy. Still only groovy.
  62. I delete all that XML and flail around google some more.
  63. I find another post where I see some sample XML from another pom, and I see that all that crap I copy and pasted needs to go inside of a “dependencies” tag.
  64. The syntax highlighting looks more promising now, but I try synchronizing and importing and whatnot, and still no framework support. Now there’s a lot of angry red in the IDE about my pom.xml file and a squiggly under it in the project explorer. But, errors are different, and different is progress.
  65. Back to google, and I’m now 2:45 in.
  66. I find another blog post and learn that the “properties” tag needs to go outside of the “dependencies” one. Of course – I shoulda known (/sarcasm). This guy’s blog is pretty helpful — too bad he doesn’t use IntelliJ.
  67. I make the change and synchronize again, and nothing really happens.
  68. After a minute, the squigglies and angry red goes away and suddenly a bunch of stuff about spring appears under “External Libraries”. It’s like magic (but more like a kid putting on a magic show and needing a few mulligans than David Blaine).
  69. This doesn’t help setting up the directory structure to get hello world up and running.  I still have a blank module under a blank project.
  70. I google and find this on stack overflow.  It doesn’t help me, but it is interesting to note that someone experienced in all three technologies (Spring, Maven, IntelliJ) would likely take longer than 30 minutes to set this up.  Someone not experienced with Maven and IntelliJ… 3:00 and counting.
  71. I try creating a new module for the heck of it, to see if maybe this time the “Maven Web App” actually has some kind of directory structure or code in it.
  72. Nope.
  73. I go to delete this module that I don’t want and spend a few minutes getting annoyed until I discover that I have to delete all of the files in the module, then delete the directory, then do it again for reals (it’s separating delete from project and disk).  That took a pointless 5 minutes.
  74. Back to google.
  75. I find this page, which has exactly what I want.  It’d be awesome if it my IntelliJ actually worked like that.
  76. I see that that post was written 9 months ago, so perhaps setups were simpler back then.  Yep, those were the days.
  77. I try creating a new project anyway because I’m really pretty much out of ideas.  Not surprisingly, that doesn’t work.
  78. Back to google.  Nothing.
  79. I start to wonder if it’s even possible to have IntelliJ create a web project directory structure for you.  I could have sworn it worked before when I did this some weeks back.
  80. I find this on the IntelliJ site, which suggests creating a Java module from scratch instead of a web module.  I try that and it doesn’t work, but I try creating a Maven module again and now have the option of creating a Spring project.  I do that, and it actually gives me a “src” directory.  Sweet!  We’re getting somewhere.
  81. This module inside the project also has a pom.xml.  I copy all of the crap from the main pom to this one and try adding framework support.  Nope.
  82. I am seeing “fatal error, cannot find JRE1.7″ in the “messages maven goal” window.  I clear the message and I can’t get it to come back.  I have no idea what’s causing it.
  83. At this point, I think it isn’t worth spending anymore effort trying to get the IDE to setup a basic project structure.  Clearly I’m asking the impossible of the incapable.
  84. Luckily, I have the source code for a previous Eclipse project that I converted to IntelliJ laying around, so I re-create that directory structure (I eventually want to be using a lot of the source from this project anyway, so I’ve kind of decided that skipping hello world might, ironically, be easier).
  85. I copy the entire WebContent directory and then copied the structure of src, at which point I copied a few controller java files.
  86. The files I copied have a little j with a red circle around them and a line through them.  That don’t look right, so I google and find this.  I have to specify a “source” directory.  Sigh.  Of course I do.
  87. I follow the instructions in the post and my src directory automatically converts into a package structure (which is admittedly pretty cool) and three of my controllers are error free.
  88. The problem was that they were referencing other files that I need to add, so I start adding them, but that’s where things get wacky.
  89. The package structure seems to work much differently than Eclipse and my package names are getting out of sync with the disk structure and each other, so I delete everything and started over.
  90. I try to google an example package structure for IntelliJ IDEA to mimic, with predictably useless results.
  91. For those keeping score, I’m now about 3:50 in.
  92. I find this on IntelliJ and it’s like a blast of fresh something.  It actually clearly explains something in this byzantine process for the first time in a long time, and I came to understand that IntelliJ’s way of handling packages is actually pretty slick — it lets you retain package names like “com.daedtech.daedalus.controller” without the silly requirement of having 4 nested folder on disk.
  93. I add my second most abstract set of classes to the new structure and do a build, which fails as I wanted it to (red before green, refactor).
  94. I add the most abstract types that these depend on those and then rework the package naming as necessary until compiling is successful (oddly, for one of the broken dependencies, alt-enter works and for the other it doesn’t).
  95. I’m calling it another night (I didn’t start working on this until a little after midnight, so it’s pretty late now).  I figure I’ll go to bed celebrating a win.  4:15 and 95 steps into setting up Java web development, I have compiling code.  Hopefully in the next few hours I can build a WAR file and actually shoot hello world to the screen, to say nothing of setting up the IOC.
  96. Picking back up the next day, I copy all of my code files over and start resolving the differences in package naming.
  97. I spend about 20 minutes resolving all of the various compiler errors and naming issues that resulted from copy.
  98. Now I copy over the ant Build that I had been using and try it out.  Fail.
  99. Start googling what on Earth “‘includeantruntime’ was not set” means.  This helped.  Apparently, I need to set some random attribute in the javac tag that I didn’t need to before for some mysterious reason I might have cared enough to investigate in the first few hours of this.
  100. New set of errors when I try to build.  Cool, different is good.
  101. The errors say that the spring framework package does not exist, which is weird considering the module compiles in the IDE.
  102. Looking at the source files, IntelliJ randomly borked my packages in the files, so I put them back to what they were.  I’m pushing the 4:45 mark and battling the IDE.
  103.  Now onto figuring out why the ant build says springframework packages don’t exist but the IDE compiler says they do.  Apparently, this is some sort of ‘feature’ where plugins compile code differently than the IDE or something.  Boo.
  104.  I do some fruitless googling but don’t really know what to search for.  “Why does Ant suck? ” amuses me but provides no answers.
  105. I see a squiggly under one of my java files and realize that I missed one of the borked package renames.  I have no idea why it would compile with an unresolved reference.  Maybe the Ant compiler is the good one and this mystery, non-functional one the IDE uses is the problem.  My apologies to Ant.
  106. This doesn’t fix the problem of the Ant build not recognizing the spring packages.  Back to flailing around google.
  107. After about 10 minutes, I stumble across this stackoverflow post.  This reminds me that usually there’s some goofiness about “classpath” in both Eclipse and IntelliJ, in my experience, so I poke around the project and module settings looking for something like that.
  108. Poking around, I see something in the Ant properties about “Additional Classpaths”.  I find this.  My suspicion is confirmed.  It’s apparently some kind of insurmountable technical challenge to have the IDE and the build plugin use the same library configuration for building and the task falls to the user.  What a mountain of fail.
  109.  Now I find where the libraries are actually located (that .m2 directory from about 70 steps ago) and add those as an “additional classpath”.
  110. Nope.  Same error.  Back to google to celebrate hour number 5 of hello world setup.
  111. I have no luck for a while and then decide to re-read that last link and see that after line 3 it says “if you want to add the contents of a whole directory, you can click the ‘Add All in Directory’ button”.  Silly me, I just would have assumed the classpath would already have meant this or else it would have been the classfile.  I delete my useless “directory with no children” entry and opt instead for the option whose existence makes sense.
  112. I try again and all errors but one disappear.
  113.  That seems like progress until I see that the single error says “Ant build completed with 86 errors and one warning” and provides me with a single stack trace and no information beyond “compile failed”.  Sweet.
  114. I run the IDE compiler to see if that works.  It does, but I don’t know how much that tells me since it seems to ‘work’ even when there are red squigglies.
  115. I spot inspect the files, but it doesn’t seem to have changed any of them this time, so I suppose the IDE compile is really working.
  116. I re-run Ant and the missing springframework exceptions re-appear.  Two steps forward, two steps back.
  117. I add one of the child directories containing an actual JAR, in case Ant/IntelliJ have yet to discover directory recursion, but that doesn’t seem to help.
  118. At this point, I decide to concede defeat for the night because it’s late and I’m tired.  The good news is that I’m probably about half done with my project — I imagine that actually writing all of the code for the application can’t be anywhere near as difficult as setting up the development environment.  Once you’ve configured Java, writing applications in it is probably a walk in the park. I’m reminded of Rational Clear Case in that perhaps it makes sense to have experts that specialize in falling on this setup grenade so that developers are freed up to actually develop code instead of doing what I’m doing. (As an aside, if I were doing this work for a client, it would have made economic sense to pay someone up to $1000 to set all of this up for me.)
  119. I’ve been somewhat busy, so two weeks have actually passed between steps 118 and now, but in terms of raw time I’m at 5 hours, 30 minutes and counting to get Hello World (or anything at all) going.
  120. First step coming back, I googled the error message Ant was reporting and found a stack overflow post asking for help.  No answers.  Gave a sympathy upvote and moved on.
  121. I expand the “compile” node in the output, even though it has no error indication and discover that it’s littered with errors.  I think I’m partially an idiot for not checking that sooner but think that the tool needs to meet me halfway by not collapsing dozens of errors and having their section header look like everything is fine.  Still, now I’m in business.
  122. All of the errors seem to be about packages and stereotypes not existing, so I suspect it’s something to do with Maven (which, for the life of me I can’t figure out why this isn’t worse than nothing).
  123. More googling and I find this post, which tells me that I maybe need to do something with the class path as I was flirting with back in step 111.  I’m not going to follow accepted answer though because it wants a lot of things and there has to be a less stupid way to do this than redundantly adding all of these definitions to the actual Ant file.
  124. I look at the settings and see there’s a bunch of checkboxes next to the Dependencies in Module->Daedalus-> Dependencies and they aren’t checked.  I check them.  It doesn’t make a difference, so I put them back.
  125. I go into the ant build properties and exhaustively add the actual jars, but that doesn’t matter.  Still errors.  I delete everything in there.
  126. I go under the Ant properties execution and tell it to use a different JDK.  Doesn’t matter, same result.
  127. Back to google, but I don’t really find anything after 5 or 10 minutes.
  128. I start poking around settings randomly.  I try adding the Maven repository root directory to my classpath.  Nope.  I celebrate the start of hours 6 of hello world with that unsurprising failure.
  129. I try adding the MongoDB driver explicitly to the classpath.  Doesn’t help.
  130. Deciding I have nothing to lose, I go scorched Earth and choose Build->Generate Ant Build.  After doing that, it adds a few new XML files to the project.  This doesn’t help my existing build run any better, so I remove it as an Ant build from the Ant window.
  131. I add the one that IntelliJ created and theirs only has two errors, which is some sort of rather sad progress, I suppose.  I also take solace in the fact that even IntelliJ doesn’t know how to generate an Ant build and they’re experts.
  132. Time for baby steps.  I run “clean” and that works.  Huzzah!  Init also runs without errors.  I run “build.modules”.  Doh!
  133. I get an error about IntelliJ not being able to find its own ant definition file.  Apparently I’m not alone.  In the world of setting up Java, just finding someone else that has the same error as me is a huge win – an actual proposed solution is like Shangri-La.  In this case, the problem is apparently that ${idea.home} is not defined.  Oh, of course — as the question asker points out after hearing the answer, he should have known to check a checkbox that was unchecked by default, as I should have too!  /sarcasm (As a brief aside, I think that this sort of thing epitomizes an Emperor’s New Clothes paradigm in programming where we’re afraid to point out that there might be benefits in simplification because we don’t want to appear as though we aren’t clever or knowledgeable.)
  134. Not knowing how to make this ‘obvious’ correction, I delete the whole build and regenerate it.  Success!  Woohoo!!!  There were no other defaults I needed to magically know to override.  Happy Day!  Finally, after 6 hours and 20 minutes, I have an application compiling both in the IDE and with the strangely separate build engine!
  135. Now time to put my build.xml targets into this new ant build and see if I can make the magic happen.  There are actually two ant build files, for some reason, and the targets seem to be spread out sort of randomly across them.
  136. I start adding all of my stuff from my old build into the new build and run it, and then I get all of the same errors.  Time to take baby steps again.  First, I go back to the known build that was running.
  137. First I define all of my custom properties, and that seems to work, so I add a path definition from that file, and that seems to work too.
  138. I then add the war target, and run it, and that works.  Woohoo!!!  I’m building a WAR file.  Almost there.
  139. Now, it’s building it in the wrong directory for some reason.  I hard code the directory name and give that a try.  That works.  I’ll figure out why my variable scheme didn’t port over later.  I want to keep going while I’m on a roll.
  140. I copy over the “start tomcat” and “run chrome” targets to see if I can run my web app.  Doh!  Doesn’t like the directory variables here either.  So, more hardcoding.
  141. That works and tomcat starts, but it can’t find chrome… forgot to hardcode that as well, so I do and then everything runs, and I get a 404!!  (I’m not being sarcastic — I’m delighted that everything at least compiles and deploys).
  142. When I look at the tomcat webapps directory, I see that the war is being generated and it’s being unpacked, but that it has actual Java files and no classpath/lib.  So, there’s something wrong with the actual packing of the WAR.  As I investigate, I see that the lib directory is empty and that so are some other key directories.  I realize that this is because the old Eclipse structure for ouptut was different than what I have now, so I reconfigure the war target, setting the classes directory appropriately.
  143. That works, and when I re-run, I see my default JSP page in the browser, which is definitely a win.  None of the controller links work, but I’m getting tantalizingly close.
  144. I see that the main problem I have now is my lib directory not being populated with my JAR dependencies.    I googled around for a while and found this page and decided to add an “artifact” with my dependencies for deployment rather than manully dropping a bunch of jars into my “lib” folder for deployment, which seems redundant and brittle.
  145. After doing this, the settings window pops back open once for each dependency I had, which seemed screwy.  I’m not optimistic about this working and I’m prescient because it doesn’t.
  146. After playing around in the settings some more, I see that I can move my libraries, so I figure I’ll move them to the lib folder.  I try that and the window starts showing me errors, so I cancel.  Unfortunately, the cancel seems only to have sort of canceled.  I now have an error left that I have to troubleshoot.  Back to google.
  147. I google around and can’t find anything, so I try  just deleting the offending library.  That seems to work and everything still builds.  Ah, the mysteries of life…
  148. After wasting another 15 minutes or so, I’m getting less picky about redundancy.  I decide to copy the jars manually to Web-Inf/lib, but apparently the IDE can only handle this one at a time, so I have to laboriously do it for each one with a right click rather than doing them all together.  /Sigh
  149. Upon further review, I don’t think that did what I thought it would.  It just created a blank module name in that same screen.  Nothing should ever be this convoluted and counter-intuitive.  I want to copy a file.  Only the java world could make this a task that requires a PhD.  Back to google.
  150. After a while, I just decide to give up and manually copy all of the dependencies in that stupid directory.  I was dissuaded all along from doing this because (1) it’s astronomically stupid that you should have to, (2) it’s redundant information, (3) it’s a huge PITA since all of the jars are in their own folders several levels deep and (4) did I mention how incredibly stupid it is that you should have to do it when the IDE already knows about both folders?
  151. I do find and try following the process here but the options in IntelliJ are different now, so this handy-dandy 10 step process for copying files is no longer accurate.  No doubt they’ve improved it to take 23 steps.
  152. Halfway through doing the manual copy, I just can’t bring myself to continue doing something this stupid, so I stop, celebrating the 7th hour of Java hello world with a soda break.
  153. Coming back and doing a lot of googling, I find  this site.  This is a three step process for copying the Jars where step 2 is “Copy the Jars”.  Of course!  /Facepalm.  But I do pick up the interesting tidbit here that this is not the proper, Maven way to do things.  That is, perhaps I shouldn’t have a Web-Inf/lib folder after all.  I tried following the link from that site to the Maven FAQ, but it might as well have been Greek for all the sense it made to me.  I am not “confident” with Maven, so apparently I can ‘conveniently’ use the command line to do God-knows-what.  If that massive parameter-list command line is the convenient option, I think the inconvenient option will probably break my spirit.
  154. I do some more googling for things like “IntelliJ Maven Web-Inf Lib” and lots of IntelliJ bug reports came up.  From using it, I like IntelliJ and the Jetbrains people are sharp.  The only possible conclusion I can formulate the further I get into this is that Maven is a complete train wreck of an implementation however good it might be in theory.
  155. More googling and I find this site.  It doesn’t help me in any way, but the post’s title, “Set up a maven web project in Intellij with Spring and JPA – Part Six” seems somehow perfect to me.  Notice the “part six”.  How many blog posts are required for hello world?  Perhaps his 155 and counting steps are simply distributed into 6 posts of a more manageable 25 step each.  Anyway, a bit of levity for the 7:30 mark.
  156. I found this wiki, which seems to indicate that this would all be much less comically difficult in the Ultimate edition.  Somehow, I’m not intersted in giving money to anyone that has anything to do with this.
  157. After another 20 minutes of fruitless googling, I bite the bullet and do the manual copy.  It only actually takes about 5 minutes, but I just can’t wrap my head around the fact that the IDE knows exactly where these JAR files are on the disk and exactly where my lib folder is, and yet the only way to get those files into that folder is for me to open up two explorer windows and copy/paste all the jars.  The mind boggles.
  158. It works!!!  Hello World (or really, just anything) up and running in just 8 hours with 158 easy steps!!!  It’s like

Setting up for Microsoft Web Development in Many, Many Fewer and Actually Easy Steps

Here are  the steps I followed for Microsoft’s ASP MVC:

  1. Downloaded and installed Visual Studio.
  2. Went to File->New Project and chose ASP MVC project (“Internet Application” template).
  3. Hit F5.

Yep. That’s it.

Threats To Validity

Is this a fair assessment? I’d like to address a few points that I can imagine people raising. First, while it’s true that I’ve been doing a lot of .NET development over the last few years and not much Java development, the overwhelming majority of that work has been desktop development in WPF and a bit of Webforms, so that gives me no experience setting up an ASP MVC project, which means I actually have more experience setting up Java web projects than ASP MVC projects (though a lot has no doubt changed in the last few years).

Another consideration is that I’m using the Community version of IntelliJ instead of the paid version of IntelliJ or using Eclipse. These are valid points, though with Eclipse, it’s been my experience that things are no less of a headache to configure. I also feel as though this is not a significant mitigating factor because of the sheer number of tutorials I encountered for both Eclipse and IntelliJ that had half a dozen or more different posts in sequence for “getting started with web development” or some such thing. As for the paid version of IntelliJ or anything else, there would be a high degree of irony to needing to pay for something in the Java world that you get for free from Microsoft.

Finally, and perhaps most up for debate is whether or not I’m just an idiot (or at least too much of a “noob” to figure things out). Perhaps I just don’t have the programmer chops to do something that an expert could have done quickly. I fully acknowledge that this could be argued (and I’d love anyone to give me time saving tips for next time), but I’d say it misses the point that I’m trying to make here. And that point is that an extremely complicated setup discourages adoption and use. I’m an experienced, polyglot developer that has previous web development experience (even if I am also an idiot), including J2EE experience, and it takes me 8 hours over several weekends to get this going. Imagine how it might go for someone new to web development or just development in general. They’ll try to set things up, get frustrated, look for web tutorials and see things like “Getting started with Java/Spring/etc part 22″. Their next step will be to download Visual Studio and start an ASP project or to download Apache start writing PHP.


Part of the beauty of Java and its stack of FOSS technologies is that it’s an alternative to Microsoft’s “golden coffin”. You have tooling options for everything you might want to do. Choose your web server, your IDE, your IoC container, your web framework, your runtime, your development kit version, etc. And not just that, but you can mix and match versions. Nobody tells you the ‘right’ way to do things — you can pick all of the options that work for you.

However, it’s important to recognize that this incredible flexibility is great for someone already immersed in these technologies, but daunting and discouraging to someone who isn’t. To this person, it’s pure, confusing fragmentation. Someone who wants to write a hello world app is going to say “what do you mean Ant v1.2.3 doesn’t work with Maven v4.5.6 and JUnit 7.8.9 on windows — I don’t even really know what those things are, I just want hello world!”

Something I’ve noticed that results from this too is that developers come to view understanding how to navigate this setup minefield as a badge of honor. Somewhere in the Java setup steps, I referred to this as “Emperor’s New Clothes” kind of tolerance for complexity. Everyone immersed in the world is afraid to call something out as byzantine and convoluted for fear of being labeled a newbie or lacking chops. But having battle scars from spending weeks configuring a development technology time and time again isn’t a badge of honor — it’s indicative of a problem in tooling.

Now that I have Java set up and finally working, I’m actually excited. I love developing in it. I like the language, I like the choices that I have with it, I love IntelliJ as a tool, and I like that I can work on any OS I choose. But I don’t think we need to settle for this horrendous “hello world” experience to have customizability. I would love to see work done on something that preserves all of the flexibility and power but allows developers to go to a site, download something, and then have a working java web setup. Something that has roughly the same number of steps and complexity of the Microsoft process (or the PHP process, which would be pretty close) would be ideal and perhaps even essential. In a world where the competition offers setup ease that allows developers to be up, productive and tweaking in minutes, a confusing process that spans hours or even days is a sure path to irrelevance and obsolescence. Maybe this already exists (and please someone correct me if I’m just not aware of it — seriously, I’d love it), but it seems doubtful given the number of entire series of posts dedicated to basic setup. If it doesn’t exist, it ought to, and not to stop me from grousing but for the future of the technology stack.


Walking the Line between Fanboy and Luddite

Are Unit Tests Overused?

I was reading this blog post by Andrew Hunter recently where he poses the question as to whether or not unit tests are overused. The core of his argument is a rather nuanced one that seems to hinge on two main points of wariness:

  1. Developers may view unit tests as a golden hammer and ignore other important forms of verification such as integration tests
  2. Unit tests that are too finely grained cause maintenance problems by breaking encapsulation.

I think the former is a great point, but am not really sold on the latter since I’d argue that the thing to do be to create a design where you didn’t have this problem (i.e. the problem isn’t with the amount of tests written, but with the design of the system).  But I don’t have any serious qualms with the point of the article, and I do like reading things like this from time to time as an ardent unit test proponent because the second you stop questioning the merit of your own practices is the same second you become the “because I’ve always done it that way, so get off my lawn” guy. Once I finished reading the article and scrolled down to the comments, however, I noticed an interesting trend.

From the Peanut Gallery

There were a total of 11 comments on the article. One of them was a complete non sequitur (probably SPAM), so let’s shave the ranks down to 10 comments, which makes the math easier anyway for percents. Four readers agreed with the author’s nuanced “we’re overdoing it” take, four seemed to take issue in favor of unit testing and two were essentially rants against unit testing that seemed to mistake the author’s questioning of the extent to which unit tests should be taken for sympathy with the position that they aren’t necessary. And thus in the percentage of these blog reading developers (which many would argue are the most informed developers) 40% defend TDD/Unit testing wholesale, 40% are generally amenable to it but think that some take it too far, and 20% are (angrily) opposed to the practice.

Of the 20% demographic, the percentage of them that have experience writing unit tests is 0, taking them at face value. One says “In over 10 years of development I can count the number of unit tests I’ve written on one hand,” and another says “I event[sic] tried to learn how TDD could help me.” Of the others, it appears that 100% of them have experience writing unit tests, though with some it is not as clear as others. None of them cops to having zero experience the way the detractors do. So among people with experience writing unit tests, there is a 50/50 split as to whether TDD practitioners have it right or whether they should write fewer unit tests and more integration tests. Among people with no experience writing unit tests, there is a 100/0 split as to whether or not writing unit tests is stupid.

That’s all just by the numbers, but if you actually delve into the ‘logic’ fueling the anti-testing posts, it’s garden variety fallacy. One argument takes the form of a simple false syllogism, “Guy X did TDD and guy X sucked, therefore TDD sucks.” The other takes the form of argument from ignorance, “I tried to learn TDD and didn’t like it/failed at it, ergo there is no benefit to it.” (I say failed because in spite of its brevity the post contains a fundamental misunderstanding of the ‘rules’ of TDD and so there was either a failure to understand or the argument is also a strawman).

To play dime store psychologist for a moment, it seems pretty likely to me that statements/opinions like these are attempts to rationalize one’s choices and that the posters protest too much, methinks — angry/exasperated disparaging of automated testing by those who have never tried it is likely hiding a bit of internal insecurity that the overwhelming consensus in the developer world is right and they are wrong. After all, this blog post and the subsequent comments are sort of like a group of chefs debating whether something would taste better with two teaspoons of sugar or three when along comes an admitted non-chef who says “I hate sugar because this guy I don’t like puts it in his coffee and I’ve never eaten it anyway, so it can’t be any good.” The chefs probably look at him with a suffering, bemused expression and give out with an “Aaannnnywho…”

Skeptic or Luddite, Informed or Fanboy?

Another way that one might describe this situation and pass judgment on both the development industry as a whole and these commenters too is to label them the developer equivalent of Luddites. After all, the debate as to the merits of unit testing is widely considered over and most of those who don’t do it say things like “I’d like to start” or they make up weird excuses. Unit testing is The Way Forward (caps intentional) and commenters like these are standing around, wishing for a simpler time where their approach was valued and less was asked of them.

But is that really fair? I mean, if you read my posts, my opinion on the merits of TDD and automated verification in general is no secret, but there’s an interesting issue at play here. Are people with attitudes like this really Luddites, or are they just conservative/skeptic types providing a counterpoint to the early-adopter types only ever interested in the new hotness of the week. You know the types that I mean – the ones who think TDD was so last year and BDD was so last month, and now it’s really all about YDD, which is so new and hot that nobody, including those doing it, knows what the Y stands for yet.

So in drawing a contrast between two roughly described archetypes, how are we to distinguish between “this might be a blip or passing fad” and “this seems to be a new way of doing things that has real value?” Walk too far on one side of the line and you risk being left behind or not taken seriously (and subsequently leaving angry justifications in blog comments) and walk too far on the other side of the line and you’ll engage in counterproductive thrashing and tilting at windmills in your approach, becoming a jack of all new trades while mastering none. Here are some things that I do personally in my attempt to walk this fine line, and would offer as advice to you if you’re interested:

  1. Pick out some successful developers/bloggers/authors/experts that you admire/respect and scan their opinions on things, when offered. It may seem a little “follow the herd,” but I view it as like asking friends for movie recommendations without going to see every movie that comes out.
  2. Don’t adopt any new practice/approach/etc unless you can articulate a problem that it solves for you.
  3. Limit your adoption bandwidth: if you’ve decided to adopt a new persistence model such as a NoSQL alternative to RDBMS, you might not also want to do it a new language (assuming that you’re doing this on someone else’s dime, anyway)
  4. Let others kick the tires a bit and then try it out. This gives you a bit of a bet hedge on whether something will fizzle and die before you commit to it.
  5. If you decide not to adopt something that seems new and hot, keep your finger on the pulse of it and read about its progress and the pains and joys of its adopters. It is possible not to adopt something without avoiding (or refusing to learn about) it.
  6. If you don’t see the value in something or you simply don’t have time/interest in it, don’t presume to think it has no value.
  7. Go to shows/conferences/talks/etc to see what all the fuss is about. This is a low-impact/low-commitment way to see what the fuss is about.

If you have suggestions for how to approach this balancing act, I’d be interested to hear them as well. Because while I think there’s definitely some margin for error, it’s important, if not easy, to avoid being either the person whose life is a never-ending string of partially completed projects and the person who has had the same year of COBOL programming experience for each of the past 30 years.


FeedPaper is Born!

As of Thursday, 11/02/12, a baby ASP MVC project named FeedPaper (later to be feedpapyr.us) has arrived. It is healthy and weights 0 pounds and 0 ounces. Both it and I are doing well, and while it does not yet have much in the way of functionality, it does have its father’s logo and some functional unit tests. (As an aside and leaving this strained metaphor, I’ve never really understood why the weight of babies is announced to me as if someone were trying to sell me a ham — what do I care how much anyone weighs? It’s always tempting for me to respond by saying, “big deal – I totally weigh more than that.”)

Anyway, you can find the source for it on Github. As I mentioned in a previous post, the main thing that I’m interested in is getting this thing up and running, so I’m happy to accept pull requests, suggestions, help, and anything else you’re willing to offer. The plan is to get it going as a website and then perhaps later port the presentation portion of it to phone/tablet implementations as well. But, no sense putting the cart before the horse — I have to figure out ASP MVC 4 first.

So, look for sporadic work on this when I have time and feel like tinkering and am not working on home automation with Java and MongoDB. I will also make posts here and there about lessons I learn as I ham-fist my way through it, talking about my experiences with the frameworks and toolsets involved. Also, in general, I’m looking for the best options for hosting the site, so suggestions are welcome (should I try out Azure, go a more traditional route, etc).



The Developer Incentive Snakepit

Getting Incentives Wrong

A while ago I was talking to a friend of mine, and he told me that developers in his shop get monetary bonuses for absorbing additional scope in a “waterfall” project. (I use quotes because I don’t think that “waterfall” is actually a thing — I think it’s just collective procrastination followed by iterative development) . That sounds reasonable and harmless at first. Developers get paid more money if they are able to adapt successfully to late-breaking changes without pushing back the delivery date. Fair enough…. or is it?

Image credit to Renaud d’Avout d’Auerstaedt via wikimedia commons.

Let’s digress for a moment.  In colonial India, the ruling British got tired of all of the cobras hanging around and being angry and poisonous and whatnot, so they concocted a scheme to address this problem. Reasoning that more dead cobras meant fewer living cobras, they began to offer a reward/bounty for any cobra corpses brought in to them by locals. As some dead cobras started coming in, circumstances initially improved, but after a while the number of dead cobras being brought in exploded even though the number of living cobras actually seemed to increase a little as well.  How is this possible?  The British discovered that Indian locals were (cleverly) breeding cobras that they could kill and thus cash in on the reward. Incensed, the British immediately discontinued the program. The cobra breeders, who had no more use for the things, promptly discarded them, resulting in an enormous increase in the local, wild cobra population. This is an iconic example of what has come to be called “The Law of Unintended Consequences“, which is a catch-all for describing situations where an incentive-based plan has an effect other than the desired outcome, be it oblique or directly counter. The Cobra Effect is an example of the latter.

Going back to the “money for changes absorbed” incentive plan, let’s consider if there might be the potential for “cobra breeders” to start gaming the system or perhaps less cynical, subconscious games that might go on. Here are some that I can think of:

  1. Change requests arise when the actual requirements differ from those defined initially, so developers have a vested interest in initial requirements being wrong or incomplete.
  2. Change requests will happen if the marketing/UX/PM/etc stakeholders don’t communicate requirements clearly to developers, so developers have a vested interest in avoiding these stakeholders.
  3. Things reported as bugs/defects/issues require changes to the software, which developers have to fix for free, but if those same items were, for some reason, re-classified as change requests, developers would make more money.
  4. The concept of “change request” doesn’t exist in agile development methodologies since any requirement is considered a change request, and thus developers would lose money if a different development methodology were adopted.

So now, putting our more cynical hats on, let’s consider what kind of outcomes these rational interests will probably lead to:

  1. Developers are actively obstructionist during the “requirements phase”.
  2. Developers avoid or are outright hostile toward their stakeholders.
  3. Developers battle endlessly with QA and project management, refusing to accept any responsibility for problems and saying things like “there was nothing in the functional spec that said it shouldn’t crash when you click that button!”
  4. Developers actively resist changes that would benefit the business, favoring rigidity over flexibility.

Think of the irony of item (4) in this scenario.  The ostensible goal of this whole process is to reward the development group for being more flexible when it comes to meeting the business demands.  And yet when incentives are created with the intention of promoting that flexibility, they actually have the effect of reducing it.  The managers of this department are the colonial British and the cash for absorbed change requests is the cash for dead cobras.  By rewarding the devs for dead cobras instead of fewer cobras, you wind up with more cobras; the developers’ goal isn’t more flexibility but more satisfied change requests, and the best way to achieve this goal is to generate software that needs a lot of changes as far as the business is concerned.  It’s an example of the kind of gerrymandering and sandbagging that I alluded to in an earlier post and it makes me wonder how many apparently absurd developer behaviors might be caused by nonsensical or misguided incentive structures triggering developers to game the system.

So what would be a better approach?  I mean with these Cobra Effect situations, hindsight is going to be 20/20.  It’s easy for us to say that it’s stupid to pay people for dead cobras, and it was only after ruminating on the idea for a while that the relationship between certain difficulties of the group in question and the incentive structure occurred to me.  These ideas seem generally reasonable on their faces and people who second guess them might be accused of arm-chair quarterbacking.

Get Rid of Cobras with Better Incentives

I would say that the most important thing is to align incentives as closely as possible with goals and to avoid rewarding process adherence.  For example, with this change request absorbed incentive, what is the actual goal, and what is being rewarded?  The actual reward is easy, particularly if you consider it obtusely (and you should): developers are rewarded when actual requirements are satisfied on time in spite of not matching the original requirements.  There’s nothing in there about flexibility or business needs — just two simple criteria: bad original requirements and on-time shipping.  I think there’s value in stating the incentive simply (obtusely) because it tends to strip out our natural, mile-a-minute deductions.  Try it on the British Empire with its cobra problem:  more cobra corpses means more money.  There’s nothing that says the cobra corpses have to be local or that the number of cobras in the area has to decrease.  That’s the incentive provider being cute and clever and reasoning that one is the logical outcome of the other.

Flexibility image credit to “RDECOM” via wikimedia commons.

Going back to the bad software incentives, the important thing is to pull back and consider larger goals.  Why would a company want change requests absorbed?  Probably because absorbed change requests (while still meeting a schedule) are a symptom (not a logical outcome, mind you) of flexibility.  Aha, so flexibility is the goal, right?  Well, no, I would argue.  Flexibility is a means rather than an end.  I mean, outside of a circus contortionist exhibit, nobody gets paid simply to be flexible.  Flexibility is a symptom of another trend, and I suspect that’s where we’ll find our answer.

Why would a company want to be flexible when it comes to putting out software?  Maybe they have a requirement from the marketing department stating that they want to cut a sort of hip, latest-and-greatest feel, so the GUI has to constantly be updated with whatever latest user experience/design trends are coming from Apple or whoever is currently the Georgio Armani of application design.  Maybe they’re starting on a release now and they know their competition is coming out with something in 3 months that they’re going to want to mimic in the next release, but they don’t yet know what that thing is.  Maybe they just haven’t had any resources available to flesh out more than a few wireframes for a few screens but don’t want all progress halted, “waterfall” style, until every last detail of every last screen is hammered out in IRS Tax Code-like detail.

Aha!  Now we’re talking about actual business goals rather than slices of process that someone thinks will help the goals be achieved.  Why not reward the developers (and QA, marketing, UX, etc as well) for those business goals being met rather than for adherence to some smaller process?  Sadly, I think the answer is a command and control style of hierarchical management that often seeks to justify positions with fiefdoms of responsibility and opacity.  In other words, many organizations will have a CEO state these business goals and then hand down a mandate of “software should be flexible” to some VP, who in turn hands down a mandate of “bonuses for change requests absorbed” to the manager of the software group or some such thing.  It is vital to resist that structure as much as possible since providing an incentive structure divorced from broader goals practically ensures that the prospective recipients of the structure care nothing whatsoever for anything other than gaming the system in their own favor.  And in some cases, such as our case, this leads to open and predictable conflicts with other groups that have (possibly directly contradicting) incentive structures of their own.  As an extreme example, imagine a tech group where the QA team gets money for each bug they find and the developers lose money for the same.  A good way to ensure quality… or a good way to ensure fistfights in your halls?


Why keep things so simple and not fan out the deductive thinking about incentives, particularly in the software world?  Well, software people by nature are knowledge workers that are paid to use well-developed, creative problem-solving skills.  Incentives that work on assembly line workers such as “more money for more holes drilled per hour” are more likely to backfire when applied to people who make their living inventing ways to automate, enhance and optimize processes.  Software people will become quickly adept at gaming your system because it’s what you pay them to do.  If you reward them for process, they’ll automate to maximize the reward, whether or not it’s good for the business.  But if you reward them for goals met, they will apply their acute problem solving skills to devising the best process for solving the problem — quite possibly better than the one you advise them to follow.

If you’re in a position to introduce incentives, think carefully about the incentives that you introduce and how closely they mirror your actual goals.  Resist the impulse to reward people for following some process that you assume is the best one.  Resist the impulse to get clever and think “If A, then B, then C, then D, so I’ll reward people for D in order to get A.”  That’s the sort of thinking that leads to people on your team dropping cobras in your lunch bag.  Metaphorical cobras.  And sometimes real cobras.  If you work with murderers.


TDD For Breaking Problems Apart 3: Finishing Up

Last time, we left off with a bowling score calculator that handled basic score calculation with the exception of double strikes and the tenth frame. Here is the code as of right now for both classes:

Without further ado, let’s get back to work. The first thing I’d like to do is actually a refactor. I think it would be more expressive when creating strikes to use a static property, Frame.Strike, rather than new Frame(10, 0). Since the strike is completely specific in nature and a named case, I think this approach makes sense. So the first thing that I’m going to do is test that it returns a frame where IsStrike is true:

(This is actually what the test looked like after two red-green-refactors, since the first one was just to define Frame.Strike). At this point, I now have a static property that I can use and I’m going to find everywhere in my score calculator and frame test classes that I queued up a strike and use that instead as part of this refactor cycle. While I’m at it, I also demote the visibility of Frame.Mark, since I realize I should have done that a while ago. The Mark constant isn’t needed outside of Frame since Frame is now expressive with IsStrike, IsSpare and Total. Strictly speaking, I should conceive of some test to write that will fail if Mark is visible outside of the class, but I try to be pragmatic, and that’s a screwy test to have and persist.

Now, let’s get down to brass tacks and fix the double strike issue. If I bowl a strike in the first frame, another in the second frame, and then a 9 in the third frame, my total score should be 57 in the third (29+19+9). Let’s write such a test:

How to get this to pass… well, I’ll just tack on an extra frame.FirstThrow if the last two were strikes:

… and NCrunch gives me green. Now, let’s make the class a little nicer to look at:

And, that’s that. Now we have to think about the 10th frame. This is going to be interesting because the 10th frame is completely different in concept than the other frames. The 10th frame’s total can range up to 30 instead of being capped at 10, and if you get a strike in the first frame or spare in the second frame, you get three throws instead of two. How to model this with what we have… add a new property to the frame class called “ThirdThrow”? That seems reasonable, but what if we populate the third throw when we’re not in the 10th frame? That’s no good — how can we know that a frame is a 10th frame? We’ll probably need a boolean property called IsTenthFrame… right?

Wrong! (At least in my opinion). That amounts to adding a flag that clients look at to know how to treat the object. If the flag is set to true, we treat it like one kind of object and if it’s set to false, we treat it like another kind. This is a code smell in my opinion — one that I think of as “polymorphism envy” or “poor man’s polymorphism”. This is a milder version of the kind you usually see which is some ObjectType enum that clients switch over. We don’t have that (yet) because we only have two values.

So if we’re contemplating a polymorphism envy approach, it stands to reason that maybe what we’re nibbling at is, well, actual polymorphism. Maybe we should have a TenthFrame class that derives from Frame and overrides important functionality. I don’t know that this is the solution, but TDD is about solving small problems incrementally, so let’s start down this path and see where it leads. We don’t need all of the answers this minute. The first thing to test is probably going to be that total is the sum of the three constructor arguments:

As I wrote this test, two things didn’t compile. The first was the instantiation of the TenthFrame, which I solved by declaring it. The second was the Total property, which I solved by inheriting from Frame. That actually turned out to be an easier way to get a red test than declaring the property (and more productive toward our design). Then to get the test passing, the easiest thing to do was make Frame’s total virtual and override it in TenthFrame. So, pretty quickly we seem to be getting Total right:

Now we need to start tweaking the business rules. Parent is going to throw an exception if we initialize frame 1 and 2 each to a strike, but that’s fine in the 10th frame. Here’s a failing test:

To get this passing, I declare a default constructor in the base (to make the compiler happy) and have the new class’s constructor implement its own assignment logic to avoid the checks in parent that cause this failure. But now that simple assignment is restored, we need to implement our own rules, which will include throwing exceptions for throws greater than ten or less than zero, but it will also include oddballs like this that I don’t yet know how to describe:

This is another one of the real draws of TDD. I don’t know what to call this or how to categorize it, but I have an example, and that’s all I need to get started. I just have to make this pass:

I could have just tested for the specific literals in the test, but I didn’t feel the need to be that obtuse. You can really control your own destiny somewhat with “simplest thing to make the test pass”. IF you have no idea what direction the design should take, maybe you go that obtuse route. If you have some half-formed idea, as I do here, it’s fine to get a little more business-logic-y. I’m going to dial up another case that should fail because of the relationship between second and third frame and take if from there:

Now I have the following production code to get it to pass:

But, that’s getting a little fugly, so let’s refactor:

Ah, a business rule is starting to emerge. In general, if a throw is not a mark, then it and the subsequent throw can’t be greater than 10. Hey, come to think of it, that sounds right from my bowling experience. They only reset the pins if you knock ’em all down. Of course, we have one final rule to implement, which is that if the first and second throws don’t knock all the pins down, there is no third throw. I’ll leave that out, since it’s pretty easy.

Now the time has arrived for some integration testing. I found a site that has some example bowling scores, and I’m going to code one up:

If you’re following along, you’ll see green in NCrunch. Let’s try one more:

Oops. Red. So, what happened? Well, I went back through game, setting temporary asserts until I found that things went off the rails following the third strike in a row. I then looked in my class at the logic following the two strikes and realized it wasn’t quite right:

I commented out the mistake and put in the correct code, and the entire test suite went green, including the integration test for Kim. I think this is a good note to close on because the tests are all passing and I believe the calculator is functioning (here it is on gist if you want to check out the final product) but also because I think there’s a valuable point here.

TDD is a design methodology — not a guarantee of bug free code/comprehensive testing strategy. I experienced and even blogged about writing code for days using TDD and assembling all the parts and having it work flawlessly the first time, and that did happen. But I realized that even with that, the happy and happy-ish paths were the ones that worked. Here, I had a bowling calculator that made it through all individual scoring tests and even an entire non-trivial game going green before we teased out a case in smoke testing where it went red.

TDD will help you break problems into small pieces to solve (the whole point of this series of posts), ensure that your code is testable and thus loosely coupled and modular, ensure that you don’t push dirty mop water around the floor by breaking functionality that you had working before, and generally promote good code. But think about this — those are all productive programming concerns rather than testing concerns. You still need testers, you still need edge case unit tests once you’re done with TDD, and you still need integration/smoke tests. The fact that TDD produces a lot of tests that you can check in and continue to use is really just a bonus.

And it’s a bonus that keeps on giving. Because let’s say that you don’t agree with my decision to use inheritance for tenth frame or you think strike would be a more appropriate descriptor of a throw than of a frame. With all of my TDD test artifacts (and the integration tests) in place, you can rip my internal design to pieces without worrying that you’re going to break the functionality that this provides to clients. And that’s incredibly powerful for allowing fearless refactoring and maintenance of this code. So do it to break your problems apart and keep yourself moving and productive, and keep the tests around to make sure the code stays clean and trends toward improvement rather than rot.

Full Code


Hilarious Conditional Bloopers!

For this Friday, I thought I’d do something a little more lighthearted and, in the tradition of bad television (or Robot Chicken’s satire thereof) post some programming bloopers. These are actual things that I’ve personally seen in source code as opposed to some kind of specific sampling of CodeSOD from the Daily WTF. Doing this series of posts about Boolean algebra made me think conditional logic fails I’ve seen both recently and long in the past.

For each one, I’ve tried my best to give it a catchy name, an explanation of the problem, an example of what it translates to in simple English (i.e. why it doesn’t “read like well written prose”), and what it ought to look like. So, without further ado, here are the bloopers:

The Ingrown Branch

I call this The Ingrown Branch because of what it does. It introduces a conditional — a fork in the road, if you will — and it winds up in the same spot no matter which branch you take. In conversational English, this says “if the number of milk cartons is not 12, make it 12″. While this doesn’t sound ridiculous in the same way that others here will, consider what’s being done. If x is equal to 12, well, then do nothing because x is equal to 12. Otherwise, if it’s not equal to 12, set it to 12. What would be a simpler way to do this?

The Tautology

In conversational English, a tautology is something that is vacuously true or redundant. In logic, this is something that is always true, ipso facto, such as “A or NOT(A)”, for instance. In terms of conversational English, this is like saying “If I’m out of milk or if I’m not out of milk, I’m going to go buy some milk.” Why not drop the spurious conditionals and get to the point:

The Contradiction

The opposite of a tautology, a contradiction is something that is vacuously false, such as primitive type not being equal to itself. With instances like this and the tautology, I usually see more complex incarnations that are harder to spot or else I give the benefit of the doubt and assume that manipulation of a more complex conditional occurred in the past and the thing was accidentally left in this condition. But this doesn’t alter the fact that I have seen code like this and that, in plain English, this would translate to “If I’m both completely out of milk and I have some milk, I’m going to buy milk.” It’s mind-bending nonsense that would best be described as:

The Double Negative

I realize that this may be largely a product of speaking English as a first language, since double (and more) negatives are acceptable in some other languages. But you have to look at code like this and think, did anyone read this to themselves? “If I it’s false that I’m not out of milk, I will go to the store.” Wat? Okay, so not out of milk means that you have it, so if it’s false that you’re not out of milk, it’s false that you have it, and you are out of milk… aha! Why didn’t you just say so:


An if within an if within an if… (credit to Dan Martin for this term). This is another mind-bending way of writing things that is rather jarring to the reader of the code, like saying “If I’m out of milk if I’m out of eggs if I’m out of beer, then I’m going to the store.” Dude, wat? Oh, you mean “If you’re out of milk AND you’re out of eggs AND you’re out of beer, then you’re going to the store? Well, nice to see what your breakfast priorities are, but at least that doesn’t read like the mumblings of a lunatic.”

The Robot

Perhaps this is a little nitpicky, but this explicit formation of Boolean conditionals bothers me. “If it equals true that I am out of milk, I will go to the store” sounds like some robot helper from the Jetsons or one of those shows that features a preposterous token “genius” whose intelligence is conveyed by having him speak like some robot helper from the Jetsons. Why not “If I’m out of milk, I will go to the store?”

The Yoda

If program in C you do, sense this makes and a clever trick to avoid assignment instead of comparison errors this is. If program in C you don’t, annoying and indicative that you’re not adopting the thinking of the language you’re working this is. When you speak English and try to sound like a native speaker, you don’t say “If missing is the milk, go to the store”. You say “If the milk is missing, go to the store.”

The Existential No-Op

Or, see variations where the comment is replaced by “return;” or some other similar thing. This is a conditional where, true or false, you do nothing. It sort of makes you question the very nature of (its) existence. This is like me saying to you “If I’m out of milk…” When you wait patiently for a moment and say “yes…?” I then say “nothing — that was all.” What should this be replaced with? How about just deleting the whole bit of nonsense?

Growing Pains

See what’s going on here? This conditional is growing so unwieldy that you forget by the end of it that you already mentioned being out of milk again. “If I’m out of milk, eggs, beer and milk, I’m going to the store.” “You said milk twice.” “I like milk.” How about dividing it up a bit and saying “If I am out of staples and I’m out of snacks, then I’m going to the store.”

The Mad Scoper

I think we’ve all seen one of these — someone on the team or in the group has a few too many cups of coffee and really goes to town on the old 9 and 0 keys. This is probably done to make sure that order of operations is being followed when you don’t understand the order of operations. Conversational equivalent? “If I am out of staples, and I mean staples and not whatever is coming next until I’m ready to talk about that and now I’m ready so I’m going to talk about that and that is snacks and not staples we’re not talking about staples anymore we’re talking about snacks which if I’m out of I’m also not going to the store, okay done.” Let’s dial it back to the last solution:

The Fly Swallower (aka The Train Wreck)

This is formally known as design with violations of the Law of Demeter, but it’s easier just to think of it as a train wreck. But the name I’m giving it comes from a nursery rhyme, which is how this starts to sound in conversational English. “There was an old lady who if she swallowed a horse who if it swallowed a cow who if it swallowed a hog who if it swallowed a dog…” How should this sound? There’s no easy fix. You need a different object model.

And with that, I’ll conclude my fun Friday post. This is meant to be light-hearted and in jest, but I’d say there’s definitely a good bit of truth here. You may not agree entirely with my assessment, but I think we’d all be well served to do the occasional double check to make sure we’re not leaving conditional bloopers in the code for others to read, triggering pointing and laughter. If you have other names for these or other conditional bloopers to mention (or you think I’m completely off base with one of these) please feel free to chime in.

Acknowledgements | Contact | About | Social Media