Folks, this isn’t hard. In fact, both of these things are so simple I simply call it “using the programming language”.

Let’s look at dependency injection.

See the reader variable? That's a dependency. You have to have it in there to do fun things later on. But we have to create it ourselves, which is one more thing that we have to do in our class constructor. In reality we also have to populate the DataTable. So what if we make the reader variable constructor parameter so that another class can do the work of creating the DataTable and the reader?

There, that's better. Now our class doesn't have to worry about creating the reader and the DataTable. This, in a nutshell, is dependency injection. It's not very complicated is it? We've made our class construction a little simpler and if we want to unit test this, we don't have to do any complicated mocking, we can just new up our own DataTableReader instance and populate it with whatever test data we want. If you run into any funny looking data in the DoStuffWithTheReader method, you know that you don't have to look in this class at all to see where the funny data is coming from, only in whatever method is creating this class and passing in the DataTableReader.

Now is there anyone who thinks that developers on their team would have trouble understanding passing in a parameter? Should they really be a developer if they do?

Ok, so let's look at inversion of control. The original definition of inversion of control I read was by Martin Fowler:

There's a big difference now in the flow of control between these programs - in particular the control of when the process_name and process_quest methods are called. In the command line form I control when these methods are called, but in the window example I don't. Instead I hand control over to the windowing system (with the Tk.mainloop command). It then decides when to call my methods, based on the bindings I made when creating the form. The control is inverted - it calls me rather me calling the framework. This phenomenon is Inversion of Control (also known as the Hollywood Principle - "Don't call us, we'll call you").

If you look at the previous example, you'll see that we have already inverted the control a bit just by using dependency injection. But the class still has a degree of control over WHAT concrete object is created, in this case a DataTableReader. What if we need to switch over to a SqlDataReader or an OleDbDataReader? Well, we could create three other classes that all take the specific type of data reader we might want to use. But that's a bad idea, you end up with the same logic spread all over the place. Instead we can use the IDataReader interface that all three classes implement.

Now our class not only doesn't have to worry about creating the DataTableReader, it doesn't even really care if it gets a DataTableReader at all. All it cares about is that the reader is referencing something that implements the IDataReader interface. This is a type of inversion of control. Most of the time people get confused between inversion of control and a container that enables inversion of control and dependency injection (like Ninject, StructureMap or Unity). You don't have to use a container to utilize these two techniques, it just makes it a little easier.

update:Also check out this great post "It’s all about the delivery"

update: I mistakingly thought it was hard to do D.I. in Python due to the inheritance mechanism in Python. Turns out, it's just as easy.

At some point that very simple manifesto turned into a set of “must have” tools, technologies, methodologies, and processes. Which I think defeats the purpose. You have to look at each tool and methodology and think “how does this help me build better software for my user?”

There is a very important paragraph at the bottom.

That is, while there is value in the items on the right, we value the items on the left more.

 

So let’s go through each line.

Individuals and interactions over processes and tools

These “story cards” are one way to increase the communication between individuals during their interactions. Gigantic requirement specifications don’t do anyone except other software engineers any good. The daily standup meeting that a lot of agile practioners adopt is one way to keep the team up to date and find out about possible problems as soon as possible.

Working software over comprehensive documentation

No matter what, you’d rather have an application that meets the users needs and helps them get stuff done easier than they could before you wrote their application. Chances are, if you need to write a lot of documentation, you’ll have to maintain it also. Most of the time documentation is only for other developers that will have to come along behind you and change the software to meet new user needs. What better way to communicate what the software is supposed to do than a bunch of executable code, e.g. unit/scenario/integration tests, that ensures the application does what it says it can do?

Customer collaboration over contract negotiation

By adopting techniques and tools that allow you to change direction quickly and confidently, you don’t need to “lock down requirements” before you start developing. If the requirements change, you’re code base and tools are flexible enough to handle the change. That’s where principles like S.O.L.I.D. come into play, they make your code base more flexible and responsive to change.

Responding to change over following a plan

How can you ensure that, as you change your software to respond to changes in the business or requirements, your software doesn’t break? Automated testing is one method. Continuous integration builds are another. These tools aren’t used by agile practitioners  because they want to feel cool, they are used to help them better respond to change. The story cards and backlog also help. You can re-prioritize your backlog to meet the businesses current needs. Since your iterations are short, and your stories are small, the overall impact to changing direction is minimized.

The fact that software development is complex, and that there is a lot of new things to learn. That there is ALWAYS something new to learn about software development, has NOTHING to do with agile practices. You’d have exactly the same problem keeping up if you practice agile or not. You might have an internal process where you work that allows you to respond to change quickly, it may even involve Microsoft Access!

There was a great post that Miguel De Icaza linked to on Twitter. “Every Ideology is Right”

What I mean by "right" is that is each one is responding to a genuine problem within human existence. And their prescriptions for how to deal with that problem "work," at least in the short term in limited circumstances.

Obviously, there are unforeseen consequences because each ideology looks at a limited aspect of reality, and then tries to apply its solution for that part of reality to ALL of reality. The important thing is to try to have your ideology "look" at as much of reality as possible.

I say this because it seems to be the way the Apple software ecosystem works. There are a few applications, written by developers who have been working on the Apple platform for a great number of years, that are constantly recommended and very successful.

Erich Gamma: Yes, and it is funny that you mention the iPhone. The iPhone SDK is based on the NeXTStep object-oriented frameworks like the AppKit. It already existed when we wrote Design Patterns 15 years ago and was one source of inspiration. We actually refer to this framework in several of our patterns: Adapter, Bridge, Proxy, and Chain of Responsibility.

Richard: Which is a great example of the enduring nature of good design, and how it survives different technical manifestations.

Emphasis mine.

In the Microsoft developer community, we are just now getting around to implementing patterns like MVC, Adapter, and Observer. People still argue over whether or not the MVC pattern is “necessary” to build a “working application”.

I guess it depends on whether or not you like good design?

Compare the two examples in this post. One uses RhinoMocks to create a stub of IDataReader and the other uses the DataTableReader to create a stub for the test. Which example is simpler and has less chance to fail due to the stub?

 http://www.lazycoder.com/weblog/2008/12/12/mocking-idatareader-using-rhinomocks-35/

Using RhinoMocks

Using DataTableReader

Stubs/Fakes allow me more control over HOW the test fails and results in a test/fixture that is easier to read. I'm not saying that mocks aren't useful in certain situations, but I would favor a stub over a mock IMO, your test should only fail because of the code it is testing, not because of a mock.

Although it is fun to say "Mock ME? No mock YOU!".

update: I forgot to link to Rob's post that inspired this post. "Using Dependency Injection and Mocking For Testability"

update to the update: Jeremy Miller and Nikola Malovic both pointed out that I'm using the terminology incorrectly. It turns out I don't specifically hate mocks themselves, I dislike use dynamic mocking/stubbing frameworks due to the extra dependency they introduce into my tests. Thanks for the corrections. Back to reading Fowler for me!

1. It requires XCode.  - I’m not sure if they can get around this one. It seems like they should be able to. All XCode does is call GCC and compile the code. My guess is that it has to do with the licensing of the iPhone SDK and/or the iPhone libraries that you can’t distribute. If you could bundle the iPhone headers, it seems to me that you could compile an iPhone app on any platform that supports GCC. DOH! As Miguel reminds me in the comments, it doesn't use XCode but the iPhone simulator is only available on Intel Macs. (1)
2. It costs 400 frickin’ dollars. – So now, not only do you have to buy a Mac, pay Apple $99 per year to get in the App store (which is no guarantee) but if you want to use MonoTouch you have to pay $399 U.S.

So what you have to ask your self is: Is learning Objective-C something that I really can’t/won’t do to become an iPhone developer?

There are a lot of benefits to developing for the iPhone using MonoTouch. Access to most of the .NET library. LINQ is available, WCF. Miguel DeIcaza has a good explanation for why Monotouch costs $400, which he'll talk about in an upcoming episode of Herding Code. But I think that the price is going to really slow MonoTouch adoption.

(1) That's what I get for writing a blog post ahead of time and not reviewing it before it's scheduled to post.

A lot of the "bugs" revolve around "fit and polish" issues. Making sure the font and wording is correct in all locations. Making sure the application looks and behaves the same across all platforms,browsers in the case of web applications. Most all requirements documents or stories include a note for the QA department to perform these checks well in advance of the final launch, yet these bugs always seem to come up and they usually are not regression bugs.

The places that follow an iterative cycle I've found don't really deploy after each iteration to any meaningful customers. They are all still tied to the "big launch". I think that getting the product into the hands of people who ACTUALLY care about it, rather than the ones that are just concerned about the launch, is crucial to delivering a high-quality product.

I'm wondering if the traditional QA department is a relic that we need to get rid of? If we move all of the testing/bug finding to the interation and fix them immediately, isn't QA relegated to mainly verifying bugs reported by customers/users?

So the question is: How do we get QA more involved in the process?

The money lines in the source are the following:

These two lines tell the browser to load the MS AJAX scripts from the CDN. There are some security concerns around the fact that the files are served from the microsoft.com domain. Both Google and Yahoo serve there files from a separate, non-cookied domain (googleapis.com and yahooapis.com respectively). Hopefully, these fears will be unfounded.

On a side note, it is surprisingly easy to use the Bing API if you are familiar with script tag injection. The easiest way is to put an empty script tag in your page.

And then just create your Bing URL and set the script elements src attribute to the URL you created.

The free world is proud to announce an old program for startups looking to do web development. When you sign up for the WebOSSFlame program, you get the following:

1. Free, unlimited licenses to the Debian or SuSE server platform
2. Free, unlimited licenses to the MySQL AND PostgreSQL database servers
3. Free, unlimited usage of either the Ruby, Python, or PHP languages.
4. Free, unlimited licenses to ALL of the following IDEs: Eclipse, Vim, Aptana (1)
5. Free, unlimited licenses to ALL of the following graphics programs: Gimp, InkScape
6. Free, unlimited licenses to the FileZilla FTP program for deploying your Web application.

Aw heck, you know what? We’ll just throw in free, unlimited licenses to any piece of software listed here.

Why start with a spark when you can start your fire with a flame?(3)

(1) – EMACS not included, why do that to yourself? Really?(2)

(2) – Just kidding EMACS users.

(3) Ok, that’s a stretch.