Restless C#ding

I was at a local park today and saw a setup for kids gaming of Dance Dance Revolution. The amazing thing with it was the fact it accepted and displayed input for 32 simultaneous dance pads.

I found it quite interesting to see how it could handle so much simultaneous information being inputted. The real amazing factor though was how well the information was projected on screen. For 32 individual players on-site, you could quickly see how each player was scoring. It was impressive to see such a clean design.

Admittedly, I'm very early in the process of getting a full suite of automated continuous tests going against an app I'm working on writing. Currently it's only involving NAnt running NUnit tests on checkin.

Jeremy Miller gives some great pointers in this post on how to extend that. Inversion of Control (IoC) is a fundamental basis for testing interaction, as well as behavior tests through WATiN testing.

In working with Scrum and attempting to reconcile it against various other development and software project methodologies, I've come to realize it's not the complete solution for all issues with the development process. It's a great step forward however. It makes vast improvements from the waterfall approach.

In waterfall:

• Here's what we (the stakeholders) want (the feature checklist)
• Here's when we want it by (the deadline)
• And if you're lucky, here's some ways to verify you did it correctly.

In Scrum it's more egalitarian.

• Here's what we (the stakeholders) are trying to do to improve the product users' lives. 
• Here's what we (the analysts) think would best accomplish that goal
• Here's what we (the development team) think would be the best technical way to implement that

The problem is that there's no overarching design to bring everything together.

What's worse for a business is when personalities get involved. With Scrum, there's team success, and team failure. Individuals don't matter as much in that stakeholders are not really seeing individual achievement. What's the proper reporting structure for a Scrum team member? Who is the manager? The trite answer is that the team is self-managing.

The problem with this answer is in trying to reconcile self-managing teams with things like compensation and reviews. Perhaps the proper answer is to have group reviews where employees are reviewed by their ScrumMaster, some overall department manager, and by their peers.

What's even more interesting is how this can affect career paths. Employees of most career-oriented jobs follow a path from junior to senior to management, etc. until they reach their desired goals, retire, or fail to further advance. However how is it right to advance an employee on the basis of a team achievement? I would contend this would be on the merits of consistent behavior that makes headway in advancing the team unit, but I can see how this can be difficult to measure. This is especially true if the person to review Scrum team members were an employee who is not daily interacting with the team member.

One thing I'd like to note is that this career path for what I consider a driven developer is aside from a personal skills improvement path. This is well known in Mike Gunderloy's Coder to Developer book (which I'd strongly recommend as a great read. The state of realizing you should not just jump to code, over architect, or any number of other mistakes most (well, at least me, anyway!) developers make at some point in their professional lives is one which will personally advance you professionally. 

I've found it extremely interesting that some people have visual minds, and some people have visual minds. By this I refer to certain peoples' ability to see how a product will evolve over time, and how some people prefer to view that interaction visually, rather than through description.

The extent to which this is true is a fairly recent realization for me, and just serves to further prove the need for decent mockups and workable design as a prerequisite to architecture. 

In my experience, developers seem to have an easier time than most in transferring the code-in-mind, or -on-screen, to the end product. That being said, true mathematicians seem to have an even easier time simplifying the complex. They can take concepts that are extremely foreign or amazingly complex, and make it possible for even small children to understand. The true teachers have a gift for simplicity.

Take Kalid Azad, whose site BetterExplained.com offers some great simplistic insights to deep mathematical concepts. I came across his guide to imaginary numbers as a 90 degree rotated dimension from the standard number line, and was amazed how simple it was to understand. The interesting thing is how he presents it as a parallel concept from negative numbers, and fits it instantaneously to parallel logic.

Contrary to this blog's title, marathon coding, or Restless C#ding as I call it, does not always yield the most fruitful results. During a critical point in development, it's sometimes more helpful to force yourself to walk away from a problem occuring on the tail end of a session that is dragging late into the non-work day.

Code quality will doubtlessly improve, and your mind will have a much simpler time trying to analyze and solve problems. I'd read articles about the uninterrupted time (I really wish I had saved the article) needed to concentrate to get into the so-called "Zone", a career- and industry-agnostic state of mind (characterized by a higher concentration of alpha activity in brain patterns) under which the mind is more focused and more apt to achieve that with which it has been tasked. 

What is a harder thing to quantify is the morale toll that taking a step away from a task will have. At least for myself, I enjoy the gratification of seeing newly working parts of an app after a long session of difficult concentration, logic, and code. Denying that pleasure for the sake of quality can be a hard pill to swallow. On the flip side, there are health benefits as well, as the body is much more productive having regular rest cycles.

After adding many unit tests, today I found myself cheating a bit. I'm attempting to retrofit tests to classes and methods that are responsible for way too much. So picture class A which is not written through TDD methodology. The new functionality in class B is being written through TDD. What I was able to do was to write good (-ish)  tests for class B, but for class A, I found myself writing way too much setup code.

I'm curious how the process will work out, but I wound up writing somewhat long unit tests to meet the point of the test. The tests are reliant on actions A, B, and C occurring before the actual thing that was being tested. So I wrote some helper methods, but I worry about one thing breaking taking down the tests like a house of cards.

This seems like a no-brainer for more of a BDD style of testing, but only more investigation will tell. One bright note is that code coverage went way up, since tests touched a large number of deeper library methods.

What is it about that last thing you want to get done before leaving that just refuses to make sense & work? You come in the next morning and it winds up taking 10 minutes.

That was the case for me today while trying to reconcile LINQ and a Unit Test. For some reason the code works perfectly in the web app, yet refuses to work (or even give an exception) when seated properly in a test fixture. Hopefully I'll update this post tomorrow stating it was something obvious.

Update: Sure enough, it was. I realized that data contexts were being cached in HttpContext, which won't work in libraries where unit tests are being run (they're not part of a web app after all!). A little Thread Local Storage, and my woes are no more.

In order to make writing unit tests easier, Ayende Rahien has come up with a mocking framework for hte .NET framework. These mock objects "pretend" to implement interfaces, and display expected behavior for tests.

Some resources available for learning the basics are:

• Wikibooks "How to use Rhino Mocks" 
• Using Rhino Mocks to Unit Test Events on Interfaces
• Ayende's Rhino Mocks documentation wiki

I've had pretty much my entire adult life as experience in diagnosing, troubleshooting, and usually repairing various computer woes. The best lessons were usually after catastrophic mistakes (which I committed, naturally).

 When I was about 13, I managed to reverse polarity on a 4-pronged power cord, and shorted out my pc. The magic smoke escaped (it's blue, apparently!), and a loud snap & that burning smell you never want to associate with hardware were suddenly present. Needless to say there were casualties. Surprisingly, most everything survived -- except for the power supply (to be fair, it was mostly dead to start with) and the hard drive. This was when I was heavy into Pascal programming, and I lost quite a bit of computer time. When you're only 13, replacing a power supply and a hard drive take months (the drive was only 40mb, but weighed about 15 pounds). I learned my lesson about polarities, though!

So how does this relate to development? Well, if you write code that performs poorly, there's obvious repercussions. In a similar vein, when code that is not scalable, or scales poorly reaches production, the flaws can become readily apparent. The ideal scenario would be to be able to recognize poor code / poor situations by sight, and have a common plan of action to address them.

Enter "Anti-patterns". These are an attempt to document types of common mistakes seen in the wild, so to speak, and give a sample way to refactor to 'better' code. Someone has actually registered "antipatterns.com", to address some of those concerns. These may be with development, and they also may be with project managment. Not everything is on their site, but what is there is pretty insightful. Check it out here... 

Writing unit tests is the right thing to do to provide regression testing and just provide some proof that things work how they should. They are the safety net that make sure that when you change the facing on the capstone that the rest of the arch won't collapse.

That being said, one does not always get the opportunity to invest the time it takes to get past that big learning curve to make it part of the daily toolbelt. But knowing unit testing will help in the long term, you get the itch to add them after the fact.

The problem is that they're much harder to just tack on as methods aren't guaranteed to be truly granular in their purpose. Methods and classes tend to be responsible for too much. So how can you write tests to cover all of the responsibilities?

The simplest answer is to write to what you know. I know that Method FastCash() logs into my bank account and withdraws $60. So I write a unit test to check a good login, bad login, pad pin number, scenario where I have $60 to withdraw, and a scenario where I'd be overdrawn. Seems like a decent bunch of simple tests for the FastCash() method, right?

Well, by using NCover, you can run coverage reports on your unit tests. When I do this, I discover i'm only hitting 67% of the logic of the FastCash method. As it turns out, there's a third bit of functionality in there -- automatically, it assumes you choose the Checking account. NCover shows you the lines that are not getting hit by your unit tests, and allows you to specifically target those additional scenarios you weren't truly testing.

I was able to put this into good use today while finding some pure business logic classes. That makes it much more simple to write unit tests for as there are minimal dependancies and coupling occasional, and a great opportunity for well defined acceptance criteria. Both make it that area of code a natural fit for unit testing.