Mark basically said don’t mock external dependencies SUCH AS Hibernate.  Not any external dependency.  Without getting into the functional versus unit/mock testing discussion I agree with Mark.  Why write tests for an ORM. It should work.  That’s why we use ORM’s.

The TypeMock guys butchered the whole thought though suggesting that Mark should have a DAL that Hibernate uses.  Isn’t the beauty of ORM’s that is generates the DAL for you?  I really don’t know where they are coming from with these thoughts – but it’s not helpful from a company that makes mocking/type isolator frameworks.

My advice to TypeMock: take a stand.  Say it should be done one way or another, or, if you don’t understand ORM’s like hibernate don’t speak on it.

The development team may feel rushed to produce because the process for project prioritization is loose.  Once this happens a development team can begin to form dissonant beliefs – for instance, that no one understands their plight.

Since development work is highly specialized (i.e. there isn’t a career path from help desk to software developer) development team members can have trouble expressing their frustrations to others outside the team.  And when these producers of work become frustrated their level of dissonance can increase exponentially until they see it as them against everyone else.  Or, really, the beginning of the end.

At the same time another team, like marketing/advertising, can tell themselves that the campaign they are working on is all-important.  Maybe, in their minds, it is an immediate trump card to developer objections to time or effort.   Many non-technical teams see software as being construction only. They fail to recognize that software, though analytical, is still just a communication game – like the rest of business.  But, if the advertising team truly believes this, how can anyone argue a counter position without causing the other to be wrong.

Both teams spend too much time looking out and laying blame rather than looking in.  At the same time, both teams feel that what they do is the most important – but how can the teams be the antithesis of one another?  Wouldn’t that just lead to disaster?  Yes.

They both miss business goals by focusing only on each other and not what they can improve.   Is a new marketing campaign a success if they just sacrificed or compromised their architecture, personnel etc.  Will that ROI get measured?  On the other hand, is the platform upgrade a success if they missed two marketing goals in a row?

Sometimes, A occurs.  And sometimes B occurs.  Trying to figure out why is a losing game because narrating past experiences only takes into account a single viewpoint.  It’s a fallacy.  So, don’t waste time trying to figure out why you can’t execute.  Focus on executing.

But – he’s still a regular guy. A software engineer. A developer. A coder. Here is why.

I attended a “Friends and Family” ThoughtWorks event at their headquarters in Chicago. The ThoughtWorks office is on the 25th floor of the ever imposing Aon Center building, which as some know, is a twin to the now gone World Trade Center buildings in New York City.

Their office space is designed to do two things: 1) induce violent jealousy of cube workers, and 2) show that they are hip coders and like Ruby. Since ThoughtWorks is a consultancy no one is ever there though. And if they are, you wonder what is wrong with them. However, they get to wear Puma’s, hoodies and generally expensive (a.k.a. designer) jeans. I wear “slacks”.

I attended a TW event before, so I had a general idea of the flow. For instance, I knew they would have some pizza so I didn’t cram my lunch in before I left. I also knew there would be mingling which I was ready for this time. I expected to schmooze with some developers at the CME or some random interactive shop.  Instead, there he was – Martin Fowler – just walking along. So I engaged him and it went something like this:

Me: “I love your books. I live by Refactoring.” (I’m a fanboy.)
Fowler: “Thank you.” (What else could he say?)
Me: “What are you thinking about nowadays? Like today? What’s on your mind?”
Fowler: “Well, really, I have a problem with my website and I need to fix it. But I have to be here as well. It’s small, but it’s bothering me.”
Me: “Your website?”
Fowler: “Yes, there is a style issue.”
Me: “On your site?”
Fowler: “It’s minor, probably just CSS really.”
Me: “But annoying?”
Fowler: “Frustrating, yes.”
Me: “So, let me get this right, Martin Fowler is concerned about CSS on his website. So, in that way you’re like all the other software engineers here leaving some problem behind at their desk to be here…”
Fowler: “Very much, except, I don’t do any real work besides writing and talking.”

And so it came and went.  I didn’t occupy him much longer with additional inane questions and politely excused myself so he could do his expected mingling with the crowd.  After all, even though there was a panel, most people were probably there for him.  Like me.  I paid 8 bucks to take a cab across the Loop to see him and I hoped that shaking his hand would impart some type of wisdom via osmosis to my software skills.

So, he’s just a regular guy.  I’m probably not that different in circumstances than him when he really started rolling in the 90’s.  He has great ideas and the ability to make complex problems simple.  But, at the end of the day, little things like CSS still weigh on him; a web page not displaying correctly or a function not being optimum.  Stuff that software engineers are concerned about.  Like me and like him.

While on CodingHorror I was reminded of the vulgarity that anonymity creates and the attitude of so many people in our industry. They just don’t give a crap. They don’t care that they don’t know how to code, that there is a difference between awful design and good design. That objects actually help refactoring and they aren’t blob classes. They couldn’t care less. Here is an example:

From codinghorror comments
http://www.codinghorror.com/blog/archives/000856.html

There’s one thing you can do trying to keep up with progress or code like you always did. If you started in maybe Fortran, Basic, VB, ASP or maybe PHP – you continue to script your code in good old plain procedural programming. Too much OO slows you down…
New shiny thing,,, i don’t give a damn – I code it like I used to, get the machine obey my will, not the other way around…
And you don’t get more paid if you code spaghetti or nice code when your boss asks for results, time is money!!!
Ideals are good in a perfect world – I could say the search for programming utopia or something…

Would anyone want this guy on their team? He purports that he speaks for management…that they don’t care…well, they just don’t know he is sinking their software deeper and deeper into the mud.

So, I feel it’s my responsibility to warn you in Jeff Atwood fashion of this pariah. BEWARE!

They will leach onto your project, or you, and pull you down. They will undermine your work, the progress you make or anything you do in the name of progress, or heaven forbid, process. And it will all be stated in a backwards apologetic standard: “one design isn’t better than the other” or “200 line methods are fine, it can’t be done any other way”. And, one of my personal favorites “no time for TDD. No time, no time”.

It’s all stated in a pedestrian manner until you begin to peal away at the onion. “Hey, can’t we all get along. There is no black or white – just gray”. Unfortunately, as in real life, there is black and there is white. Billy is white and Sam is black. Deal with it. In software these folks will seriously suck the ever loving life out of you and then move on with their indecision, ignorance of the industry and belief that all things are equal.

Beware.

IEdcFinder

It needs to be composed with one of a few data lookup methods. Like a method connecting to SQL or a method connecting to XML.  I don’t want the caller to have to configure this finder object with the data method.  I’d like to make it easier.  Especially since this finder object is already being injected into another class as a pluggable object.

So, logically, move the construction of the finder to a factory method and compose the data method with it then.  I created a Factory class:

class EdcFinderFactory

But then, we have another class doing work.  So, with TDD, I switched the interface to an abstract class thinking I could use inheritance to mark all subclasses with a private constructor as well – and made the tests pass.  Good.

I was feeling OK about how things were going, but not thrilled.  I had working code but something smelled.  I realized something: there is only one class implementing IEdcFinder and that is EdcFinder.  Let’s remove duplication.

Remove: EdcFinderFactory
Remove: IEdc

(There were actually many small steps in here making sure the system still passed.)

Left with:

EdcFinder
public EdcFinder(){..}
public Create(){…inside here we create an EdcFinder composed with IReadSomeData}

So, EdcFinder became a simple concrete class with it’s public constructor and the factory method.  And, as always, I ran the tests: Pass.  Then the constructor was marked private. Pass.  Remove the old abstract class (which was an interface to start with).

Now there was less code, less interfaces and easier to read code.  I was able to implement the “Replace Constructor with Factory Method” refactoring in just minutes and I know everything still works.

With TDD and my test suites I could change with out fear.

And two days later, I looked again  and removed this entire class realizing it was unnecessary and the data method could be simplified with Func<T>.  I switched everything in about an hour. Red, Green, Refactor.

Bon.

He’s worked at the same project for the last 11 months and management tells him the end is in sight.  His inbox describes an alternate view:
Defect #234 -New- Wrong font color in IE 6
Defect #188 – Reopened- Pricing is incorrect

Brandon’s usually up beat, but he has seen nothing but build reports and defects for months. His stake-holders haven’t even been reviewing key features – they’re waiting for the magic release where all feature are included and everything works according to a document that some managers have signed.

Starting QA after 10 moths didn’t feel like a success.  Nor does closing 30 defects in two weeks.  And now, as the winter starts, he can only look forward to shipping the 50,000 line project on a cold weekend.  It will feel good. Right? To be done with it.  Right? Wash his hands.  Move on.  To the next…project…

This isn’t an unusual case.  Even with supposed agile practices catching on, organizations like to hold scrums for the development team but the stake-holders choose to wait until it’s complete.  Even with the idea of software being complete an oddity and undefinable end point.  Yet, they’ll wait.

This outlook on software development has caused the most pain for the Brandon’s of the industry because there is a lack of incremental satisfaction.

Nassim Nicholas Taleb sites the idea of hedonic happiness in his book, the Black Swan, to examine the idea of hope in light of big singular rewards.  Meaning, many small rewards have a much greater effect on our overall happiness then one or two big ones very far apart.  This is called positive affect.  Taleb’s example is financially driven, but excellent.  Simply, a person will be happier making $100,000 a year as opposed to making $1,000,000 every ten years.  The amount of tension and angst for those ten long years can not be recouped with the big payout – especially if it might be another ten years until it happens again.  As humans, we’re simply not wired up like that.

This fits perfectly into the not so modern realm of software development that 90% of organizations participate in.  Remember Brandon waited 11 months before a release.  He waited 10 months until someone would even begin verifying his work.  Therefore, there were 10 months of effort without any reward.  If positive affect is indeed a true nature of humanity, then long development cycles are like a 30 story ledge that developers stand on crying week to week while looking at the cars below.

The Orwellian similitude’s carry on.  The ruling “Party” of 1984 used doublespeek as a way to control the masses;  simultaneously accepting as true two mutually contradictory beliefs.  I’ve see this in places I’ve worked – and I’m sure I’m not alone.  For example, the requirement is to be agile and to release all features at once.  To do incremental work, but not test until all increments are complete.  To look at iteration plans but not really care unless a feature might not make it at release day.

Are these contradictory? Indeed.  Are they agile.  Of course not.  We don’t have to wait for a solution.  It’s already been invented and bigger organizations can take advantage of it – if they will invest in a mindset change that iterations of the product and each one should be complete.  It’s going to take more training and experience for a stakeholder to really understand that an iteration is planned to be a deployable piece of work and not the subgrouping of tasks on a Gantt chart.

I won’t belabor the incremental, agile, continuous integration points.  The amount of literature and case studies is staggering. However, I’ll continue to make a case for the Brandon’s of the world.  Give Brandon some wins.  Schedule QA of the first iteration (even two iterations) of the project so that it’s in a deployable state. Then, and this is acrimonious to some, release it.  Actually, physically release it.  Then start the next set of features.  Help our Brandon’s feel the little frequent successes that nature makes us crave and then watch the productivity of a motivated software team soar.  Use positive affect to the advantage.

George Orwell’s 1984:
“To tell deliberate lies while genuinely believing in them, to forget any fact that has become inconvenient, and then, when it becomes necessary again, to draw it back from oblivion for just so long as it is needed, to deny the existence of objective reality and all the while to take account of the reality which one denies”

My talk was an expanded and more implementation specific version of my article that published in DDJ this summer. I try to make it fun – not everyone finds managing application lifecycles exciting. In the end I hope the attendees left with a better understanding of what managing an applications life from idea to maintenance means for an organization – and how it doesn’t have to be a yawner.

One can be wrong in myriad of ways.   There is fault in attitude, fault in actions, and fault in opinion – with Test Driven Development I was wrong on all three.  Gentle reader, following are the ways I wronged TDD and myself:

Ways I was wrong:
1. The way I write software is fine.
2.  I write complicated software – this won’t work here.  Object composition and encapsulation precludes TDD’s success.
3.  This will slow me down.
4.  It’s a fad.

Let’s dissect these.  My attitude was prideful (1); my abilities do not need improvement I told myself.  This is the sweet trap of stagnation we knowledge workers lay for ourselves.  Spending so much time creating models in our heads and expressing ideas in a language for machines ripens the opportunity to see our reflection as Turing, Beck or Fowler.

The applications I build are anything but trivial (2).  Is this a true statement?  Sure.  Not yes – aren’t most applications complicated?  And how would one consistently define one system as being more complex than another?  I could do it via lines of codes or cyclometric complexity – but that isn’t really what I told myself.  In fact, I belittled TDD as too small for the job because of my boastfulness stemming from fault number one (1).

Asking the question “will this slow me down?” is a trivial scapegoat for avoiding doing any task better (3).  This one is endemic of human nature because it’s difficult to argue the counterpoint – of course doing something new will be slower at first.  So does drying the dishes before putting them away, but the average domesticate prefers their cabinets not moonlighting as mold spore factories, so they will wipe that Crate and Barrel flower pattern down.

A couple months before I noted to write an essay on the benefits of TDD I planned a counter thesis – TDD is a fad (and it sucks)(4).  Yes, gentle reader, as egregious as it sounds I was quite comfortable in my anti-TDD stand; after all I was deluding myself with points one, two and three.  In fact, I reacted from cognitive dissonance; if I don’t write software well then TDD can not possibly be of benefit. Stated inversely: if TDD works there is something wrong with the way I write software. That kind of conclusion is demoralizing and my brain rejected it before I could even fully consider the implications.  I rejected TDD  to keep my ego in place for the job I spend my days contributing to.  This of course, led to confirmation bias (Nicholas Taleb terms this platonic confirmation in his book the Black Swan, http://www.fooledbyrandomness.com/) as I sought out evidence – again, the first three points – on how I was right and the TDD crowd was wrong.

If you can’t teach an old dog new tricks, like your author, it’s like pulling water from a rock to help a developer change a habit.  Now, tell them to not write cod and then test, but to write tests that write the code.  My struggle persisted.  So, I looked at the advantages – which are numerous.

Advantages

Advantage #1 – Consumer Friendly
Aesthetics are more a part of coding than the secretly vain development community would like to admit.  What is the class named?  Does it take the correct parameters?  Is it a subclass of something else?  All these things are figured out iteratively because the test is the code.  In order to write the test “GetAccountNumber” you write what you would like to see in your code.

public void Test_GetAccountNumber()
{
IAccount account = new Account(44444);  //this class does not exist yet!
int a = account.GetAccountNumber();  //this method does not exist yet!
}

This idiom of works produces more readable code because it’s already been thought out and used before it ever hits the application.This is synonymous to building UI first for a UI app.

Start with the consumer.

Advantage #2 – Interface Based Development
Entire books are written on interface based development.  Composition is preferred to inheritance and interfaces are the way to compose your objects, therefore interfaced based development is preferred.  Writing your tests first give you the opportunity early on to program to an interface, saving much grief later on.

Advantage #3 – Prove it works the first time
As humans we look for ways to avoid pain and injury.  Which hurts less:  a) writing a method called GetAccountNumber and testing it to fill a drop down on a web page and watching the drop down render as empty, or b) run the unit test for the method and watch it pass or fail.  It is infinitely easier to debug the unit test.  The only parameters for the method GetAccountNumber in the unit test are what actually gets passed to the method; like the primitive number 413.  The parameters for testing the method in the web page are the entire context of the web page – possibly the entire site – as any number of run time errors can occur while manipulating other elements.

With TDD, the chances of success the first time a method or class is used in an application greatly increase and application debugging goes down.  They are inversely proportional.

Advantage #4 – Proof it works after changes.
No matter if the program is a flight simulator, a line of business app or a huge e-commerce platform, all programers struggle with using their classes after they’re written.  Even with some up front class modeling, the first time a class is used is almost always a disastrous event.

For instance, let’s say the class built is called Mortgage. It looks like this:
class Mortgage
{
public Mortgage(datetime startYear, dateTime endYear, double loan)
{
….
public datetime GetStartYear()
{
…
….

This is all simple enough.  The Mortgage class is plugged into an existing web app and the methods that it exposes are used by this application. Again, this is the normal course of events for software development the world over for the past, say, 30 years.

Just a week later  a new application feature is needed to calculate the amount of interest paid for the length of the loan – which requires knowing the interest rate.  Notice though, interest rate was not past in though the constructor.  There are now two options – 1) overload the constructor with a new version that accepts the interest rate or 2) expose a public property to set the interest rate.

Option 2 does not sound very elegant and can lead to object state issues as the object is not created atomically with all the data it needs to perform it’s behaviors.  So, the new GetInterest method could be called and throw an exception because it does not have the data it needs.  (I’ve done this…it was a really, really bad idea.)

Option 1 sounds like a golden parachute over the later option.  So, the constructor is overloaded with a new version:

public Mortgage(datetime startYear, dateTime endYear, double loan, double interest)
{
…

There are now two constructors for this object, and they need to stay this way for the time being because the Mortgage class is already used in 5 different places in the application.  In fact, Joe Developer is using the Mortgage class with the first constructor and adding new methods to the class.  Looking at that fact, it’s thought best not to change that first constructor because who knows what may break, or worse: misbehave at runtime.

The new Interest feature is now coded and approved by whomever approves these kinds of things and everyone is happy – until iteration 3.  A routine that Joe Developer coded needs to slide that Interest number into a grid.  Joey D thinks “no problem” and calls the GetInterest method: bang, dead.  It blew up.  There isn’t an interest value in the object because he constructed his object with the original constructor.

This could have been avoided by simply eliminating that first constructor which was leaving the object in an invalid state when the GetInterest method was added.  But that was scary.  Since there weren’t any tests on the methods of the Mortgage class it was deemed to risky to change the places where the first constructor was used and now every developer from this point on will run into the same problem.  Of course they can now decide to alter all the instances of the first constructor in the application – but the damage was already done; defects.

Advantage #5 – Make the Brownfield easier to navigate.
As a professional we usually work in environments we did not bootstrap ourselves.  The environments are preexisting and have characteristics of their own.  Often, the code isn’t even legacy – it’s just there.  Any environment like this is referred to as a Brownfield and means integration work.  Integration is difficult because analyzing what may break with new or upgraded features can’t be seen until functional testing.  Writing tests first in a Brownfield will make your life easier – and the guy who comes next.

Advantage #6 – Be a professional – take responsibility for your product
Simple economics dictate the likelihood of having a tester for every coder is the same as successfully writing software using a pencil.  Writing tests that prove code works before testers touch it ups the quality dramatically.  It’s a way to take responsibility for the product being created.

Advantage #7 – Have fun.  Red, Green, Refactor.
Remember when writing software was fun.  When you referred to it as “coding” or “hacking out some code”?  Replace your TPS reports with TDD and bring a little fun back into the development cycle.

Doing Test Driven Development means that one small piece of functionality is being written and tested at a time.  It’s written. It breaks.  The code that the test is trying to run is written.  It breaks again: Red.  Tweak.  It passes: Green.  Now that it passes go and make it better.  Improving the code is no longer a fantasy.  It’s easily doable because it’s all covered by tests.  Refactor those primitives into an object or replace conditionals with polymorphism.  Or – this is fun- replace some meddlesome constructors with factory methods.  It’s not a dream with TDD – changes can be made as long as the test go Green.

Advantage #8 -  Sleep better at night
Turn off the monitor(s), grab the keys and go home assured that things are working.  Pretend that it’s Monday and you cranked out the following code; four new classes and ten new methods.  That’s a good amount of new code introduced into an application in one day.  The build succeeded, good, but you’re still not sure that when your teammates get latest things will functionally work.  Now, pretend you had tests over all that new code and they all were Green when you left.  No worries. Better sleep.

Advantage #9 -  End up with better software.
This is really what it’s all about.  Test Driven Development makes your code refactorable, which means it’s easier to change, which means it’s easer to optimize, which means it runs better which is correlated to less defects, less QA and easier releases.  And all that adds up to better software.

Sadly, there isn’t much empirical evidence separating an enterprise ready app from any other piece of software.  A development manager requiring an enterprise developer doesn’t make the role anymore real than an engineer claiming to be a “people person”.  An HP blade server is no more enterprise ready being racked in a enormous corporate data center than in a startup’s cage at RackSpace.  Let’s dissect this hypothesis by looking at two very popular web frameworks: ASP.NET and Ruby on Rails.

Microsoft sits in the interesting position of selling the same software that runs small businesses and large enterprises.  This of itself should be enough to prove the term enterprise a loaded marking term – but let’s keep going: ASP.NET is Microsoft’s enterprise web platform.  It, coupled with IIS, provide everything needed to build dynamic multitiered web applications.  It has optimizations for Microsoft SQL Server, session and cache providers, error reporting, performance tuning, remote configuration, etc.  It can do just about anything a web application in 2008 would require.  Again, Microsoft, pundits and analysts say it is enterprise capable.

On the other extreme is Ruby on Rails.  Note, not just Ruby the programming language, but the Rails web framework as well.  What I’m embarking on is dangerous:  I am not a Rails expert and provide this caveat up front.  Rails is considered by popular opinion to not be enterprise ready.  What does it lack?  As far as I can tell, the only thing it really lacks is a support package, IDE and hordes of corporate programmers.

On it’s own, ROR is terribly productive.  The Active Record design pattern is built right in as a OR Mapper with the friendly and obvious name of “Active Record”.  So, it provides a concise model of objects over data right out of the box (if anything had a box these days).  The framework is based off the of tried and true MVC, model-view-controller, design pattern to provide distinction between data, middle tier and presentation.  This is a simple programming idiom used with GUI development, web applications or the myriad of systems that actually make’s power arrive to substations to power my MacBook (Pro, thank you very much).

I  provide these contrasts between the frameworks to illustrate the futility of using the term enterprise for one group of software products but not for another.  Because it gets better.  Bigotry of platforms like ROR grows as corporate IT software developers feel more threatened.  Hence their managers feel threatened and when Forester Research shows up all they hear is how platforms like ROR are not enterprise ready.  But it’s not a technology stack that is not ready for development in these corporations.  It’s the people.

In the end it’s that simple.  When people are not ready they will search for whatever means to prove their disaffection, dissatisfaction or ignorance about a product to be real when it’s empirically false.  This is why the enterprise is difficult to define: because it’s a constantly moving target through the emotions and minds of corporate software developers.