Simplicity Follows Complexity

Stop thinking Agile, and start thinking agile

2011-09-13T18:56:00.000-07:00

There's been plenty of sentiment about Agile (capital A as my buddy Ed pointed out to me) being dead or that it's a failure or that it's in some state of decay. In a sense, I completely understand why people would think that. It may also be some of what is holding back the free thinking in the process of software development. There are few big, new ideas (outside of lean but then that's not new) that are really providing direction for the software development process.

From my point of view, this wound is self inflicted. Agile has become the hammer to nail all process problems. It was championed and supported by some really smart guys in the software dev space. Popularity grew, Agile become all the rage and, as all fads in the space, it became a personal point of pride to declare that you or your company "went Agile". There were books written about it that contained all the activities and routines you must partake in in order to be considered Agile. Training classes and certifications inevitably popped up that claimed that with 3 days of training you too could be a scrum master and Agile wizard. Before anyone knew it, Agile was a defined creature with a strict set of rules (standup meetings in the AM, planning poker, TDD, pair programming, retrospectives, etc.). It was no longer the organic process that it was supposed to be.

I certainly wasn't there in the early days of Agile but my company did "go Agile" almost 3 years ago. With it, I've found some fantastic practices that are now part of my software development six-demon bag and I've chronicled many of them on this blog. It's truly been a great addition to my craft and I would certainly advocate others to try it as well. GO AGILE! You may thank me later.

So what's the problem here? I just said Agile prevents free thinking but then I advocate that you try it. The problem isn't the Agile movement, it's how it is adopted. People want to add it to their process without appreciating where it came from and why your company should care to use it. It's the same behavior I allude to in my "The Goal" entry. Blind adoption of the Agile process isn't going to be to your benefit.

When I talk to people about a good software development practice, I no longer think in terms of the canonical Agile. Every company, every product, every team have their own unique environment and set of problems. It would be a mistake to not take those things into account before you start throwing the Agile bible at everyone. My goal is to streamline the process and use the best tools I can to reach the coveted hyper productivity. Agile is comprised of many different practices and procedures. Take what you need from it and recognize what works best for you.

Remember, Agile wasn't created from thin air. It was coined by a bunch of guys that saw waste, friction and deficiencies in the process. This is not uncommon to any of us. These are things we all see in our days, isn't it? "Wow, that meeting was useless." "The number of regressions grows on each release!" "We build what they ask for but then they never like it!" "These manual deployments take hours and they're error prone!"

LISTEN to those thoughts and react to them. As a developer I know how easy it is to identify what is going wrong and grouse about it. It feels great to vent. If I asked you what pissed you off, you'd ramble about it for hours, eventually repeating yourself but then you'd dive back into it anyways because you're that passionate about it. Take that energy and think of how you would fix things. If that meeting was useless, how would you make it better? Should you even have been there? Were there too many people talking at once? Was there one loudmouth that dominated the whole discussion?

Don't accept this reality. Change it. Make it better. Be organic in your process. Evolve. Mature. You don't need a certification to understand where things are going wrong for you. Fix it. You have manual builds today. Automate them tomorrow. You have 6 month projects with unhappy customers. Decompose them into 1 month deliverables to get quicker feedback. You have too many bugs. Increase test coverage and improve your QA. You have a schizophrenic product organization that pulls you in 8 directions? Stop the assembly line and demand consensus and priority.

That's all Agile ever was.

...but before you go, buy a book, ask questions on forums and learn about all the wonderful practices that fall under the Agile umbrella because we've learned a lot in the last decade about good processes.

From a Java/C# world to Ruby's: Writing modular code

2011-07-31T18:28:00.000-07:00

For the past handful of months I've been dabbling in Rails in my free time to play with some projects. It's a fun platform for creating applications and I (as has been mentioned) dig Ruby. I'm starting to actually build up enough code to warrant a little more discipline than what I've had so far. For the most part, I've been plowing through just trying to experience all the tools and tricks the platform has to offer. I couldn't really be effective otherwise if I hadn't given myself any time to play in the sandbox.

One thing I'm trying to learn is how to modularize code in Ruby. How and where do you draw lines of responsibilities? Where should code live? Should I use a module or should I use a class? There hasn't been a straight forward answer. Ruby being dynamic, open classes and being able to intercept/modify just about any behavior in the system...it feels like my first year away at college (well, not really but you catch my drift). While it's a lot of fun, you have to make sure you don't run wild with your freedoms. There's a limit and you have to govern yourself.

Again, where are the lines drawn? What are the right things to do? It's not apparent. Look at models as they're known in Rails. Models use the Active Record pattern where each instance constitutes a record in a persistent store. So what is the typical Rails model responsible for? Reading and writing itself from a persistent store at the least (along with any of its child models). This alone will make members of the CQRS Illuminati grow faint. But it doesn't stop there. Also, you need to perform your validation there which makes sense for any stateful, data-driven creature to do.

At first, I let everything pile into my models. If I had 3 ways I wanted to query things from the DB? Oh, hey, I need to query my associations too, what should I do with all that logic? Put it in the model. If I had extended validations dependent on certain conditions? It undoubtedly went in the model. If I add an authentication framework that needed to decorate the client classes? Hey, I'll just add it to the model!

It never felt right and as I piled more functionality on, things became especially itchy. Instead of trying to foresee how this would all pan out and try to apply some half-brained pattern of my own, I just went for it and made things a sloppy mess. I really wanted to see what the wrong way to do things was so then the answer would be more apparent. Just like my early days when I realized how tests benefited my code, I could learn from it. Why? Because Ruby isn't Java or C# and I'm a Ruby part-timer. I've seen and read about trying to apply patterns from either of those languages that is inappropriate. I decided to let mother nature dictate how I should proceed.

In the case of the rogue models, I found what makes me most comfortable. First, anything related to the data and validation of a model stays in its class definition. Second, any associations defined stay in the model's class definition. Third, anything that demonstrates how that model behaves in its domain should stick around (if possible). I want to be able to see and quickly digest what the model is and what it's related to.

Last, everything else, provided that its a significant amount of code, is placed into modules. Modules allow me to create meaningful, cohesive groups of methods and constants. For example, the code to query the DB (in any number of ways) is pulled out and placed in some sort of data access module. Modules, while not being the same as classes, act very much like a class in most senses. What I don't have a feel for is how many includes is too many includes. The models get this very facade-like feeling. They do a lot. It's still something I haven't quite gotten used to yet.

So, the short of the long, modules are nifty and I can draw parallels with how I used interfaces (and ultimately their implementations) in Java/C#. It's the same song, just a different dance. Use them to decompose the larger objects and group logically related functionality.

MongoDB repair on bad shutdown

2011-07-26T18:23:00.000-07:00

I've been working on a little side project and I've been using MongoDB. One insanely annoying thing I've run into a couple times is if Mongo doesn't shutdown cleanly then you have to repair it. The next time you try to start it up you get errors. You'd hope that these things would happen automagically but oh well...I'm just starting to learn it so I may be missing out on the larger reason.

You may end up seeing something in the console like this when you try to connect to your local server,

:~$ mongo
MongoDB shell version: 1.8.2
connecting to: test
Tue Jul 26 20:45:17 Error: couldn't connect to server 127.0.0.1 shell/mongo.js:79
exception: connect failed

or this (this one was just me putzing around trying to get it going),

:~$ sudo mongod
mongod --help for help and startup options
Tue Jul 26 20:47:35 [initandlisten] MongoDB starting : pid=3358 port=27017 dbpath=/data/db/ 32-bit
** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
** see http://blog.mongodb.org/post/137788967/32-bit-limitations
** with --dur, the limit is lower
Tue Jul 26 20:47:35 [initandlisten] db version v1.8.2, pdfile version 4.5
Tue Jul 26 20:47:35 [initandlisten] git version: 433bbaa14aaba6860da15bd4de8edf600f56501b
Tue Jul 26 20:47:35 [initandlisten] build sys info: Linux bs-linux32.10gen.cc 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:39:36 EST 2008 i686 BOOST_LIB_VERSION=1_37
Tue Jul 26 20:47:35 [initandlisten] exception in initAndListen std::exception: dbpath (/data/db/) does not exist, terminating
Tue Jul 26 20:47:35 dbexit:
Tue Jul 26 20:47:35 [initandlisten] shutdown: going to close listening sockets...
Tue Jul 26 20:47:35 [initandlisten] shutdown: going to flush diaglog...
Tue Jul 26 20:47:35 [initandlisten] shutdown: going to close sockets...
Tue Jul 26 20:47:35 [initandlisten] shutdown: waiting for fs preallocator...
Tue Jul 26 20:47:35 [initandlisten] shutdown: closing all files...
Tue Jul 26 20:47:35 closeAllFiles() finished
Tue Jul 26 20:47:35 dbexit: really exiting now

I found the answer in the comments of this blog. Run the following commands and all will be well,

sudo rm /var/lib/mongodb/mongod.lock
sudo chown -R mongodb:mongodb /var/lib/mongodb/
sudo -u mongodb mongod -f /etc/mongodb.conf --repair
sudo service mongodb start

HUZZAH!

The Goal

2011-06-20T21:15:00.000-07:00

The only right way to write code is to use TDD!

Scrum should only take 5 minutes!!

You should ALWAYS use DDD to develop your model!!!

NOSQL is the only way! Down with SQL!

That's the sentiment you can find in a lot of arguments between developers. It's too black and white, too absolute. The issue is that the focus leaves the goal. It artificially limits the solutions you can come up with.

In the case of TDD, you can most certainly write code before tests. What do all software development practices boil down to? Building easily maintained software. It isn't about creating beautiful code, it isn't about designing a family of classes, it isn't about creating a model that sounds like a spoken language. Building easily maintained software can be done in any number of ways. Something like TDD helps to reinforce proven practices for maintainable software but it's not the only solution. I'm a TDD practitioner but you know what? I've got no beef with writing code first. You don't always need to TDD.

In the case of agile development, for anyone adopting agile, there's a LOT of focus on the religious practices that come with it. You will, for a long time, follow these practices blindly, even when they don't improve your process and become a nuisance. The answer is that not all practices may make sense. Take a step back and look at what they are intending to achieve. A 5 minute scrum doesn't mean you're doing a good scrum. You may find that, for your group, have something like 8-10 minutes is more comfortable. Don't hate yourself because you're not following it to a T. You've done exactly what these practices were intended to do; maximize your productivity. That's the goal of this whole thing.

In the case of NOSQL, it's a poor musician to blame his instrument. People finally realized that they were using SQL as the hammer to nail everyone's persistence problems. With the host of new applications we build, SQL isn't always the answer. Maybe it's a document database. Maybe it's a key-value store. Maybe you need something that natively supports object graphs. Instead of recognizing the fact that applications and their persistence mechanisms come in all shapes and sizes, the sentiment has become that SQL is the scourge of software development. We have ourselves to blame on that one, trying to force an object model into a system that poorly represented it. Somehow this is SQLs fault? We stopped questioning why we did the things we did. Take a step back, ask yourself what you're really trying to do and then it becomes a no-brainer. That's what gave birth to all these new forms of persistence.

For some, it may take a while to see it but you'll get there. Don't fall into the trap of blindly doing things without re-evaluating constantly. There's more than one way to do something and you shouldn't let software purity or zealotry prevent you from considering it. It leads to the innovations that improve our lives as developers and the people who use our software.

Thoughts on the Test Pyramid

2011-03-08T07:44:00.000-08:00

About a half year ago, one of my coworkers sparked a discussion on the test pyramid. Specifically, he referenced a link and asked our thoughts on it. Since I like to geek out, I had to respond. I actually spent some time creating what I thought was a reasonable analogy so I figured I'd share it. I'm also offering this now as I have another post I really want to discuss in regards to the boundaries in testing between a QA group and developers. Is there one? Should there be one? How do we deal with test overlap? It's something I've been mulling around and I need to think out loud.

So, here's how the original thread went,

S:

Some interesting posts on testing pyramids and automation. I'm a proponent of using this pyramid metaphor for organizing our test strategy. Thoughts?
http://benhutchison.wordpress.com/2008/03/20/automated-testing-2-the-test-pyramid/
http://blog.mountaingoatsoftware.com/the-forgotten-layer-of-the-test-automation-pyramid

Me:

It's an effective way to describe a proven testing strategy. The simple law here is that tests are all about feedback and how valuable that feedback is. The value is tied directly to their maintenance cost. If you look at it this way, you stop thinking in terms of layers. For example, brittle unit tests are high cost and thus less valuable than verifiable, repeatable, solid unit tests. This is the mindset all test implementers need to have in order to build the best test suite.

In terms of the test pyramid, we can certainly assume that there are responsibly written tests. What's illustrated there is how the test maintenance cost rises in parallel to the growing level of component interaction and complexity. The more complex the interactions in the test then the more likely it is to break. Broken tests need to be maintained. Tests of complex interactions take longer to repair.

At each level of the pyramid, we have a set budget on how much we can spend on maintenance. Unit tests are cheap therefore we buy lots. Integration tests are a little more expensive so we can't afford as much. Functional tests carry the heaviest price tag so we just buy a handful.

Tests at all layers are valuable and provide a distinctly different type of feedback. That's why it isn't a good idea to simply forego testing a layer at all. Having a codebase with only unit tests doesn't prove that the system actually runs.

There are a few more factors in what defines the value of a test but I'm glossing over that by calling them "responsible" tests. If you had two integration tests that exercised the same grouping of components then you should probably entertain getting rid of one. We want clean, clear feedback and having multiple test breaks for a single issue will obscure the root of the problem. Given that we're trying to be as frugal as possible we'd probably identify tests like that early on.

The one caveat/tangent I might mention is that the pyramid metaphor (and how I commonly see it described) doesn't account for things like capacity testing; the throughput of the application, the transactions/second they can service, their memory footprint and resource consumption and other issues that can potentially derail a release.

Application deployment is an implicit test to make sure that you can actually install and run the application. There would never be an NUnit test for that but their is value in knowing that the application can be reliably deployed. We should try doing that earlier to get that feedback when the information is more fresh in our minds.

...

And that was about it. I had a few more words but they dealt with the internals of our specific situation. Not worth repeating for obvious reasons.

On the fence about Java, open source is the shiznit and .NET build automation sucks

2011-02-27T14:26:00.000-08:00

I moved to a new team more than half a year ago and at first things were rough. The team itself was fine but I was giving up my precious C# for Java and I was entering a whole universe of new software. My technology stack changed from Microsoft branded IDEs to that of the open source crowd. I was out of my element but I thought, "Hey, time to try something new!".

Let's just get this out of the way; as a language, Java is not aging well. Certainly not in comparison to C# which is getting updated more frequently with a lot better language niceties. When .NET rev'ed itself up to v3 it brought along lambdas and extension methods which makes for some really nice, clean code. This is noticeably absent from Java. Even the simple act of passing around functions is no where to be seen in Java. I have to create a full-blown class that implements one method. It feels like Java is more worried about being pulled from the holy scripture of Design Patterns than it is about making a language that is enjoyable. Ah, you can pass an anonymous class but it's still waaaay too verbose.

But that's the thing with Java. It seems like it tries to be as horrifically verbose as possible. One of the common Java practices is to mark everything final. You see final everywhere. Final member variables, final arguments, final variable declaration, final classes, final final final. You'd wish that they marked things NON-final because there are far fewer instances of that. Better yet, choose a language where variables are immutable by default. You end up with a lot of chatty code, which is unfortunate since it's already a static language...you don't want to be known for pushing the envelope on verbosity. Here's my favorite quote about it,

Whenever I write code in Java I feel like I'm filling out endless forms in triplicate.

-- Joe Marshall

I can forgive these sins because I've finally been exposed to open source software. Software built by the community. For us, by us. Open source software has a distinctly different flavor to Microsoft software. Tools load faster. There's less fluff. It's more of what you need and less of what you don't need. If something has a bug, it's fixed quickly and you can get the patch as soon as someone posts it. You don't have to live with the same crap for years because it just doesn't show up as a priority on Microsoft's radar. You know, like the "add reference dialog" that has been the bane of our existence since early 2000 that they only recently addressed (sort of).

I was introduced to Maven which is build and dependency management for Java. For anyone who cares about build automation (and that had better be ALL of you), Maven beats the ever living snot out of anything you can find in .NET. .NET's build automation story is absolutely abysmal in comparison. I know some people think Maven is kinda crappy but it's still light years beyond what the .NET crowd has going on. The only thing that seems to be standardized in .NET is using NAnt (and possibly but incredibly doubtfully, Albacore/Rake). Here's a simple scenario that is more difficult to do in .NET,

Gather dependencies
Compile code
Run Unit tests
Run Integration tests
Deploy the application
Run smoke tests

Step 1 was always something that was custom to whatever shop you worked at. This is where someone had to copy third party libraries somewhere your build process could access them (probably a lame network share). This is a problem that has been solved for years with things like the Maven repository in Java and Gems repository in Ruby. Maven just does this out of the box. When you run a build, it will retrieve your dependencies prior to compilation. There's a project NuGet for .NET that is supposed to alleviate this problem and I admit I haven't tried using it. I can only hope it gets integrated into another project like Maven for the .NET community.

Steps 2-3 are straight forward (and usually) don't introduce too much pain. Step 4 usually requires partially constructing the environment of your application which includes databases, web applications and other such "heavy" dependencies. This is where the open source community trounces .NET. When I tried automating testing of web applications it required that IIS be installed, that I had the correct users/authentication, that I figure out the mystery of the Web Deploy tools that are anything but intuitive and extremely prejudiced to IIS 6, blah blah blah. It was a process that required massive manual intervention and implementation. It's brittle and no company wants to pay for the time it would take to implement that.

With Maven, I just reference the Tomcat web server plugin, tell it to start a web application on the fly, install it, and run it. It's disgustingly simple to do and it's actually running a very good analog of my production environment. You don't get Tomcat Home Edition or Tomcat Developer Edition or some other lame neutered version of the web server product (I'm looking at you Cassini web server). You get the real deal and you get it with only a handful of XML declarations.

Step 5 in .NET has no real public support or method. It sucks. Using the same Maven Tomcat plugin I mentioned above, deploying your web application is a breeze.

I don't think I care to carry on describing how immature the state of build automation is in .NET. Suffice it to say, we .NET devs should stop waiting for Microsoft to make it for us. It's a glacial development. There's too much to be learned from the open source software projects. First lesson, not all .NET projects need to be monetized. Yes, you can be compensated for your hard work but there are tons of opportunities to do that outside of selling a product. Embrace your community, have them push the feature list. We can go from there.

So while I get a lot better developer tools in open source software, it doesn't come without a price. I'm not impressed with documentation and it's difficult to find the answers you need. Unless you subscribe to their IRC channel or mailing list, you aren't going to find help from available online content. Sure, it can get you going but once the rubber meets the road you will inevitably hit an issue that doesn't seem to be covered in anything you can find with conventional Google searches. I've come to loathe all the websites that index mailing lists, jira and java documentation only to provide you with advertisement-laden dead ends. You'll have to subscribe to a mailing list, post your question and pray that somebody wants to respond to a question they've probably seen a dozen times before.

The open source world isn't perfect but I love the tooling and the low barrier for entry. If you've been living in the .NET bubble for some time, take a break and try something new. The worst case is that you recognize ways to make your life easier.

It was a busy summer

2010-10-03T07:50:00.000-07:00

This last summer I spent time getting embedded in a new group at work. It's been a blast because the group is really enthusiastic about agile development and adopting new and efficient practices. I've had a chance to practice a lot of the things I've been doing and studying in my free time including acceptance test driven development, NHibernate, ASP.NET MVC 2 and lots more BDD.

There's nothing sweeter than having a greenfield project and I was able to get my hands on one. I was tasked with building an internal dashboard for some of our back end (Windows) services. I'm still in .NET land and we're primarily a Microsoft shop so I used a pretty small but flexible stack,

For testing, I tried out doing acceptance test driven development with SpecFlow which is the .NET analog to Ruby's Cucumber. My unit/integration testing framework of choice is still MSpec.

I took this experience and made a presentation to the company about BDD. For anyone that's looked around the web at BDD presentations you won't be incredibly surprised by the content. Lots of the same points are made and I even borrowed the excellent high gear/low gear analogy of ATDD I found in someone else's presentation (I can't remember who :-(...sorry, uncredited person, whomever you are). You can download it from my dropbox here.

I know I promised an example of doing ATDD and I'd really like to do it. Now that work is semi-calm I can try to whip something up. There are tons of other things I want to talk about like the Java codebase I'm working in now, when NOT to unit test, the current .NET craze around CQRS, and other interesting topics swimming around in my head.

BDD: Just tell me what the eff it is!

2010-06-27T13:37:00.000-07:00

Here's my big problem with BDD...on first blush the only thing you can see of it are the tools used in it for testing and a bunch of acronyms and buzzwords. You get all these testing frameworks to try to write natural language tests geared to output something your stakeholder can both read and understand. For a long time, the question still stood for me; what is BDD? How do you do BDD? Sure, my tests were now human readable but it still hadn't added up.

For those that don't understand what BDD is and even those that do, I want to walk you through what I've learned over the last year. I want to give you an alternative narrative to the stuffy version on wikipedia and the dated top ranked Google results which offer breadcrumbs to understanding but didn't give me the clarity I was looking for.

Let's look at the two line summary Dan North gave last year,

BDD is a second-generation, outside-in, pull- based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters.

Get it? Neither did I when I first read it. After doing a lot of research, investigation and experimentation I finally get it. Now that I do, that two line definition is an excellent summary. There's a lot of information packed into those sentences. We won't try to drill into all of that here. Let's start with the simple building blocks of the BDD process.

It starts with a story

BDD is firmly rooted in the agile universe. It relies on a lot of the mechanisms and practices you find in agile processes. The first and most important is the practice of capturing user requirements as stories. I'm not going to spend time in this post defining what a story is but let's just use an example we can refer to.

In order to build readership of the blog
As a blog reader
I want to leave comments

This is the first step in BDD, the first tangible piece of the process. Your stakeholder(s) and your agile group develop stories.

Create examples/scenarios

You have your story. Take that story and imagine (realistic) scenarios of it in practice. Who it is that generates the scenarios may be multiple people. Your scenarios are your acceptance criteria. They tell you when the story is done.

Here are some samples of scenarios based on the above story. (Remember, for this story, we're in the context of a reader of the blog and their desire to leave comments.) The scenarios are written using the Given-When-Then format for describing scenarios.

Given a blog entry
When I write a comment
And I submit the comment
Then I should see my comment under the blog post

Given a blog entry
And the blog entry is no longer accepting comments
When I view the blog entry
Then I should not be allowed to write a comment

You can see how there would be numerous scenarios and contexts of users of your application. When generating your scenarios, you must take them all into account.

You're just about to write code but...AUTOMATION!

Any good development environment should be as automated as (in)humanly as possible. With a few quick commands/scripts you should be able to build your app, build your DB (if you have one), execute tests, deploy the app, and run it. The more you have to do manually the harder this whole thing is.

Also, you should be able to run this in isolation on your workstation, if possible. If your app is sharing a DB with 5 other workstations in your department, chances are you're going to have collisions. You won't be able to make predictable tests and you'll be stepping on each others' toes.

When you write your code you want to be continuously running tests. This should be a push-button activity that does not derail you for several minutes. If it is then analyze what it is that you're doing and see if you can find ways to streamline it. Either through tooling or through eliminating deficiencies in your testing strategy.

Outside-in: It's time to TDD

In BDD, we do things outside-in. Meaning, you start at the level of the user's interaction with your application and then you build downwards. It's a huge shift for a lot of people. I haven't been doing it for very long but it's not a huge departure if you were already doing TDD. Most of my difficulty was just learning how to automate UI interactions.

Here is where the rubber (finally) meets the road. You have a story, you have some scenarios of your story that crystallize your acceptance criteria, and you have an automated development environment that allows you to build and test your app rapidly.

Using the story and scenarios from this blog post, we can write our first lines of code. But...I'm not going to do that here. I have a separate blog post (it certainly deserves its own) coming that will walk through the TDD process under the BDD umbrella. I'll update this post to refer to it once it's done.

In summary

Write user stories
Create scenarios based on the stories
TDD those stories starting at the top level of your application (typically a UI) and keep developing downwards until it's functionally complete

Yes, that's seriously it. There are methodologies, practices and tools that go inside of it but, at its simplest, that's all you're really doing. If you're reading about BDD then I have no doubt that you're already aware of most of these topics anyways.

The mystical cloak of BDD has now been removed!

DISCLAIMER: This was meant to be a high level, entry level explanation of BDD because I have rarely seen it simplified. Most information I've found online, the explanation seems to be a deep dive into how to write stories, stakeholder interaction, how DDD dictates the ubiquitous language, how it's the natural evolution of TDD (without ever showing you how!), and a variety of other entirely relevant information. The problem is that there's a lot of cognitive overload.

In other words, for BDD enthusiasts, or developers in general because we like to be intellectual, don't dog me out and poke holes in my examples. It's horribly contrived, I readily admit I am still learning these concepts and I don't believe anything I've written is incredibly misleading.

wtf, with a side order of bbq

2010-06-24T22:13:00.000-07:00

Just a blurb; been trying out new technologies and shiny toys. Here's my naive/ignorant take on things:

Been years since Linq hit .NET. Why is the NHibernate criteria API so incredibly non-intuitive and not making a huge move to linq? It's still clinging to the uber-verbose criteria API that, even fluently, makes hardly any sense. Yeah, I tried using Linq2NHibernate too but it was buggy for anything outside of simple selects and joins. I had an inner join that would magically make itself an outer join when I added an orderby clause. Hot tip for NHibernate; ditch the criteria API and just use Linq like all the other cool kids. It's ok to abandon the bizarre RDBMS abstraction that's been created.

I've been spoiled by Ruby. I can't tell you how many times in my day I think, "goddam, why can't I have mixins!?" It would make a lot of things a lot easier/sexier.

Finally, how can there not be a fully automated solution for deploying .NET web apps? I want something that builds the DB, deploys an MVC app and creates one in IIS if it doesn't exist yet. I haven't found anything like that. Granted I haven't looked too much but I didn't find anything with a handful of google searches. This is another area where the other open source community blows .NET out of the water. If I cared, I'd try to make something like this but I don't have the friggin' time.

Finally, finally I am again reminded of how small the open source community is in .NET. Still can't figure out why.

Here we go again; where is my mind?

2010-05-09T21:08:00.001-07:00

Something is itching at my mind and I haven't given it a name or a face yet. Whether I use Ruby, Java, C#, Scala or Javascript, it doesn't matter. They're details. When you go to Facebook do you think "Wow, this really feels like PHP." or when you hit Twitter do you sense the presence of Ruby and Erlang? Not so much. Then what counts here? What is it that matters?

Software is just a means to an end. I'm not in the business of writing code, I'm in the business of creating tools. Software just happens to be the vehicle in which I deliver them. You need a tool that will remind you to call your mother on her birthday? I'll write software that generates email reminders for important dates. Alternatively, I could have created a phone service that would call your home or cell phone as a reminder. Maybe I could create a network of carrier pigeons that did the same. Unfortunate for the pigeon trade and call centers, writing software is a lot cheaper and maintainable. Do you see what I'm getting at though?

It's more about what I'm delivering than it is how I deliver it. And, for me, the "how" is no longer so narrow. I'm not just a .NET developer and I'm more than comfortable stepping outside of the MS world. I've learned a fair number of engineering practices and principles that are language agnostic like DRY, YAGNI and some of SOLID. I can pick things up quickly no matter which language I choose to use. It's satisfying to know that within 2 weeks of reading and practicing, I have a fairly good idea of how I'd do modular development in Ruby and I even grok some of the deeper concepts like Ruby's compositional nature and metaprogramming.

One benefit of this line of thinking is that I'm no longer narrowing my vision to how I build what the customer wants. I have a much broader perspective of the business I'm in. Ultimately, I'm sure 98% of what I make will be a software product but someday there's going to be something that I think of that can be better serviced with a non-software solution. If I'm lucky, nobody else will be doing it and I can make my fortune from it.

What drove me to this whole post is that I'm trying to figure out what I'd like to create with my new found Ruby skillz. It dawned on me that, while Ruby is a blast to use, it's just the details. The hard work is figuring out what the hell I want to bring to the world. What's my product? What's my vision? What do people want? That's the new mental hurdle for me now.

Ruby is cool, Time for Rails

2010-05-02T18:51:00.000-07:00

I've spent the last couple weeks reading about the fine details of Ruby. My first impressions are good. I dig the language. I haven't put it to good use yet though. Mostly just dicking around in IRB and putting some small classes and modules together. I've been using RubyMine and NetBeans but I haven't had any clear winner on a Ruby IDE. Again, I think once I get into actually writing an application I'll have something more to substantial to share in that regard. Or maybe I'll shed my dependencies to a GUI and go all command line...well, let's not go overboard here. One thing at a time.

Now the next thing to check out is Rails. On first blush, I can see where ASP.NET MVC gets its influence. They share a similar DSL and even class/method names are echoed between the two. But, once again, I'm starved for details. I don't have any books on Rails so I may have to shop for one. I'm mostly just putzing around with what I know from ASP.NET MVC. Did I mention that they're close relatives?

Playing with Ruby

2010-04-21T18:52:00.000-07:00

With the 1.0 release of IronRuby I decided to take a brief detour from my prior game plan of outside-in development . Part of that decision was because I'd wanted to check out Ruby for a while as a dynamic language (I've lived in a stuffy, static world for too long) with a lot of hype around it. Part of it was because most of the cutting edge BDD work is happening in the Ruby space. And the last part is that Ruby is in the .NET space now (at least up to 1.8.6) so the barrier for entry couldn't possibly get any lower. Yeah, I know the IronRuby project has been going on for years and prior to that it was dirt simple to get Ruby running on Windows but whatever. I'm here now.

Last year I did manage to pick up the book Beginning Ruby which I, unfortunately, didn't take a shine to. The first handful of chapters were light on the details of Ruby and deferred it for later chapters that I never got to. But that's also my fault because I'm a reference book kind of guy. I just picked up The Ruby Programming Language the other day which totally itches that scratch.

I've been playing around with the interactive Ruby shell which has been fun. It gives me a chance to take a spin before I do anything serious. Now I'm looking to pick up an IDE. I downloaded NetBeans and RubyMine. I'll post back with impressions on both the language and the tools.

Analysis and Investigation on Outside-In Development

2010-04-13T19:40:00.000-07:00

BDD has a variety of testing tools surrounding it in a number of languages. Since I'm primarily in the .NET world (looking to expand that soon), I've dabbled with MSpec and had a lot of fun/success in creating descriptive tests that spoke the language of the business and communicated value. That was my first experiment in the world of domain drive design in an agile process.

The one thing these tools have in common is that they promote outside-in development. In BDD that literally means starting at the touch point with the consumer/customer/stakeholder. For most applications, that's a GUI of some sort but for others it may be a web service or something similar.

I've seen outside-in development go by a couple names like story driven development or acceptance test driven development. Unless I'm mistaken, they're both trying to achieve the same goal. What outside-in development is trying to do is make the software customer-oriented not unlike the agile processes that fit with this thinking. You start building the software from the customer's point of view based on their specification of it (usually as a story). Coupled with agile, you're doing something along the lines of rapid prototyping (with a bit more discipline). It's also keeping you focused on what the customer wants. It discourages gold plating and extra work that are typically waste.

<tangent>

I don't like to say gold plating because I know there are those developers that think that discouraging gold plating is like discouraging free thought and creativity. I would disagree. The hard pill for us to swallow is that what we perceive to be a "better way to do things" is not from the perspective of the actual consumers of the application. They may have no use for the bells and whistles that we believe to be productivity boosters. What it may be doing instead is creating excess inventory that costs money but has no ROI.

However, if you're in an agile process (or even if you're not), don't despair! Agile, by its very nature, relies on high-bandwidth communication. Reach out to the customer and communicate your creative thoughts and ideas. They will rely on your expertise in this arena and most times accept your recommendations. But, just remember, if they don't find use for your widget/tool/interface then don't do it (at least on company time :-P)!

</tangent>

Sooooo this is what I've understood so far. I am by no means an expert on outside-in development and I'm still trying to understand the practice. In the past, I've worked from the application logic and worked my way downwards. I haven't done it from the UI down which is certainly an interesting experiment. I'm also coming to find that I haven't done nearly enough acceptance/functional testing in my travels.

I plan on following up this post with my first attempt at doing outside-in development. I need to find a good book on it. I'm pretty sure the RSpec Book is probably what I'm looking for but any recommendations are appreciated. In the meantime, I've just been reading blogs, articles and comments. One such blog I ran into has a tremendous amount of insight into testing and offers good information to get you started on writing acceptance tests using ASP.NET MVC and some other tools and frameworks. Check out Steve Sanderson's blog to get some really great information.

TDD Tidbits: Your unit tests suck (and so does your design)!

2010-03-10T05:40:00.000-08:00

TDD is a design process but there are skills required outside of its discipline that you need to master as well. One such skill is writing proper unit tests. Prior to TDD I thought I was unit testing. I really wasn't for a number of reasons. The simple answer is that my design wasn't permitting unit testing and what I was calling "unit" tests were actually integration tests. Classes were tightly coupled, methods were more procedural than OO, I didn't do a good job of separating responsibilities/concerns, etc.

A unit test has some simple requirements you need to fulfill. I'll rattle off a list of them off the top of my head.

The test must be fast
The test must be repeatable
The test must be predictable
Only one assertion per test
The test must isolate the behavior under observation

Easy, right? You'd think so. I'd heard these in some shape or form before I began to do TDD but it never really hit home. I've seen a couple blog posts with lists like this one so I'll try to describe my thoughts on each of the items above. I'm sure I could go on for hours about them and more so I'll try to keep it brief.

DISCLAIMER: The following code examples are extremely naive and serve only to demonstrate.

The test must be fast

Unit tests are meant to be run frequently. You have them local to your development workstation and they (should) run as part of your continuous integration. Unit tests are regression tests and your first line of defense. They report to you when something is no longer behaving the way it's supposed to. You need that feedback immediately and there's absolutely no reason for them to be slow.

For any system of significant complexity you don't want to wait 30 or even 10 minutes to find out that a bug was introduced. Unit tests should execute in milliseconds and running a whole suite of them should execute within seconds. For example, a project I had at work had around 300 tests that would execute in 4 to 5 seconds. That's the type of speed you should be aiming for.

Having tests that run in the timespan of minutes immediately introduces context switching. What happens when you kick off a full system build for a project that may take a minute or two or more to complete? You open up your browser and see what's going on in the Twitterverse, Facebook, StackOverflow, etc. You don't want that to happen for your testing. It's good to keep focused on the task and to plug along without too much interruption.

The test must be repeatable

This one is simple. I can run a unit test as many times as I want and it will not fail. Take the following for example of what would not be a repeatable test. This is a domain of rabbits. You have some rabbits, you add them to a collection of rabbits. It's a cruel domain and no two rabbits may have the same name. When you run this test a second time it will fail since it's picking up state from the last run. "Thumper" will already be in the database so adding him again will cause an error.


[TestFixture]
public class RabbitFixture
{
    [Test]
    public void Should_create_rabbit()
    {
        var rabbitRepo = new RabbitRepository();

        rabbitRepo.Add(new Rabbit("Thumper"));

        var thumper = rabbitRepo.GetByName("Thumper");

        Assert.IsNotNull(thumper);
    }
}

public class Rabbit
{
    public Rabbit(string name)
    {
        Name = name;
    }

    public string Name { get; private set; }
}

public class RabbitRepository
{
    private readonly ISessionFactory _sessionFactory;

    public void Add(Rabbit rabbit)
    {
        using (var session = _sessionFactory.OpenSession())
        {
            if(Exists(rabbit))
            {
                throw new Exception("Rabbit of the same name already exists!");
            }

            session.Save(rabbit);
        }
    }

    private bool Exists(Rabbit rabbit)
    {
        return GetByName(rabbit.Name) != null;
    }

    public Rabbit GetByName(string name)
    {
        using (var session = _sessionFactory.OpenSession())
        {
            return session.Linq<Rabbit>()
                .FirstOrDefault(r => r.Name == name);
        }
    }
}

There are various tricks to make this test repeatable but not without violating some of the other guidelines like test isolation and speed. Unit tests shouldn't rely on external state and likewise they should not be creating any state that will last beyond the life of the test itself. It will be hard to keep the test repeatable and is brittle.

The test must be predictable

1 + 1 will always equal 2, right? Conceptually, your test should do the same. The inputs will always yield an expected output. I don't think this needs much more explanation.

Only one assertion per test

This is one of the more misunderstood practices of unit testing. Don't mistake mapping the word "assertion" to the Assert function that is called within a unit test. In this instance, they are not the same. You may call the Assert function multiple times to assert a single behavior. Take the following example.


[TestFixture]
public class RectangleFixture
{
    [Test]
    public void Should_resize_rectangle()
    {
        Rectangle rectangle = new Rectangle(40, 20);

        rectangle.ReduceSizeByPercent(50);

        Assert.AreEqual(20, rectangle.Length);
        Assert.AreEqual(10, rectangle.Width);
    }
}

public class Rectangle
{
    public Rectangle(int length, int width)
    {
        Width = width;
        Length = length;
    }

    public double Length { get; private set; }

    public double Width { get; private set; }

    public void ReduceSizeByPercent(int percent)
    {
        Length *= (percent * .01);
        Width *= (percent * .01);
    }
}

There're two calls to Assert to verify that the rectangle's size was reduced by 50%. That's what we're talking about when we say a test makes only one assertion. It's asserting the one behavior. Don't hate yourself if you call Assert more than once and don't feel the need to create another test.

The test must isolate the behavior under observation

Now that we're warmed up let's look at the one guideline to rule them all. This is the one that will have the greatest impact on the design of your code. You have to isolate the behavior you wish to test.

You can read this another way. The unit test cannot fail for any reason other than the implementation of the behavior being tested is incorrect. I have read blogs that mandate that a unit test cannot touch the file system, a database, a network, etc. That's not just because of how slow that may be. It's because now your unit test may fail for any reason related to an external dependency that has absolutely nothing to do with what you're unit testing. When you get the red light that a unit test fails it shouldn't be because you didn't install a database, it shouldn't be because you neglected to include a configuration file, it shouldn't be because your network cable isn't plugged in. Those have nothing to do with the unit test at hand.

Following this guideline will teach you how to detach your class from its external dependencies. The external dependencies aren't just things like databases and LAN access. They can be other classes that have rules of their own that need to be satisfied. You do not want your test to fail if some rule in a class that you consume isn't satisfied. That's outside of the scope of the behavior you're testing.

This is where people start to introduce language like "mocking" or "faking" your external dependencies. These are ways of allowing you to truly isolate the behavior you're trying to test. You're replacing pieces of your class that would cause the test to fail for reasons outside of the class's cares or awareness.

When you first start to really isolate the code you're trying to unit test the first thought that may pop into your mind is that "I'm just writing it this way so that I can test it!" Yes, you are but there is a truth you do not yet realize (and may take some time to settle in). Well designed code is easily testable and easily testable code is well designed. Writing proper unit tests can expose major (or minor) issues in the your design.

For me, this is where I learned the most lessons and what made me truly appreciate things like the SOLID principles. It leads you there and, in my opinion, you would have to go way out of your way to succeed in isolating your tests but avoid good design. It puts bumpers on your bowling lane so to speak.

Summary

Unit testing in and of itself is huge to the design process. Without even engaging in TDD, it is going to highlight deficiencies in your design. There is a lot of talk that TDD isn't about testing, it's about design. Unit testing is also about design so it's a perfect marriage.

TDD Tidbits: Red, Green, REFACTOR!!!

2010-03-09T05:38:00.001-08:00

So I was a TDD noob at one point. I had to start somewhere so I picked up some recommended reading, Kent Beck's Test Driven Design: By Example. I'll be honest; I didn't like it. I actually returned the book. Was I stupid? No! It just didn't seem to add up.

To Mr. Beck's benefit, I wasn't rejecting his book but rather the notion that I should put myself on a leash when I code and do "stupid" stuff like return static data to satisfy a test. I was feeling the discomfort a lot of developers feel when they first dive into this stuff. It's a whole different way of writing code. I would never fault anyone for having reactions like my own.

The idea of returning junk data to satisfy a test was probably the hardest thing for me to overcome. I spent many frustrating sessions trying to figure out when to stop returning dummy data or why I was even doing it. It was frustrating to know how to code things but having to hold myself back and continue with the TDD process. It won't let you wander off and start implementing all sorts of code.

Why the hell would I return dummy values in my production code? Why would I fake out my code at all? I could write code all day that would return dummy data. Hey look, my code returns zero! On the next unit test I can have it just return one and fake that out as well! What the hell is this proving? I'm not writing any meaningful code! I KNOW what the answer is. Why do I have to go about it this way? What a waste of time! *head explodes*

To speak to my frustrations I didn't fully understand the process and I didn't (immediately) see the benefits. I was missing the important step of refactoring my code after the test passes. Sure, you may write a test that returns a static value of zero. Then you write another test that expects the code to behave a new way and return another value. At this point, feel free to refactor your guts out. You don't need permission to write code. Don't let the dogma of "only write code when you have a failing test" fool you. It comes in two stages. You write code to get the test to pass and then you write code again to refactor! Your test passes but that doesn't mean all hands have to come off the keyboard!

For example, here's a bucket. You put apples in the bucket and then you want to know how many apples you have. The first test and implentaton may look like this.


public class BucketFixture
{
   [Test]
   public void Should_have_five_apples_in_bucket()
   {
       Bucket bucket = new Bucket();
       bucket.AddApples(5);

       bucket.TotalAppleCount.ShouldEqual(5);
   }
}

public class Bucket
{
   public void AddApples(int appleCount)
   {
   }

   public int TotalAppleCount
   {
       get
       {
           return 5;
       }
   }
}

Then you want another test to hammer out more of the behavior of this awesome bucket.


public class BucketFixture
{
   [Test]
   public void Should_have_five_apples_in_bucket()
   {
       Bucket bucket = new Bucket();
       bucket.AddApples(5);

       bucket.TotalAppleCount.ShouldEqual(5);
   }

   [Test]
   public void Should_have_no_apples_in_bucket()
   {
       Bucket bucket = new Bucket();

       bucket.TotalAppleCount.ShouldEqual(0);
   }
}

The new test breaks as expected but now you can't pass back dummy data. What code can you write to satisfy both tests?


public class Bucket
{
   int _totalAppleCount;

   public void AddApples(int appleCount)
   {
       _totalAppleCount += appleCount;
   }

   public int TotalAppleCount
   {
       get
       {
           return _totalAppleCount;
       }
   }
}

Huzzah! But I don't necessarily have to stop there. I can still refactor if my heart so desired. I don't need a failing test. What if I wanted to be super cool and use auto properties? Don't bother to write a new test for it. Just do it.


public class Bucket
{
   public void AddApples(int appleCount)
   {
       TotalAppleCount += appleCount;
   }

   public int TotalAppleCount
   {
       get; private set;
   }
}

No failing test required! But bear in mind this is refactoring; we aren't changing behavior, only structure. The code must continue to behave the same. The tests will verify that.

Another thing to point out is that if the only behavior the bucket exhibited was that it had 5 apples then the test and implementation stops immediately. This is when it's called out that you're trying to do the simplest thing to satisfy the requirements. Even when new behavior is added, you're taking the shortest route to functional without being a complete chimp about it. Add patterns where applicable and such.

Last point I'll make is that now I view my first test as probably the most important to my API. The first test is figuring out the names of my classes, interfaces, properties, methods and arguments. It's the first stab at the design of the class that you're making. This is where I'm extra sensitive to the needs of the client code (typically called dog fooding). It's a big deal to me that my code demonstrates its intent and usage without the need for lengthy comments.

So there you go kids. Take advantage of the refactoring step! Do all the stuff that you want to do when you think that the TDD process has put you on a leash.

TDD Tidbits

2010-03-09T05:36:00.000-08:00

I've been practicing TDD for two years and when I take a step back and look at what it's done for me I see I've learned a lot. I'm a far better coder because of it. Had I not picked it up, I doubt I'd be as well off. I began writing a post about it but it became monolothic. There's too much to be said. I decided to break it down into individual posts to make them easier to digest.

Just doing superficial searches on TDD in google, I don't see much in the way of individual experiences on TDD practices. I'm sure it's sprinkled about in blogs but most of what I find are the howto's, tutorials and videos surrounding it. I think what I plan to write is a mixture of tips, insight and experiences in TDD. I'm hoping it has value for the novice, the intermediate and the seasoned veteran. It's probably going to be in C# but I'll see if I can't do examples in other languages (feel free to comment/request one for all 3-4 of my possible readers).

Kickstart your BDD training

2009-09-27T08:26:00.000-07:00

Rob Conery posted an excellent quick-start for getting up and running using MSpec titled "Make BDD your BFF". For those who still haven't taken the plunge, MSpec is framework for writing tests using the BDD style of development. Overall, the literature on MSpec on the internet is lacking so take advantage of this and help get the word out!

Also, just so I'm not repeating too much, Apostolis Bekiaris just posted an entry similar to my own except with more links to resources.

I don't mock much anymore

2009-09-25T19:52:00.001-07:00

I still use Rhino Mocks. Never tried any other libraries. I probably should just so I can be more worldly but it's fit my needs and I have a laundry list a mile long of ToDos.

That being said, I've done a lot of unmentored exploration into the whole unit test and TDD countryside. At the beginning of my journey I did a metric ton of mock creation. I'm speaking to the different types of test doubles. Go check out Fowler's ever-expanding documentation on the topic.

What I found was the obvious (but not at the time); mocks are part of the test assertions. Its giving me intimate details about how an object is doing its work. As such, they should only be used to verify the test at hand. If they are not truly verifying the expected behavior then it's not a mock. It's a stub, it's a fake, it's something that's allowing the process to emulate its behavior in some integrated environment.

The tests get brittle when you mock things that have no business being mocked. What I started doing was creating everything as a stub and then used the Rhino Mocks AssertWas/WasNotCalled() extension methods. Things end up being much cleaner and far less prone to unexpected test failures.

But I ramble. We're coders. Let's look at some code. Here's an example of a test I wrote using Context/Specification (a style of testing supporting BDD) and the MSpec library. Everything is a stub and I use the AssertWas/WasNotCalled() to assert that certain collaborations occurred the way I had expected them to.

Forgive the user_registration_scenario class as I use it as the base class for a number of scenarios not shown here. It's the collection of inputs/collaborators used for the test and, per Context/Specification, the Act of Arrange/Act/Assert is at a class level, not at a method level.


[Concern(typeof(UserAccountCreationService))]
public class When_a_user_registers_successfully : user_registraton_scenario
{
    Establish context = () =>
    {
        var no_errors = new List<ErrorInfo>();

        _modelValidator
            .Expect(v => v.Validate(_account))
            .Return(no_errors);

        _userRepository
            .Expect(r => r.UsernameExists(_account.Username))
            .Return(false);
    };

    Because of = () => _service.Create(_account);

    It should_send_confirmation_email =()=>
        _emailService.AssertWasCalled(es => es.SendConfirmationEmail(_account));

    It should_save_user_to_persistent_store =()=>
        _userRepository.AssertWasCalled(r => r.CreateUserAccount(_account));
}

public class user_registraton_scenario
{
    protected static IEmailService _emailService;
    protected static IUserRepository _userRepository;
    protected static IModelValidator _modelValidator;
    protected static UserAccountCreationService _service;
    protected static UserAccount _account;

    Establish context = () =>
    {
        _account = new UserAccount { Username = "kdog" };
        _modelValidator = MockRepository.GenerateStub<IModelValidator>();
        _emailService = MockRepository.GenerateStub<IEmailService>();
        _userRepository = MockRepository.GenerateStub<IUserRepository>();
        _service = new UserAccountCreationService(_userRepository, _emailService, _modelValidator);
    };
}

I might remark that I'm quite enamored with Context/Specification. I never liked the look of my tests so much. At work, it's agonizing because we're still at a very basic level of unit testing. I'm thinking of giving a presentation on BDD using MSpec...

Constructor injection FTW

2009-04-12T20:00:00.000-07:00

I prefer using constructor injection with DI for a few simple reasons.

It's self-documenting code. It's explicitly telling clients or maintainers of the component how it's put together.
It keeps my components honest. In most cases, excessive constructor arguments is a code smell.

I also don't like setter injection for a few simple reasons.

It adds noise to component's API. I wouldn't want to see public properties hanging off a component that serves's me no use as a client.
It feels like it breaks encapsulation. How the component does its work internally shouldn't be part of its public API.
It obfuscates how the component is put together.

Finally; ubuntu installs...no problems!

2009-04-09T21:51:00.000-07:00

This has been a WIP since years and years now. I install the latest version of Ubuntu two or three times a year mostly because I'm curious and partially because I'm a masochist. I generally want to get into using an open source OS and just be aware of how things work on the other side of the fence (being a Windows user and .NET developer). That's also why I chose Ubuntu; it's the entry-level linux distro.

Things usually work out this way; I install Ubuntu and there are issues. Wireless has never worked out-of-the-box. The graphics are 50-50. Sometimes they work and other times they don't. I've done the whole ndiswrapper thing and iwconfig and messed around on the command line more than any Windows user should ever have to feel comfortable with. Things never end up pretty and are generally unstable.

For instance, my last installation was Ubuntu 8.04. Wireless didn't work. Graphics were fine. I sacrificed the customary chicken and goat and eventually got the wireless to work. But then after I did a restart it stopped working again. Then it intermittently worked until finally it stopped working altogether. Completely random.

I tethered my laptop to the wired network and decided to updgrade Ubuntu to 8.10. After I did, the bootup had the funniest behavior. It would stop booting unless I pressed keys. Nothing in particular. Just pressing keys would make it advance. Once I booted into the desktop it said there were new drivers for the nVidia graphics card. I let the update take place (the drivers were recommended by Ubuntu). When I restarted, I couldn't get to the desktop anymore. One of the startup steps would fail and it would die. I'm not a linux ninja so it was as good as dead.

I burned down the now defunct Ubuntu 8.10 install. I downloaded and installed Kubuntu 8.10 out of sheer desperation. It too demonstrated the "press some goddam keys to boot" behavior so this wasn't an isolated incidence. Once I got to the desktop it didn't recognize I had wireless card at all and the graphics chip wasn't detected either. I was worse off than when I was just in Ubuntu 8.10. Fail.

That was last night. Today, I see that there's ubuntu 9.04 experimental. I installed it, it detected my wireless and it only took a minor spiritual channeling to get the graphics to work. Needless to say, I am happy that things just worked out-of-the-box. This blog post has come from my linux desktop. Joyous day!

Hot feature storm and digging into ASP.NET MVC

2009-04-06T20:22:00.001-07:00

Hot feature - A feature that is released as a hotfix usually due to an overly complex or bloated release process that makes normal releases a burden on the entire organization. Those wishing to circumvent the release process will hide features in hotfixes and have them pushed out without any of the normal safety nets used for an official release.

Hi and welcome to my life for the last month. Hot features suck. As a developer, I've never felt so dirty or violated. The things I do for money...

The story; we built a releasable product but never got an official release for it due to lack of QA resources and the overall brutal release process we have now (4 days for the automated QA tests to run! Bullshit!). The solution that was worked out was that I had to tear apart the product and release each feature as a hotfix (henceforth, hot feature). Decomposing a product for its features in a non-chronological order was a nightmare in and of itself given how code evolves. This was only compounded by the fact that there was perfect storm of daily issues that would block or bump these hot features. There was one day where I had to tear apart the product 3 times, each time adding or removing a feature until ultimately, we didn't release anything at all. I will never partake in such a thing ever again.

Tomorrow we push out the last of the hot features and I'll officially be switching teams. My new role is much like my existing role. I'm generally involved with modeling the solution domain and implementing the application layer. One of the first things my team lead has indicated to me is that I'll be working on some new web pages and the platform of choice is going to be ASP.NET MVC. This is thrilling news for me as I've never cut my teeth on any MVC platform. I've been reading about it, I bought a Ruby book that just arrived today so that I could try out rails and I'm hearing stuff all the time from Mr. O'Hara about his MVP framework.

As the .NET web dev world knows, ASP.NET MVC 1.0 was RTM'ed a few weeks back. I've kept it on my radar but hadn't invested any time into it. Not because I don't care but that I've been involved with a brutal release schedule at work (as outlined above) and a newborn child. This last weekend I finally had a chance to download it and take it for a spin.

I've been developing with web forms since time out of mind and I haven't really known anything else. They've never felt quite right and given my gravitation towards TDD, it's become apparent, more than ever, that it's just not the right solution for me. I can't test the way I want to and I have to struggle against web forms to create logic that fits the web forms domain, not my product's domain. I've got the page lifecycle down pat and it was a great introductory solution for me to get acquainted with web app development but it just creates tightly coupled code by default.

My first impression of MVC; I'm smitten. It just flows the way my mental model of the application layer should be behaving. As far as ASP.NET MVC I'm glad I hopped on at 1.0 since they've improved it considerably since the betas. What it allows me to do is nearly forget the fact that I'm working on the web (outside of rendering the views). Controllers create the workflow of the app and they create truly meaningful names and actions that speaks directly to what you're modeling. It's liberating from my years of web forms oppression.

I really want to articulate for all 3 readers in my audience how this has liberated me and one example ran through my mind that captured it perfectly. Let's take the example of some portion of a simple banking application where we want to save a deposit. Use your imagination as to how it should behave.

In web forms, I load an account on Page_Load and I tie into the button click event of a web control to submit a deposit from a user.

public partial class AccountPage : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        //Load the account
    }

    protected void btnSaveDeposit_Click(object sender, EventArgs e)
    {
        //Save the deposit
    }
}

In MVC, I speak to the AccountController and I tell it to load an account or save a deposit.

public class AccountController : Controller
{
    public ActionResult LoadAccount(int accountId)
    {
        //Load an account and show it to the user.
    }

    public ActionResult Save(Deposit deposit)
    {
        //Save the deposit
    }
}

Do you see the difference in the way you think about this code? Web forms have the unintentional side effect of obfuscating the workflow of your application. It's noise that doesn't speak to anything. What the hell is Page_Load and why do I care about intercepting events to a button? Why do I need event arguments that I'm not going to use? What does this all have to do with a bank account or saving a deposit?

Absolutely nothing. You get mired in the details of the page lifecycle and all the black magic you have to employ to do what should normally be simple activities. I can never forget lessons like "Don't forget to load dynamic controls at page init or else their viewstate is lost!" or "Always load your data on prerender as events are fired after page load and you may end up displaying stale data!". I just have a hard time caring for web forms, the page request life cycle, and all the bloat that comes with their attempt at creating a stateful application on a stateless medium.

With MVC, it makes perfect sense. My workflow is clearly illustrated, my purpose is outlined with meaningfully named actions and we can get strongly typed arguments. There is no ambiguity, this is no unexpected behavior and despite it's learning curve, I can show this to anyone and they will get an idea of how the application flows.

So, this is my first impression and what I've witnessed. As a 1.0 product it's no doubt rough around the edges and it seems like there's a lot of work to be done to ease the pain of creating the views as the web controls built for web forms can't (for the most part) be dropped into an MVC view. The tutorials on the main website are also light on details. They aren't tutorials so much as they are quickstarts. I had to munge around to find out how some things worked. Other than that, it looks to be a fun platform and I'll report back when I have more dirty details about my travels in ASP.NET MVC land.

Holy smokes, do I have a lot to learn

2009-03-26T21:53:00.000-07:00

It's been a loooooooooong time since I really invested in my technical expertise as a developer. Sure, I've grown a ton over the last year and I've really "come into my own" but as far as the latest and greatest talks, toys and technology platforms, my head is still somewhere in late 2007. Luckily, podcasts and prolific blog writers are making my education far easier than I could have imagined. At the same time I'm absorbing massive quantities of information that I hope I can retain at least 50% of. Here's a shortlist of the craziness swimming in my mind.

I made a small quest into truly learning what Javascript is all about and I'm happy to report that it really is an awesome tool. It's been getting a bad rap for a number of years but it's really turned out to be a simple but effective language. I've been getting interested in dynamic languages overall and I used Javascript as an opportunity to check out something I've already meddled with AND I can program with nothing more than Notepad and a browser (how effing sweet is that?). Seriously, I'm sick of compilation. I waste an hour of my day every day compiling projects. But that's beside the point. Javascript is great. Go check it out, understand closure, understand that everything is a module (function, whatevs) and dynamic languages are not as scary as you've been programmed to believe.

I've begun to study domain driven design simply so I can see what all the hoopla is about. At first, you'll be patting yourself on the back since it's talking about things that any seasoned programmer is familiar with. You have your solution domain where you model your customers or orders or whatever it is that your software is trying to solve. But it's more than that. It's creating discipline and drawing lines and boundaries where you may not have considered them before. It's trying to promote clarity not purity.

Case in point, I was involved with a recent code review where I came across some code that had a distinct smell. Upon discussing the issue with the developer submitting the review it was revealed that the code existed due to a hack from an external system. Basically, the external system didn't have a way to model some financial transaction so it used another financial transaction to "hack" it into the system. For example, it's like recording a negative deposit to some banking software because the software doesn't have a function to withdraw money. Some of the DDD literature I've been reading recently points to the simple fact that we're no longer modeling the domain. We're modeling the hack of another system. Frankly, you don't need DDD to see this as a problem but it certainly brings it into perspective. It brings confusion to the codebase, to the domain, to any developers coming on board, the code that evolves from this will be as bent and unsightly as its ancestors and so forth. I may have not given this as much scrutiny had I not had so much DDD dancing through my mind.

I read Ken Schwaber and Mike Beedle's Agile Software Development with Scrum since the scrum tsunami is about to crash on my development organization. I'm drinking the Kool Aid so I'm not so concerned about whether or not it's a good methodology. The only thing that worries me is if the management cast can stomach it when I actually speak up and collaborate in ways I had never done before. If what I read is true then I should be telling them when what we're doing is ill advised. I continuously read that I am now "empowered". We'll have to see how that ultimately shakes out...

I started digging into .NET 3.5 and some of the niceties that have come to the framework. Nothing too serious but I hope to be writing a new web app with it soon. I'm particularly interested in ASP.NET MVC since that's now in 1.0. I've downloaded everything, now I just need to do something with it.

Other stuff that's on my radar but I haven't played with yet is Fluent NHibernate, Structure Map, Ruby, and DSLs. I think I may have a post or two coming to discuss some thoughts that those topics have generated for me.

In any case, my brain is running dry and it's 2am.

XML sucks

2009-03-25T12:38:00.000-07:00

Friggin' namespaces. Such a pain in my ass. JUST PARSE THE GODDAM VALUE!

Of C# Interfaces and dynamic typing

2009-03-17T17:36:00.000-07:00

Adopting the design kung fu of TDD was one of the better practices I've picked up as a developer in the short time that I've been one. I build out the behavior of my system with stable, solid code and maximum reward. Due to its method of design (unit testing) I've also learned other important skills in creating loosely coupled code.

The one style of programming that goes nearly hand-in-hand with TDD is programming against interfaces. This is a decades old approach. What I find to be the most enjoyable behavior of interfaces is the fact that it's breaking the client code from the implementing code. You're trying to loosen up your coupling. I used to think it was insulting to create an interface with any less than one implementing class. I was missing the point. I forget where I read it but I saw someone who summarized it wonderfully, “Creating interfaces is not to the benefit of the implementing code but rather to the client.” Points to anyone who can help me find the original source.

TDD becomes a natural litmus test for discovering when I should introduce an interface. You get what's commonly called “test friction”. Friction is simply noise in your tests that has nothing to do with the component you're testing. It causes them to easily crash or be brittle, and makes it hard to test overall. Anything that turns your tests into massive scripts or breaks often can be considered test friction. Abstracting out the friction into interfaces is key to keeping the tests focused and your classes loosely coupled.

At first you'll be surprised at how many interfaces you end up creating but then it eventually feels right. The interfaces were always there between your objects, you're just formalizing it. What's wrong with that?

Well, actually, maybe a couple of things. I do get annoyed with the ceremony of interfaces. First I need to make the compiler happy. I may have a class that perfectly conforms to the expected method signatures of an interface but I can't use that in place of that interface; it's not the right type.

So then I need to create the interface every time I need to abstract something(which is often enough). Being an obsessive, compulsive coder, I create a new file for it (although, from time to time, I may embed them with their default implementation). I'm introducing noise into the project by having more files and more types to wade through in the auto-complete. Not ideal.

Recently I've looked at dynamically typed languages and felt a secret jealousy. They don't have interfaces. It's just good old fashioned duck typing. It's just messages being passed between objects. Why can't I do that? I don't need an interface to pass messages between objects. The object either accepts those messages or it doesn't. No need to paint myself into a corner. Testing becomes easier. I create objects on the fly, mock/stub/fake them up with hardly the effort it takes in C#. No extra interfaces necessary.

I guess the root of this may be that I'm finding the world of statically typed languages to be confining. It's been a feeling I've had for at least the last half of year or so. I've had a hard time articulating what it is that bothers me but I'm seeing it at as these things that I'm being forced into obeying by the compiler. Statically typed languages will certainly help you to avoid simple issues in your types but it can't guarantee you won't run into runtime issues anyways. Who can say they've never encountered a InvalidCastException? NullReferenceException? Statically typed languages are still exposed to the same problems that dynamically typed languages are. Compilation is providing compile-time debugging of your types. But if you're already writing unit tests, which undoubtedly test the interfaces of your objects, does that negate the advantage of compile-time debugging?

Most accounts that I've read of developers sharing a sentiment like my own usually end up embracing dynamically typed languages. Some even switch specialization and jump ship. I don't know what to do yet. I guess I have to go and find out for myself.

There' an awesome alt.net podcast that really speaks to where my head is at. It's an interview with Scott Bellware so if you dig his contributions to the community then you'll certainly enjoy this. I strongly recommend you give it a listen.

OOP in Ruby with Scott BellwareAOP

javascript unit testing/mocking framework?

2009-03-16T07:37:00.000-07:00

I've looked around the web and I see a ton. Can anyone give a recommendation on frameworks they've worked with? I'm being lazy and avoiding testing every one that I find.

Why we do it: Unit Testing

2009-03-10T19:54:00.000-07:00

What started me on this blog on such an elementary concept? I could list a couple reasons. There are those that don't unit test. To them, unit testing is an annoyance. They're experienced so they know exactly what the design and subsequent code will be. Unit testing just slows them down. I might comment that their defect rate is much higher than my own or that their code is far harder to modify or work with. These things don't matter. What matters is that when I face this resistance I need to be ready to respond with all the facts that negates any ill-informed opinions.

The other reason I'm on this is that I've been listening to too many podcasts. Notably some from Bob Martin (with his craftsmanship movement) and Scott Bellware's less-than-complimentary view on recent alt.net activity. They reasonably argue that developers latch onto the idea of using unit tests or practicing SOLID without ever knowing what benefit it is to them. They can't quickly tell you why they use it. In effect they're stagnating an otherwise progressive movement like alt.net by no longer questioning the practices that gave them the awesome methodologies and tools that they're using.

As a final note, lots of the benefits of unit testing are sometimes attributed to TDD. Recognize that TDD's primary goal is design and it is the beneficiary of unit testing. From what I read, BDD was born from this fundamental misunderstanding. This writing also assumes that we understand what good test writing is. When you change code it shouldn't make 10% of your tests break. That's a code smell. If you find yourself in such a situation then I recommend reading the XUnit Test Patterns book.

Without further adieu...

Unit tests are documentation

They document your API and demonstrate its usage. Test assertions are telling clients exactly how to specify the inputs to get the desired outputs. Invalid and erroneous use cases are outlined. Best practices for your code are emphasized. For these reasons, you may see developers (like myself) that will forgive violating DRY in order to make the test more story-like and readable. You want anyone to read the script and "get it".

Unit tests are better than documentation. Code comments, UML diagrams, design docs, etc. go stale within minutes of the ink drying. They aren't reliable for anything but the most static systems. That's not to say that they don't have their place but ,for the sake of development, they're best expressed in white board sessions and reflected in the code.

Unit tests are security

Good unit tests execute in fractions of a second and running the whole test suite should take a few seconds at most. If your unit testing suite executes on the order of minutes then they aren't unit tests.

They are your safety net for regression. Introducing change to the system will raise red flags anywhere that has been impacted. This immediate feedback loop allows us to fix problems before they go out the door as defects. It also illustrates defects in design. Making a simple change that implodes half of your test suite indicates that the recipient of the change is a dependency attractor.

I'll add the obligatory mention of ease of refactoring. The added security of unit tests allows you to confidently refactor your code with little fear of breaking the system.

Unit tests preclude debugging

At one point in my life I thought it was the best thing ever to be able to walk through my code, examine values, change them, simulate branching logic and so forth. No code could be a mystery to me because I could interrogate it in the watch window and make it tell its secrets. I'd be lying if I said that it didn't save my ass on more than one occasion.

Flash forward to today. I hate debugging. Debugging is a hassle. Someone has a problem in code then I have to go do a source control update, get the latest dependencies, do a build, work through peripheral issues in getting my integration environment up to snuff, somehow ham-bone data in the DB to recreate the issue BEFORE I can even begin to execute the debugger. Then, after I run through the debugger once, I have to do a DB restore or some other voodoo magic to restore my integration environment so that I may try again.

Imagine my shock and surprise when the problem that warranted the debugging session was as pathetic and minor as are most defects I've worked through. In fact, I can't remember the last time I found a defect that was anything more than an uninitialized value or an unexpected branching. It's almost heart breaking to make this discovery as you'd hope it would be some mythical code beast that needs slaying so then at least traveling minstrels and bards will sing songs of your valor and courage (Monty Python just sprung to mind).

Unit testing isolates the units of the system (duh). Recreating and driving out defects can be done without firing up any debuggers. Some TDD practitioners will profess that they never have to use a debugger, ever. The tests themselves provide the debugging. I can't make such a boast. The point is that you will be less involved with debugging because you will have appropriately addressed the conditions that create defects and you can easily hop into and test the code that is throwing the error. Debugging becomes a "break glass in case of emergency" type utility. You only need it in extreme circumstances.

One thing that I can boast is that integration or functional tests seem to be a formality now. I can almost always guarantee that my code works right out of the box before I deploy it to an integrated environment. It's a very satisfying thing to me and to clients of my code.

AUTHOR'S NOTE: I kind of got bored with this post halfway through it so if you're not feeling the love then neither was I. It's not you, baby, it's me. I'm just getting this out there since I've spent enough time looking at it in my posting queue.

Testing code highlighter

2009-03-07T22:14:00.001-08:00

This should look snazzy.


public interface IComicBookRepository
{
     ComicBookCollection GetComicsByGenre(Genre genre);
}

Decorator pattern: alternative to using AOP?

2009-03-07T20:27:00.001-08:00

I've wanted to check out some of the Aspect Oriented Programming frameworks out there just to get a feel for how they behave in the code. I understand the paradigm and the vocabulary but I haven't really played around with it. AOP is one of those things I keep promising myself to check out but I always put it off. Now I'm finally sitting down to check out what's around and how it would fit in with my day-to-day.

If you're an AOP framework you're generally implemented in one of two ways; either you're compile-time and the code is "weaved" into the class of choice or you're runtime and a proxy is generated for the class in question. Basically, you're looking to attach some behavior to a class that will happen before a method call, after a method call or when an exception is thrown.

AOP being a tool in my six-demon bag, I have to see how it can improve any of my current projects. Right now, I only have the ubiquitous logging issue that is commonly mentioned in the same breath as AOP. The usual problem is thus; you have some component who's main concern is not logging wonderfully verbose diagnostic information but rather that it builds a list of accounting records for export to a general ledger or it's approximating how late an MBTA train can be before the commuting populace riots. To keep the gods of Truth and Beauty satisfied you must separate these concerns.

My only problem is that I may have already. I hadn't seen it done this way before but I was using the decorator pattern to effectively perform the same work that an AOP framework would. I had fallen into using decorator pattern recently to eliminate inappropriate inheritance (just about any inheritance is inappropriate to me but that's a topic for another post). Think of it this way; the AOP framework is providing a mechanism to intercept method calls and do some magic before or after the a method is executed. The decorator pattern is doing just that. I'll break down the pros and cons for using an AOP framework or using the decorator pattern in a moment but here's a code snippet to demonstrate the thought.

NOTE: For the sake of brevity I'm hoping you can make logical leaps about the types and classes I'm using. They're purely fictional and they're not what's important.


public interface IComicBookRepostitory
{
    ComicBookCollection GetComicsBy(SearchParameters searchParams);
}

An IComicBookRepository is simply a repo for comic books. In this case it has a method for retrieving comic books by a set of parameters. The concrete class for the repo looks like the following.


public class ComicBookRepository : IComicBookRepostitory
{
    public ComicBookCollection GetComicsBy(SearchParameters searchParams)
    {
        return new ComicBookCollection();
    }
}

This class obviously does nothing of import but that's ok. We can fill this in with whatever we please when we know what that implementation will look like.

I can create a class that will "decorate" any instance of IComicBookRepostitory with error logging. Hence the LoggedComicBookRepository.


public class LoggedComicBookRepository : IComicBookRepostitory
{
    private ILog _log;
    private IComicBookRepostitory _wrappedRepo;

    public LoggedComicBookRepository(ILog log, IComicBookRepostitory wrappedRepo)
    {
        _log = log;
        _wrappedRepo = wrappedRepo;
    }

    public ComicBookCollection GetComicsBy(SearchParameters searchParams)
    {
        try
        {
            _wrappedRepo.GetComicsBy(searchParams);
        }
        catch (ArgumentException ex)
        {
            _log.Error(
                string.Format("Parameters: Genre {0}, Year {1}", searchParams.Genre, searchParams.Year), ex);
            throw;
        }
    }
}

Notice that it contains an instance of an IComicBookRepostitory. The LoggedComicBookRepository has a constructor that is configured with an ILog and an IComicBookRepostitory. The ILog will capture logged messages and the IComicBookRepostitory is what is being wrapped (decorated per the pattern). Whenever the wrapped instance of the IComicBookRepostitory throws an error it will be captured and the appropriate error logging will occur. Calling GetComicsBy(searchParams) is now completely logged and our concrete ComicBookRepository is none the wiser. Likewise, if we wanted to do more work before or after the method is called for any other reason then we may do so and capture the essence of AOP.

Here's some setup code that will perform comic book retrieval that will be logged.


public class SomeClass
{
    public void DoSomething()
    {
        IComicBookRepostitory repo =
            new LoggedComicBookRepository(
                log4net.LogManager.GetLogger(GetType(LoggedComicBookRepository)),
                new ComicBookRepository());

        SearchParameters searchParams = new SearchParameters(Genre.Action, 1995);
        ComicBookCollection collection = repo.GetComicsBy(searchParams);
    }
}

That setup/configuration code can easily be hidden behind a DI container or something similar but I'm just illustrating how it would generally work.

The advantage to this is that I don't need to bring in a new library with XML configuration, code setup and an API that may not be familiar to other developers. It's also swatting a fly with a bazooka. In the scenario presented above we really don't need to involve a professional AOP solution.

Where AOP makes sense is for a more generic scenario. With the code I've been working with, I want to emit important information about specific method calls and their inputs. If I didn't care for that then an AOP framework would be a far better choice. For example, if I wanted to include code that profiled method execution then I could have a stopwatch that started on method entry and stopped on method exit using an AOP framework. The only thing it may capture about the method is its name. If I tried to hack an AOP framework into my previous example I would have to generate additional code that would provide mapping between method names, their overloads and the class that was responsible with logging each.

So, once again, I've avoided digging into an AOP framework. I know what I need to know and when I find the square hole I'll put the square block of AOP into it.

I've made up my mind

2009-03-06T21:15:00.000-08:00

I want to write my own developer blog. I really do. I have two major enemies at the moment. A lack of casual time and rabid curiosity. The lack of time is self explanatory. I have a 4 year old, a 2 month old baby and a demanding job.

The "rabid curiosity" part is my laundry list of methodologies, technologies, practices and tools and I want to preview them all at the same time. For example, I want to check out what the premier dependency injection framework is so I'll go read some blogs and documentation. Someone will make a reference to BDD so I have to see what that is. It's behavior driven design which is apparently the logical evolution of TDD. So then I'll fire up another tab and start looking at that. Someone mentions something about TypeMock so now I have to go see what that's all about. Then I'll start reading the blog war around TypeMock and how it supposedly promotes writing untestable code.

You can see where this is going. At the end of this I can't say I have a demonstrable understanding in what it was I had initially set out to explore. I picked up a handful of nuggets and have a general understanding but it's nothing I can make any good use of.

I've recognized this and I've forced myself to give only a single topic of interest the bandwidth it needs. This has worked out well. I've been interested in scrum as it's coming to my company so I read Schwaber and Beedle's book on it. I wanted to understand the wackiness of javascript so I spent a week and read around and played a bit. Now I "get it".

I'm going to continue on this path and start blogging a bit more on the experience. It's the best way to learn and then demonstrate that I have a grasp on the subject.

I also need to improve on my writing. There was a time where I was never at a loss for words or had trouble communicating my thoughts. I let that skill atrophy so I have to build it up again. Bear with me in the meantime.

Too many interests, too little time

2008-10-15T09:06:00.000-07:00

I have too many goddam things I want to check out in the world of software development and not nearly enough time to entertain them in any significant fashion. There are a few tricklets missing or otherwise unpolished from my programming bag of demons that would prove to be valuable to my ability to dispense truth and beauty to the world of code. Here's the latest group of stuff that I want to dig into:

Ruby - Believe it or not I'm beginning to feel constrained in statically typed languages (it's a mostly love and partially hate relationship). Ruby seems to be all the rage so I want to poke around in it.
AOP - I would love nothing more than to break logging out of the components I write. I know I can abstract them out in one of a billion ways but I'd rather just have it be completely invisible to classes whose responsibilities should be focused on their task and not making sure log4net gets the message.
Being a computer scientist - I got so wrapped into the abstraction of software that I stopped thinking about the science of it. Steve Yegge reminded me just how much rust I've accumulated since graduating.
Agile Development - I've read the manifestos and some online documentation but I haven't committed to reading more details or purchasing any publications. The only reason I'm partially reluctant to start now is that it's a major uphill battle with my current team. They aren't dumb and they read about this stuff but there's no interest there. I'm not much on lobbying and I can't train them all (including the role of our manager).

Right now I'm mixed between finding out what AOP offerings there are for .NET and playing in Ruby development. I want to play with toys instead of read books.