I searched MSDN this morning for “ironpython”, and found a CTP had been posted yesterday.  It installs into Visual Studio and makes it possible to write ASP.NET websites using all the dynamic language Python.  This is very interesting as it’s the first dynamic language will full tool support in Visual Studio.

I personally am going to investigate it for use in testing.  If some of my code depends on the system clock, it would be so nice to just fake out the system clock in real-time with the power of a dynamic language instead of having to fake it out with more intrusive techniques such as putting it behind an interface.

Blake put up a post yesterday entitled “Does your code work?”.  Interesting question.  I recommend taking a minute to read it.

I think mock objects themselves are a 300-level topic.  I wish it weren’t so, but from the folks I talk to, the average developer doesn’t use them.  Fakes, stubs, mocks (whatever you want to call them – and I know they overlap, and I understand the semantic differences among them) are critical for testing.  It’s important to isolate code under test, and in order to do that, we have to fake out other classes the current class talks to.  Not all the classes as a rule, but the ones that might give our test unpredictable results.

Phil Haack lays out an example faking an event on an interface.  While I prefer to use plain delegates for my view-controller notification, events are multicast delegates, so the work as well.  Give it a read.

http://haacked.com/archive/2006/06/23/UsingRhinoMocksToUnitTestEventsOnInterfaces.aspx

NHibernate knows when an object under its watch has changed.  As soon as the object changes, it is “dirty”.  Some other changes might cause an object to be dirty as well.  One that my team recently encountered is a cast.  We use an enum of type byte.  It’s only a few items (less than 255), so we use a tinyint in our database.  When our mapping uses type=”byte”, NHibernate casts from the byte to our Enum type when hydrating the object.  This cast is a change because when NHibernate checks the value, it’s an Enum, not a byte. 

To get around this cast (implicit or not), we use the fully qualified type name of the Enum in the mapping.  NHibernate understands Enums natively, so just put in the enum type, and you are off to the races.  Note that if you are using an Enum that is nested inside a public class, you need to follow .Net’s rules for fully-qualified type names.

See MSDN’s documentation for this: 

http://msdn2.microsoft.com/en-us/library/w3f99sx1.aspx

TopNamespace.SubNameSpace.ContainingClass+NestedEnum,MyAssembly

Imagine two scenarios: 

• You build a system where one class is responsible for coordinating actions of many.  This one class may observe many conditions or events and act appropriately.
• Each small event or condition is encapsulated by an object.  You have many classes, but the responsibility of each class is small.  No one class has too much to do.

I call the first scenario “god code”.  This code rules from on high.  This code might have to track multiple conditions in class or global variables to keep track of what is going on.  This code is very busy all the time and has its hand in everything. 

god code leads to overly complex applications.  A remedy for god code is to push behavior down into the smaller classes being worked on.  Empower the smaller classes to take some responsibility for themselves.  They are quite capable. 

I’ve been with my current company for over two months now, so I’m fully ramped up and integrated with my new team.  Since I arrived, we’ve hired one more developer and a tester to round out the team.  Last week we finalized some plans to prepare the application for an huge influx of new features.  The application does about 1/5 of what it needs to do long-term, so we need to be able to add these new features quickly now that we have formed a complete team.  My challenge was to find a way to facilitate that. 

The hump to get over was some of the assumptions that the current application made (and were perfectly valid at the time).  The business had changed direction, but the software hadn’t.  Consequently, new features had to work around the (now false) assumptions.  Adding features became slow, and debugging even slower.

The solution:  rematch the software with the business.  Another way to put it would be that the application was full, and we need to make room in the codebase for new features.  This means a lot of new code.  It might sound alarming at first, but typing the codes isn’t what takes so long.  What takes so long is hashing out the design.  Yes, the code IS the design, and the code is what is important, but I would argue that the code is a mere textual representation of the design.  You can’t have code without design.  Typing characters in the IDE is very fast when the design is known (because one can see the text in one’s head before typing the words).  The design has been hashed, changed, and rehashed over time.  It’s been refined and tested, so now that it is known, the code representing it can by typed very quickly in a manner that leaves ample room (i.e. loosely-coupled) for new features and changes down the road.

We can’t throw away code!  We spent a lot of money on that code!!!

The above statement is a fallacy.  The company spent money designing, not typing.  The level of communication required with business partners was the majority of the costs.  Technical design and whiteboarding is some cost.  The typing was cheap! 

In my first three installments of this series, I discussed:

• Eliminating waste
• Dodging as much work as possible
• Using powerful tools

Please read these first three to get the full context.

Part 4: Constantly Improve the Design

The inverse of this guideline is to never improve the design.  Sadly, I’ve seen my fair share of systems where the design is never improved.  Instead, new features are wiggled into the existing design, even though there really wasn’t room.  I’m sure you, the reader, can recall an application that grew on it’s own without a critical eye on the evolving design, and eventually, the application is bankrupt and has to be rewritten.  I like the analogy of the credit card.  There is only so much you can charge up on the card without paying for something.  If the indebtedness continues without restraint, financial bankruptcy occurs.  In America, law allows the wiping of debts and a fresh start (with horrible credit).  In software, every shortcut is a charge to the credit card.  Every feature added “around” existing code (because of fear of changing existing code) is a charge.  Every assumption proven wrong, every unrealized assumption, every smelly class, every method with a cyclomatic complexity above X (pick your threshold) is a charge to the application credit card.  The design left to itself will run up a huge technical debt and eventually max out the credit card.  At that point, even if you try to pay down the technical debt, the payment will be less than the monthly interest charge, and the battle is lost.  At that point, management calls for a rewrite, and everyone rushes in to write another application. . . using the same habits and techniques.

Recognizing Design Decay

It’s quite easy to recognize design decay.  Refer to this article on code smells for a little background.  If you smell something in the code, don’t be afraid to investigate.  Look for the root cause of the smell.  If the smell is duplicated code, look for a way to refactor out the duplication.  The key is to identify the design problem so that it can be discussed.  In a team environment, it’s important to discuss smells as an opening for improvement.  Weird bugs are another symptom of design decay.  If the system attracts strange bugs caused by unrelated code in other parts of the system, there may be unintentional coupling.  Confusing code is a smell.  If you can’t look at the code and know what it is doing, it may be rotten code.  Well-designed code will read like a flowing sonnet to a programmer.  Decaying code won’t read at all and has to be stepped through (in a debugger) just to get a feel for what purpose it serves.  For those not using Resharper (for C#), you don’t know what it is like to know exactly who is calling a particular public method all the time.  You do a compile to find things wrong with the code.  Do a small experiment:  download the Resharper trial and open an existing solution with it.  Next, go through the code file and go through the warnings Resharper flags.  It will find private method that are dead (not called by anything), member and local variables that aren’t initialized or even used, etc.  Resharper has on-the-fly code checking to keep you safe from most code bacteria so that you can focus on the actual design.  In conclusion, always be on the lookout for code that is calling out for improvement.

Don’t Fear Code Changes

In many programming shops, this is easier said than done.  If your software has not automated tests, there is cause for fear.  You have no feedback.  If you make a code change, it might take a long time for you to know that the change didn’t have any side effects.  Fear of changing code is a design smell.  It means that you don’t fully understand what the code does.  If you understood completely what the code does, it would be trivial to change it.  The solution to this is to implement practices that make this fear go away.  If you had test coverage for the code in question, it would make it easier to change.  If the code were simpler (a 10-line method instead of a 300-line method), it would be trivial to change.  Not fearing code change might not be an option when confronted with a mountain of technical debt, but conquering this fear is key to producing the software world.  Applications that are write-only end up rotting and dying.  Software that is easy to change can endure for a long time.

Ruthlessly Refactor

Use every opportunity to improve the design of existing code.  Even a little technical debt is bad and incurs interest charges.  Refactoring is not an investment in your code, it is a payment.  Slinging code on the credit card runs up technical debt.  Refactoring actually pays for it.  Paying as you go is the best balance for a sustainable software product.  Refactor to get your technical debt to zero, and constant refactoring will ensure your monthly balance is paid off every month even if you do encounter a small amount of technical debt from time to time.

Improve the Design

Wasn’t that the point of this article,  you say?  Yes, but it is hard to do if you are used to living in a world of technical indebtedness.  Your team may be so busy producing code that you don’t have time to improve the way to produce code.  <analogy>A lumberjack sawed away at a tree all day.  Another sharpened his saw after every tree and delivered several trees in a day</analogy>  The smart lumberjack took time to improve his methods and saw productivity soar above his peer.  Are we sometimes to busy doing things that we can’t find time to improve the way we do things?  This is counterproductive.  Producing software has to include constant retrospection to identify things that need to be improved.  If aspects of the software are hard to work with, take the time to improve that portion of the software so that you can move more quickly through it.  We can talk about improving the design all day, but eventually, we actually have to do it, and it may include throwing away or replacing some code.  Don’t consider this a loss.  Lines of code don’t cost anything.  They just represent the design ideas that you spent so much money fleshing out.

Research and Development

Car manufacturers have entire departments dedicated to finding better ways to do things.  If a car company spent all its resources producing cars and no time finding better ways to produce cars, it would quickly go out of business.

Apply this lesson to your software team and constantly improve your design.