Steve Smith's Blog

A First Pass at PotterKata

ssmith — Thu, 22 Oct 2009 03:53:37 GMT

Tonight at Hudson Software Craftsmanship, I paired with another group member and worked on the PotterKata for the first time. I’d seen NotMyself write about it a few days ago, which prompted me to suggest it for the group to work on (summary of the meeting here).

Briefly, this kata is a fairly real-world exercise in that it has to do with business rules for a shopping cart that are non-linear. In this case, the rules are:

One copy of any of the five books costs 8 EUR. If, however, you buy two different books from the series, you get a 5% discount on those two books. If you buy 3 different books, you get a 10% discount. With 4 different books, you get a 20% discount. If you go the whole hog, and buy all 5, you get a huge 25% discount.

Note that if you buy, say, four books, of which 3 are different titles, you get a 10% discount on the 3 that form part of a set, but the fourth book still costs 8 EUR.

Attentive readers will notice that there is no 15% discount – there’s a big jump from 3 different titles (10%) to 4 (20%). Because of this, it’s possible to calculate the discount incorrectly (that is, not optimized for the buyer), with a cart that includes 2 of each of 3 titles and 1 of each of the remaining 2. If you make it a set of 5 (25% off) and a set of 2 (5% off) your price will be higher than if you make it 2 sets of 4 (20% off all of them).

My partner and I set about TDDing this with these tests (the first 3 are easy so I left out the actual implementation):

[Test]

public void EmptyCartShouldCostZero()

...

[Test]

public void CartWithOneBookShouldCostEightEuros()

...

[Test]

public void CartWithTwoOfSameBookShouldCost16Euros()

...

[Test]

public void CartWithTwoDifferentBooksShouldCost1520Euros()

    // Arrange

    var cart = new Cart();

    var book = new Book("One");

    var book2 = new Book("Two");

    cart.AddBookToCart(book);

    cart.AddBookToCart(book2);

    // Act

    var totalPrice = cart.GetTotalPrice();

    const decimal expectedCost = 2 * 8.0m * .95m;

    // Assert

    Assert.AreEqual(expectedCost, totalPrice);

At this point it’s possible to do the calculation work simply based on the total number of distinct titles in the cart. However, the next test is much harder:

[Test]

public void PriceCalculatorYields2320With2SameAnd1DifferentBooks()

    // Arrange

    var books = new List<CartItem>()

                        new CartItem(new Book("A"), 2),

                        new CartItem(new Book("C"), 1)

};

    // Act

    var totalPrice = new PriceCalculator().CalculatePrice(books);

    // Assert

    Assert.AreEqual(23.20m, totalPrice);

Note that at this point we moved the logic of calculating discounts into its own class, which we pass into our Cart (but which we can test in isolation from the cart, as shown here). This test required substantial rework of the calculation bits, because it was no longer sufficient to just multiply the total book quantity times the discount based on distinct titles.

The last test is the hardest one, and represents the acceptance test given in the Kata itself:

[Test]

public void PriceCalculatorYields5120WithGivenCartLoadOfBooks()

    // Arrange

    var books = new List<CartItem>()

                        new CartItem(new Book("A"), 2),

                        new CartItem(new Book("B"), 2),

                        new CartItem(new Book("C"), 2),

                        new CartItem(new Book("D"), 1),

                        new CartItem(new Book("E"), 1)

};

    // Act

    var totalPrice = new PriceCalculator().CalculatePrice(books);

    // Assert

    Assert.AreEqual(51.20m, totalPrice);

We were tight on time and one of the few pairs to get a working solution, so this code is still quite rough and would need additional tests and refactoring, but it works for this specific case. The main logic of the problem ended up all being in the PriceCalculator class shown below:

public class PriceCalculator : IPriceCalculator

    public const decimal BOOKPRICE = 8.0m;

    public decimal CalculatePrice(IEnumerable<CartItem> items)

        List<Book> bookSet = new List<Book>();

        var totalPrice = 0.0m;

do

            bookSet = GetUniqueBookSet(items);

            totalPrice += CalculateUniqueSetPrice(bookSet);

        } while (bookSet.Count > 0);

        return totalPrice;

    private List<Book> GetUniqueBookSet(IEnumerable<CartItem> items)

        var bookSet = new List<Book>();

        var itemsOrderedByCount = items.OrderByDescending(x => x.Quantity).Where(x => x.Quantity > 0);

        foreach (var item in itemsOrderedByCount)

            if (items.ToList().Count > 3)

                if (item.Quantity > 1)

                    AddBookToSet(item, bookSet);

                if (bookSet.Count == 3 && item.Quantity == 1)

                    AddBookToSet(item, bookSet);

        if (bookSet.Count > 0) {return bookSet;}

        foreach (var item in itemsOrderedByCount)

            if (item.Quantity > 0)

                AddBookToSet(item, bookSet);

        return bookSet;

    private void AddBookToSet(CartItem item, List<Book> bookSet)

        bookSet.Add(item.Book);

        item.Quantity--;

    public decimal CalculateUniqueSetPrice(IEnumerable<Book> books)

        var count = books.Count();

        var discountMultiple = 1.0m;

        switch (count)

            case 2:

                discountMultiple = 0.95m;

                break;

            case 3:

                discountMultiple = 0.90m;

                break;

            case 4:

                discountMultiple = 0.80m;

                break;

            case 5:

                discountMultiple = 0.75m;

                break;

        return count * discountMultiple * BOOKPRICE;

I’m pretty happy with the CalculateUniqueSetPrice() method; it’s clean and easy to follow. Likewise, CalculatePrice() is pretty easy to follow as well, though I’m not sure it’s as clear as it could be at expressing what it’s doing, which is pulling out sets of unique book titles and pricing each one. The actual logic for how it does the grouping of books into sets is in the big ugly GetUniqueBookSet method, which is full of magic numbers and inscrutable nested if statements. It’s nasty. If the discount schedule were to change such that the biggest jump in the discount schedule was not between 3 and 4 different titles, this method would break bigtime. But it works.

Note that we only ever group our collection of titles into sets once. This program has no intelligence or built-in optimization – that was all done by humans (we figured out that the magic number 3 was the threshold value). The more interesting problem to solve is one which works for any given discount schedule, by grouping the titles into sets in a variety of ways and seeing which resulted in the best price. One other pair did something close to this and completed the problem, and at least one other pair was working on a brute force approach that would literally try every possible set combination to see which resulted in the best price.

A simple way to discover the minimum optimal number of books to have per set (4 in this case), one could run through the discount schedule looking for the biggest gaps/differences. With the given schedule, the difference of 10% when going from 3 titles to 4 titles would be the largest (every other difference is only 5%). This calculation could be inserted to replace the magic number 3 in my implementation.

I’d also want to move from foreach() and nested ifs to LINQ and lamba expressions. I spent a little time trying this approach, but couldn’t get some of the syntax to work so ended up falling back to the familiarity of foreach() and if(). Still another option, not exclusive of this approach, would be to create a BookSet class which was capable of calculating its price, which would eliminate one of the responsibilities of PriceCalculator, which currently violates SRP because it is responsible for grouping books into sets as well as pricing such sets.

Anyway, it’s a fun kata if you want to give it a shot. If I have time to do it again on my own and to arrive at a more elegant solution, I’ll be sure to post it.

Which Visual Studio 2010 is Team Suite?

ssmith — Wed, 21 Oct 2009 13:02:00 GMT

The new VS 2010 has a new lineup of versions which you can find described on the Visual Studio 2010 Products page. Some things to note:

Ultimate is the new Suite
The “Data Dude” SKU is now fully incorporated in the Premium and Ultimate versions
Premium and Ultimate come with a production license for Expression Studio 3, as well as Visio and Project 2010.
All versions now come with some Windows Azure pieces for dev/test use
All versions ship with Team Foundation Server (which now supports running on the client as a lightweight alternative to a full server-side install), providing version control, build automation, bug tracking, and continuous automation out of the box very quickly

How to Install Windows 7 from USB Drive

ssmith — Wed, 14 Oct 2009 16:32:24 GMT

I decided to reinstall Win7 on one of my laptops because it was acting up – turns out that’s not helping and I think at this point it’s a hardware problem (either memory or hard drive – I’m going to try memory next). In the course of troubleshooting the problem, I decided to rule out a bad installer DVD for Windows 7 (the installer was failing, saying it couldn’t access certain required files). So I created a USB installer for Windows 7 x64. And since I’ve been meaning to install Win7 on my Dell mini10 for a while (which has no CD/DVD reader), I also created a separate USB installer for it for Win7 32-bit x86.

I found this post to be helpful, but it has some problems in the original post that are corrected in the comments. However, there are about a million comments so to save you the trouble of reading them all and trying to figure out which are correct, let me just post what worked for me here. I’m sure this is not the only way to create a USB thumb / flash drive installer for Windows 7, but it is one that I can confirm works.

Requirements

You need a 4GB or larger USB drive.

You also need the 32-bit ISO for Windows 7 no matter what, and you need the 64-bit ISO if you’re planning on making a 64-bit installer. (I’m assuming you need the 32-bit ISO in order to run the bootsect command correctly from a 32-bit machine based on a comment I read. I haven’t tried creating an installer from a 64-bit machine nor have I tried running the 64-bit ISO’s bootsect command, so I can’t say how or if those methods work).

I performed all of these steps on a 32-bit Windows Vista installation.

Creating a Windows 7 USB Drive Installer

1. Download MBRWiz and unzip it to some folder.

2. Insert your USB drive, make sure there’s nothing on it you need (it’s about to all be destroyed), and Format it. If you’re in Vista you simply right-click on it and select Format, choosing NTFS as the file system.

3. Mount your Windows 7 32-bit ISO as a drive (using MagicDisc or something similar).

4. Open up a cmd windows with administrator privileges. The easiest way to do this is to go to Start > Run and type ‘cmd’ and then press ctrl-shift-enter (instead of just enter).

5. Change to the folder where you unzipped MBRWiz and run the following commands:

mbrwiz /list (note the disk number of your USB drive)

mbrwiz /disk=X /active=1 (replace X with the number of your USB drive)

In my screenshot below you can see that my disk number for my USB drive is 1, so I used /disk=1 /active=1 for my command.

6. Now in the same cmd window, change to your ISO mounted drive (in my case the F drive). Type the following commands, replacing e: with the actual drive letter of your USB drive:

cd boot

bootsect /nt60 e:

Your command window should read more-or-less like the following screenshot (click for full size):

7. Last, copy all of the files from your ISO mounted drive to your USB drive. If you are creating a 64-bit installer, unmount the 32-bit ISO first, then mount the 64-bit ISO and copy the files from there.

Summary

I just followed these steps, twice, to create one 32-bit and one 64-bit Windows 7 USB thumb drive installers. I can confirm that these steps work for me doing all of the creation work from a 32-bit Vista machine. I can’t attest to any other configuration or process’s likelihood to work or not, but feel free to comment if you have suggestions, improvements, or success stories to share.

Avoid Entrenched Dependencies

ssmith — Tue, 13 Oct 2009 15:51:00 GMT

Last year I wrote about Avoiding Dependencies and described some Insidious Dependencies (with help from many commenters) that many developers might not immediately recognize as dependencies. It occurred to me today that I should point out that dependencies themselves are not intrinsically bad design – all software has dependencies. The important distinction here that I think is a best practice is that one should make efforts to avoid entrenched dependencies on things that are likely to change.

As an example, I write most of my software using Microsoft .NET. I’m inherently taking a dependency on the CLR. If at some point the customer’s needs dictate that I need to move to Java or Ruby, that is most likely going to be a painful thing. However, I don’t foresee such a change being required, so I’m happy to have tight coupling to .NET for most of my applications.

When you perform a code review, whether for your own software or for someone else’s, one of the things you should analyze are the dependencies the code has, and whether these are implicit or explicit and whether they are entrenched or flexible. If the software simply instantiates classes directly wherever it might need them, and makes no use of Dependency Injection, it’s likely to be riddled with implicit and entrenched dependencies. On the other hand, if classes identify their dependencies in their constructor via interfaces, and an IoC container is in place to allow easy management of the actual implementation classes that are used at runtime (that conform to these interfaces), then the dependencies are explicit and flexible. (and on the other other hand, if everything is an interface, the application is likely to be more difficult to understand than necessary – see below)

There are costs associated with abstracting dependencies. In the extreme, every “new” in your code is a dependency on a particular implementation, and thus could be replaced with an interface and injected in. In practice, the main things you want to worry about abstracting are the ones that are most likely to change, and over which you have the least control. Things that need to change in order to test your code count as things that are likely to change, and thus should always be abstracted if you plan on writing good unit tests! Otherwise, don’t go overboard. Wait until your dependence on a particular implementation causes pain before you start extracting interfaces and DI-ing them into all of your classes. All things in moderation.

N Tier Design Lessons Learned Part 1

ssmith — Mon, 12 Oct 2009 15:54:00 GMT

Eight years ago this month I gave my first presentation at a conference. It was DevConnections’ Fall 2001 show, and it was held in Scottsdale, Arizona at the Princess Resort. The show was delayed a couple of weeks from its originally scheduled dates, and took place Sep 30 to Oct 3rd, as a result of the events of 11 September 2001. I still vividly remember the alarm with which my seatmate on the flight over (an older lady) observed that they had given us all plastic knives with our meals. I reassured her, “It’s OK, we all have them.”

As a result of the times and the rescheduling, the resort was a ghost town and the conference attendance was, shall we say, light. I think my 3 sessions pulled in attendance numbers of 6, 10, and 6, which I recall being pretty happy with as not all speakers managed to get double digit attendance. One of my sessions was on N-Tier Development in .NET. You can still download all of my 2001-2003 talks on my old training web site here. The talk which is the topic of this series is this one:

N-Tier Development in .NET (rename it to NTier.zip or something similar)

Lessons Learned

When I gave this talk, it was based on personal experience and a lot of industry best practices that I had picked up from other software professionals and from Microsoft itself. These included things like the IBuySpy samples and FMStocks samples, which in their time were amazing and wonderful and helped a ton of developers build effective and no doubt profitable applications using ASP.NET.

However, now I’m 8 years older and wiser, and there are things I certainly would change about how I recommended architecting applications in .NET in 2001. I know that millions of developers learned these same best practices, and that probably millions of developers continue to believe these remain best practices for building applications today. I’ve learned otherwise, and I am hoping to show through this series both why I’ve changed the way I do things and how to go about changing a .NET Solution from what I’ll refer to as “traditional n-tier” architecture to a more domain-driven or onion architecture.

The Original Presentation

Unzip the file into a folder and you should see something like this:

If you look at the slide deck (which I would totally redo today, naturally), you’ll see Slide 9 shows this diagram:

This was always one of my favorite slides in this talk. I believe I got this diagram from MSDN – I know I didn’t create it myself (slide 10 shows the extent of my diagram creation skills at the time). N-tier architecture was actually kind of novel back in 2001. there were plenty of developers in the audience who weren’t familiar with the concept or hadn’t bought into it yet. Today, it seems like most developers I talk to are certainly familiar with this separation into layers, and I would say that most mainstream .NET developers in the last few years are following a Two- or Three- tier architecture. However, only a minority of them create their solutions in such a way that the Data Access Layer assembly is not referenced directly by the Business Logic assembly, which in turn is referenced directly by the Presentation Layer. This is an anti-pattern (Data Driven Architecture), and is one of the lessons learned that I will cover in the next part of this series.

I’ll also include a download of a slightly cleaned up version of the sample code, updated to use a VS2008 solution file and including the schema needed for the User table, to save anyone wishing to follow along in the code the tedium of such things. But I wanted to point to the actual, original file so that you could see it in all its glory, warts and all, and see how far we’ve come in the last 8 years.

Find String in Files with Given Extension Using PowerShell

ssmith — Sun, 11 Oct 2009 17:56:56 GMT

This week I found myself wanting to search within files of a given extension for a particular substring. I often find myself missing UNIX’s grep tool. In any event, I tried using the default Windows Vista file search dialog, but found that if I wanted to search for “connection” or “database” within all files ending with “.cs” or “.config” I was unable to do so. I’m guessing there actually *is* a way to do this from the GUI, but after spending a couple of minutes either searching all files for the text “.cs” or else searching for files named “connection” I opted to just do it from the command line using PowerShell.

PowerShell is just freaking amazing. Seriously. Being able to easily store collections of objects in ad-hoc variables (named $something) and then to further be able to pipe the output of anything to anything (using | just like most other shells), you can quickly do some amazing stuff. I use PowerShell all the time now to make downloading pictures from my camera and organizing them by date easy.

To get a list of all files with a given extension that contain a given string, you can use the following steps (click on the screenshot to see it full size).

Move to the appropriate folder. While not strictly necessary, this will make your life easier. The standard “cd” command from DOS works for this, but remember you can’t do “cd\” you have to do “cd \” to move to the root of the current volume.
Get a list of all files. This isn’t strictly required but again using an intermediate step like this can ensure you catch any mistakes in your operation earlier. To get a collection of all the files in and below your current folder, use: $AllFiles = Get-ChildItem –recurse
Next we’ll filter our list to only include files with the extension we want. If we’re looking for all of our C# source files, we would search for extensions that end with “.cs”. Note that the $_ value refers to the current item in the collection as we loop through them applying our filter condition. The “-eq” means “equals”. The full command to create a new collection named $CSharpFiles is: $CSharpFiles = $AllFiles | where {$_.extension –eq “.cs” }
The next step is again not strictly necessary since we could simply write out the command, but it does show another useful PowerShell feature, namely the ability to alias commands with shorthand strings. For example, the Select-String command is useful for matching files that contain a particular string, but if you’d prefer to just type “ss” for this, you can alias it like so: Set-Alias ss Select-String
Finally, we’ll use the ss alias on our filtered list of files to find all files containing the string “SqlConnection” which might be useful if you’re trying to ensure nobody is using ADO.NET when they should be using your ORM: ss SqlConnection $CSharpFiles | format-table Path

The result will be the paths of all files that contain that string. If you leave off Path from the end of the command, your table will include the line number and the actual Line of the file that matched the string you specified.

So there you go. It took much longer to write this blog post than to figure all of this out in PowerShell and find the files I was after. Here are a couple of links that helped me get here:

Don’t Repeat Yourself

ssmith — Sun, 11 Oct 2009 03:12:44 GMT

(this is a submission I made to the upcoming 97 Things Every Programmer Should Know book)

Of all the principles of programming, Don't Repeat Yourself (DRY) is perhaps one of the most fundamental. The principle was formulated by Andy Hunt and Dave Thomas in The Pragmatic Programmer, and underlies many other well-known software development best practices and design patterns. The developer who learns to recognize duplication, and understands how to eliminate it through appropriate practice and proper abstraction, can produce much cleaner code than one who continuously infects the application with unnecessary repetition.

Duplication is waste

Every line of code that goes into an application must be maintained, and is a potential source of future bugs. Duplication needlessly bloats the codebase, resulting in more opportunities for bugs and adding accidental complexity to the system. The bloat that duplication adds to the system also makes it more difficult for developers working with the system to fully understand the entire system, or to be certain that changes made in one location do not also need to be made in other places that duplicate the logic they are working on. DRY requires that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

Repetition in process calls for automation

Many processes in software development are repetitive and easily automated. The DRY principle applies in these contexts as well as in the source code of the application. Manual testing is slow, error-prone, and difficult to repeat, so automated test suites should be used, if possible. Integrating software can be time consuming and error-prone if done manually, so a build process should be run as frequently as possible, ideally with every check-in. Wherever painful manual processes exist that can be automated, they should be automated and standardized. The goal is to ensure there is only one way of accomplishing the task, and it is as painless as possible.

Repetition in logic calls for abstraction

Repetition in logic can take many forms. Copy-and-paste if-then or switch-case logic is among the easiest to detect and correct. Many design patterns have the explicit goal of reducing or eliminating duplication in logic within an application. If an object typically requires several things to happen before it can be used, this can be accomplished with an Abstract Factory or a Factory Method. If an object has many possible variations in its behavior, these behaviors can be injected using the Strategy pattern rather than large if-then structures. In fact, the formulation of design patterns themselves is an attempt to reduce the duplication of effort required to solve common problems and discuss such solutions. In addition, DRY can be applied to structures, such as database schema, resulting in normalization.

A Matter of principle

Other software principles are also related to DRY. The Once and Only Once principle, which applies only to the functional behavior of code, can be thought of as a subset of DRY. The Open/Closed Principle, which states that "software entities should be open for extension, but closed for modification," only works in practice when DRY is followed. Likewise, the well-known Single Responsibility Principle requires that a class have "only one reason to change," and relies on DRY.

When followed with regard to structure, logic, process, and function, the DRY principle provides fundamental guidance to software developers and aids the creation of simpler, more maintainable, higher-quality applications. While there are scenarios where repetition can be necessary to meet performance or other requirements (e.g., data denormalization in a database), it should be used only where it directly addresses an actual rather than an imagined problem.

Principles, Patterns, and Practices of Mediocre Programming

ssmith — Thu, 08 Oct 2009 18:43:49 GMT

This is my first pass at a list of anti-principles, anti-patterns, and anti-practices that make up mediocre programming. I’m hoping to refine this list and update this listing based on community feedback, so please leave a comment or contact me to let me know what I’ve missed, and I’ll gladly credit you with a name and a link if you’d like.

Principles

Fast Beats Right (FBR) – It’s more important to get something done that probably works, or that works right now even if it will be hard to change later, than to spend time ensuring that it is correct or is well designed. This is classic “cowboy coder” or “duct tape programmer” thinking, and sometimes management may be OK with dictating that for a given feature or prototype, speed is more important than anything else. However, for typical, long-term projects where someone is going to have to maintain the application for years to come, this can be a very expensive principle to follow.

Preferred Principle(s)

“Continuous attention to technical excellence and good design enhances agility” – Agile Manifesto

Feaping Creaturitis Driven (FCD) - A project built using FCD never, ever has a cycle that completes appropriately. Just when you can see the horizon, someone on the team adds yet another nozzle or value that they are desperately in love with.

Preferred Principle(s)

Plan with a short delivery schedule, deliver on that plan, and plan the next cycle. Avoid throwing new work into the current cycle.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” – Agile Manifesto

Source

Roger Pence (with credit to PL Plauger for the term “feeping creaturitis”)

Assumption Driven Programming (ADP) – Rather than wasting time thinking about edge cases, assume that the user will only use your software the way you mean for them to, and that nothing bad will happen. This is the quickest way to knock out a feature and be able to demo it to the customer anyway (as long as you are in charge of the demo script), and besides, it should be obvious to anyone how they’re supposed to use the application, so it’s the user’s fault if they do something unexpected.

Some typical “Assumptionist” questions:

“What do you mean, you can’t change the configuration on a shared host?”

“Why would the user type garbage in the address bar?”

“Who would try to put a script file through this image upload form?”

“Why would someone type SQL into a textbox clearly labeled ‘username’?”

ADP often leads to uncaught “sad path” bugs and security holes.

Preferred Principle(s)

Practice some defensive coding, and verify that inputs to your method are what you expect before working with them.

Define with the customer what should happen when the unexpected occurs, and treat this behavior like any other feature.

Write one test for the “happy (expected) path” but write several tests for various “sad paths” where things could go wrong.

Source

Felix Pleşoianu

The Pragmatic Programmer calls this Programming by Coincidence (per Adam)

Telemarketer Principle (TP) - Programming is about control, and the best way to ensure that your software does exactly what you want is for you to manage exactly when and how it behaves at all times. The Telemarketer Principle is summed up as “Make lots of calls to anything you might need in the system for your program.” If you cede control to other modules or let the system or a framework do things on your behalf, can you really be sure they’ll do it right? And just in case, don’t forget that for anything really important you can always Reinvent The Wheel (RTW) and call your own routine all over the place instead.

Preferred Principle(s)

Follow the Hollywood Principle: “Don’t call us; we’ll call you.” If you find for instance that you’re making Response.Write or Console.Write or Window.Draw calls throughout your business logic, it’s likely that your design would benefit from this principle.

The Dependency Inversion Principle can also help remove dependencies like these, and set up the ability for the callee to become the caller.

(do you have more principles of mediocre programming? Leave a comment below!)

Patterns

Static Cling Pattern (SCP) – Static (global) methods and objects are often an expedient way to add some functionality to an application without spending any time worrying about where the “right” place for it to live might be. Using static methods for truly stateless operations that work only on the parameters passed in and do not have any other dependencies is fine, but problems arise when static methods instantiate objects or call other methods outside the scope of the passed in parameters. Once this has gone on for a while, it can be very difficult to introduce seams into the application to decouple its components from one another – it has begun to suffer from “static cling”.

Preferred Pattern(s)

Dependency Inversion Principle. Calls to static methods are direct dependencies that cannot be easily injected. Replace them with interfaces and calls to instance methods on injected objects.

More Reading

Static Methods are Death to Testability

Source

Bob Lee, (of Guice) - (via Nate Kohari)

Vestigial Structures Pattern (VSP) – When features are removed that span multiple tiers, the bits that are no longer used are left behind “just in case.” As in biology, Vestigial Structures are usually in a degenerate, atrophied, or rudimentary condition, and tend to be much more variable than similar parts. Although structures usually called "vestigial" are largely or entirely functionless, a vestigial structure may retain lesser functions or develop minor new ones.

Preferred Pattern(s)

Vestigial Structures are typically symptoms of a muddled architecture, where it is difficult to tell where one feature ends and another begins. See also Big Ball of Mud.

Source control. Delete it if it’s not used; if you end up needing it, pull it back out of source control.

Source

Richard Dingwall

Flags Over Objects (FOO) – Instead of using objects, polymorphism, or delegation, it’s much faster to just add a flag to a class and expose it. Then anywhere in the system that cares about that condition can simply add an if(foo.IsBar()) { … } clause to deal with this condition. Who needs inheritance?

Preferred Pattern(s)

Replace Conditional with Polymorphism, Refactoring, p255 (online)

Source

Curtis Cooley

The God Class (TGC) – Everybody knows that object-oriented programming is great because it lets us leverage and reuse classes to do all the work in our programs. And of course, nobody wants to have to look for the right class to do something, and the more classes you have, the less powerful each one is. It’s much better to just write (in Lord of the Rings voice here) one class to rule them all, a master class, capable of doing anything and everything your application might require. And who cares if it’s 5,000 lines of code?

Preferred Pattern(s)

Follow the Single Responsibility Principle (SRP), which states that a class should have only one reason to change. If your class has more than one responsibility, it should be split into several classes.

Source

Corey Coogan

Data Driven Architecture (DDA) – Professional developers know that building applications in layers or tiers is a best practice. The traditional approach is to have at least 3 such layers: UI, Business, and Data. When organized following the DDA pattern, the Business Layer will reference the Data Layer, and the UI Layer will reference the Business Layer. This is obvious, since clearly the Business Layer needs to be able to fetch and persist data, so it has to reference the Data Layer, and the UI layer needs to provide an interface to the Business Layer, and so must reference it. The benefit of this layered approach is that the Data Layer could, theoretically, be completely rewritten without any changes being made to the UI layer. Only the layer one step up would need to change (and it must change, since any interfaces used can’t belong to the Business Layer using this approach, because then the Data Layer would need to reference the Business Layer in order to implement such interfaces, creating a circular reference.

Preferred Pattern(s)

The application’s Business Layer should be its Core. It should not depend on anything if possible, and certainly not on Infrastructure like data access. All project dependencies should point to the Business Layer / Core, which should define the interfaces it requires its collaborators to implement. See Onion Architecture and Hexagonal Architecture.

The Dependency Inversion Principle can be valuable in achieving this reversal of project reference direction.

(do you have more patterns of mediocre programming? Leave a comment below!)

Practices

Found On Internet (FOI) – When faced with a problem, the quickest fix is often to search the Internet. This is a valuable and effective way to research solutions. The mediocre programmer’s approach to this, however, is to locate the first blog post or forum response that looks like it might be a fit to the problem at hand, and then to cut and paste the code, hack at it until it compiles, and run the application to see if it seems to work. If it does, move on to the next fire. If not, continue hacking until it does or go to the next item in the search results.

Preferred Practice(s)

Spike a solution using the found code and see if it works in a variety of scenarios.

Write some tests to confirm the behavior of the code does what it claims and works according to your expectations.

Review a variety of possible approaches to the problem and try to determine if you’re actually asking the right question before jumping on a possible solution.

Premature Optimization (PO) – Developers like to write code that runs as quickly as possible. Certainly, performance is one factor in nearly all software, but like all factors it must be weighed against other attributes like maintainability and velocity of feature delivery. The practice of optimizing code before one knows if a bottleneck exists in the current code, or if the actual production performance of the application will not be sufficient without such optimization, tends to result in waste. More often than not, the code being optimized is either good enough as is, or simply is not the bottleneck and thus any optimizations made to it will not impact the actual performance of the application.

Preferred Practice(s)

Get actual performance requirements from the customer and write tests to ensure that given scenarios comply with these performance requirements. Do not optimize unless these tests fail.

Collect actual data on the performance of the application and identify where the bottlenecks are. Spend your time eliminating the actual bottlenecks identified by your analysis, rather than guessing where the problem might be.

Copy-Paste-Compile (CPC) – Sometimes an application exhibits a bug or requires new functionality that has already been corrected elsewhere. All that needs done is to locate the correct section of code, copy it, and paste it into the section of code that requires this behavior. Make sure it still compiles and check it in. Another task complete!

Preferred Practice(s)

Get actual performance requirements from the customer and write tests to ensure that given scenarios comply with these performance requirements. Do not optimize unless these tests fail.

Collect actual data on the performance of the application and identify where the bottlenecks are. Spend your time eliminating the actual bottlenecks identified by your analysis, rather than guessing where the problem might be.

(whoa, did someone copy and paste the above and forget to update it?)

Follow Don’t Repeat Yourself and move logic that repeats into its own methods or objects. Fight duplication wherever you find it in your code.

Reinventing The Wheel (RTW) – Part of an application requires a little algorithm or utility that no doubt someone else has encountered before, but rather than using an existing framework class or well-known industry solution, the developer takes this as an opportunity to write the best XXX utility ever. It’s often more fun to write an algorithm or regular expression than to deliver yet another boring business form or report, but reinventing the wheel doesn’t add value. (also seen sometimes as Not Invented Here (NIH)).

Preferred Practice(s)

Know and use the framework. If you’re a .NET developer, the .NET framework has a ton of functionality in it and is usually a good first place to look.

Share knowledge within your organization. It’s likely someone else in your company already has solved this problem.

Quickly estimate the time it would take to build the functionality from scratch, and the cost of your time. See if a commercial tool could do the job for less, and see if management is willing to invest in such a tool.

Copy Folder Versioning(CFV) – Sometimes, changes to an application are big enough that they seem scary (even to a cowboy coder), so they decide to make a backup. Of course, there’s no source control software in use, so naturally the way to go is to make a copy of the folder containing the project (and, if you’re being extra professional, rename it from “Copy (2) of FooProject” to something more useful).

Preferred Practice(s)

Use Source Control! Please, if you’re still not using some kind of source control, start doing so today!

Seriously, use source control.

Source

Brendan Enrick helped come up with the TLA for this one.

Golden Hammer (GH) – The Golden Hammer refers to a particular language, framework, library, or tool with which you are familiar, and with which you’re certain you can solve any problem. When wielding the Golden Hammer, every obstacle looks like a nail, and any suggestions by teammates that other tools might be better-suited to the task at hand go unheard. (aka Silver Bullet, Magic Bullet)

Preferred Practice(s)

Learn or at least become familiar with a variety of languages, tools, and frameworks. Keep an open mind about how to approach problems as you build an application.

Source

Peter Hickman

Shiny Toy (ST) – The Shiny Toy is latest, coolest tool or technology available. Its potential is boundless. It can solve world hunger and bring about lasting peace in the Middle East. But it’s still beta so of course you need to spend some time learning it, since there’s no documentation for it yet and nobody you’ve heard of has released a live application running with it. You’re sure it will do everything the application needs, though, without too much extra effort… (this is related to the Golden Hammer practice, above, but taken to the opposite extreme. Sometimes you will find someone who thinks their Shiny Toy is a Golden Hammer, though!).

Preferred Practice(s)

Prefer existing and well-known tools and patterns to unproven ones for production use. Learn about the new on your own time, at conferences, for your blog, or if you’re sure it solves a real problem the application has, with a spike solution that can quickly demonstrate whether or not it will work.

Source

Kevin Babcock (renamed “Shiny Toy” by Steve Smith)

(do you have more practices of mediocre programming? Leave a comment below!)

Additional References

Anti-Patterns : Avoid Programming the Dark Side
Book: Agile Principles, Patterns, and Practices in C#
Ward Cunningham’s (large) Anti-Pattern Catalog

Why not Classic (Legacy) ASP?

ssmith — Thu, 08 Oct 2009 14:22:55 GMT

Yesterday I got the following email, which I thought raised some good points that I thought were worth addressing here in my blog in addition to the reply I sent directly.

Hi Steve,
I've been following your blog (as well as Rob C. and Scott H.) as I look into dipping my toes into MVC. I just read you "How I Got Started in Software Development" and your description of the joys of lightweight ASP development really hit home. So I have a perfect question for you.
I've been in the MIS/IS/IT/ICT field for, well, as long as it's taken me to collect all those acronyms. I've been doing lightweight webapp development since the late 90s, starting first in CDML, then ColdFusion, then classic ASP.
For the past few years, I've been developing some first-rate classic ASP webapps using a heavy does of AJAX (jQuery) for the UI interactivity. The problem is, nobody takes these webapps seriously, and I'm constantly taking flack for not moving to a "real" framework. And yet as I look at many of these frameworks, they seem like overkill in all the wrong ways. ASP.NET WebForms, in particular, makes me want to run out of the building screaming.
And yet, many clearly smart and experienced people like yourself are rallying behind these frameworks. What's up? What am I missing? What's the draw? And please don't spin that old "spaghetti code" yarn; as Rob writes, "Spaghetti is as spaghetti does".
Here's my thinking: HTTP is stateless. All you need the framework to do is talk to your database and render clean HTML. That's it. All UI interactivity should be handled on the browser in JavaScript, and all design should be handled in CSS. Classic ASP (with the help of jQuery) makes all this SO EASY. And there is nothing to prevent a good developer from writing clean spaghetti-free code with proper abstraction and separation of concerns.
I don't want to pretend that I'm a VS programmer working on a stateful desktop app. I want clean and efficient HTML, CSS, and JavaScript rendered to the browser. All these frameworks seem to get in the way of that while providing minimal benefit. So in five bullet points: WHAT AM I MISSING?
Thanks for taking the time to read this, and hopefully even to answer.
Sincerely,
another confused old-school ASP guy,

Here’s my emailed response:

Hi XXX,

Read these three books when you get a chance:

1) Working Effectively with Legacy Code by Michael Feathers

2) Agile Principles, Patterns, and Practices of Software Development in C# by Robert Martin and Micah Martin

3) Clean Code by Robert Martin

Now, to properly answer your question. The big reason why I won’t wish to return to ASP is the lack of ability to reuse and properly test code. As applications grow in size and complexity these two things are critical to retaining the ability to make major changes to the site’s design. Include files are a poor substitute for OO patterns of reuse. Also ASP uses COM which is a PITA in its own right, lacking xcopy deployment and forcing you into DLL hell that I don’t wish to return to (for instance, you can’t have two versions of a given component on the same machine, requiring separate instances of the OS just to run side-by-side versions of an app). Plus, talking to databases is something that should be done via an ORM tool if at all possible, and certainly not with lots of hand-written ADO plumbing code. Perhaps the ORM landscape has changed since I last did ASP 9 years ago but and there are numerous effective options, but if not, that alone will ham-string your productivity.

If you liked the clean separation that ASP afforded, you should like MVC views which will let you do your jQuery + Services approach easily but will also let your services run in .NET where they can take advantage of ORM tools, better performance, unit testing, and inheritance/polymorphism as well as new language features like LINQ and built-in platform features like caching that ASP lacked. Give it 3 months’ time on a real project and email me back and let me know what you think.

Thanks,

Steve

I’d also recommend some of the other books listed on my Favorite Developer Books post, which I’ll need to update soon to include the two Martin books I referenced in my response. Yes, you can write well-structured web applications in ASP. Yes, writing them with jQuery and a clean separation between UI and data and business logic is a good way to avoid spaghetti code. However, as the reader has found, support for this technology stack is all but gone, and there are many benefits to be had from moving to a modern stack like .NET (which itself is getting somewhat long in tooth, nearing 10 years of age). If he’s very enamored with the dynamic nature of ASP, Ruby is likely a good choice for him to check out as an alternative. But if he likes the Microsoft toolset and stack, then I’ll stick with my recommendation that he go to ASP.NET MVC, and avoid the VB6-like ASP.NET Web Forms model.

Another benefit I neglected to mention in using .NET over ASP is the ability to debug the code. Honestly I don’t use the debugger that often (tests > debugger usually) but when I do need it it’s extremely valuable. And I can say that on the rare occasions when I’ve had to work with ASP code in the last 9 years or so, both my own and clients, it’s been universally unpleasant compared to ASP.NET MVC, which has been a joy across the board. However, I wouldn’t say that any of the ASP apps were written as well as the author of the email writes his.

How many other readers are still using ASP for new applications today? Are you trying to incorporate modern advances like ORM tools, jQuery, web services, etc. or do you build them the same way people built them 10 years ago? What are the biggest pain points you face?

SQL Divide By Zero Error Solved

ssmith — Mon, 28 Sep 2009 17:07:00 GMT

Recently a report that had been running fine for months began failing with a Divide By Zero exception. This report is a summary of a lot of data and is contained in a stored procedure which uses quite a few table variables to do its job. Here’s part of it:

declare @AccountManagerRevenueByFormat table

(FormatID int, AccountManagerRevenue money)

insert into @AccountManagerRevenueByFormat

select CreativeFormatID, sum(AmountEarned)

from lq_AccountManagerRevenueDetail amr

    inner join lq_Placement p on amr.PlacementID = p.ID

where DateRecorded between @StartDate and @EndDate

group by CreativeFormatID

Ultimately, after a bunch of such tables are created, all of the results are pulled out using a final select that joins together each of the table level variables. One of the columns displayed is a CPM value, or “cost per thousand,” which is how online ad impressions are typically priced (this report was part of AdSignia, Lake Quincy Media’s ad network management platform). In order to calculate CPM, the query included something like this:

isnull( isnull(Revenue,0) / ( nullif(Impressions,0) / 1000),0) [CPM],

The purpose of the various isnull and nullif functions is to guard against divide by zero exceptions and to ensure that any lack of results is shown as zero. For instance, the following returns 0 as expected:

select isnull( isnull(1,0) / ( nullif(0,0) / 1000),0) [CPM]

And when impressions are 1000 and revenue is 1, the CPM of 1 is returned as expected:

select isnull( isnull(1,0) / ( nullif(1000,0) / 1000),0) [CPM]

However, despite all of these guards, one thing can still go wrong. Do you see it?

…

The problem has to do with the fact that Impressions are an integer field, so by default the division is going to drop any remainder. Thus, the following doesn’t evaluate to slightly more than 1, but rather results in a divide by zero error:

select isnull( isnull(1,0) / ( nullif(999,0) / 1000),0) [CPM]

To counteract this, the Impressions field needs to be converted to a numeric or floating point data type before being divided, like so:

select isnull( isnull(1,0) / ( nullif(convert(float,999),0) / 1000),0) [CPM]

which results in: 1.001001001001.

Returning to the original snippet, it looks like this:

isnull( isnull(Revenue,0) / ( nullif(CONVERT(float,Impressions),0) / 1000),0) [CPM],