Tag: tdd

Me on TDD/BDD/Pairing and Jason Fried’s TED Talk and “why work isn’t done in the office…”

This talk is so right, but could it be so wrong at the same time?

Just watch this, that’s all I have to say. Jason is so right about this topic. Here’s a few quotes to convince you.

  • “I’m going to talk about work, and why people can’t seem to get things done at work…“
  • “If you ask people the question, “where do you go when you really need to get something done?” you typically get three different types of answers; one is a kind of a place, a location or a room, another is a moving object, a third is a time…“
  • “The Train”  <  – That one caught my fancy, if you’ve ever talked to me about transit you know that one caught me…  🙂
  • “What you almost never hear people say is “the office”“
  • “Managers and bosses will tell you the distractions at work are things like Facebook, Youtube…”  “…and they’ll go so far as to ban it…”  “…what is this China?!”
  • “The real problem in the modern office is the M & Ms”   <  –  Oh hell yeah, so very true.
  • “Manager’s jobs are really to interrupt people…” “…they don’t really do work so they have to interrupt you.“
  • “You would never see a spontaneous meeting of employees, no, managers do that…“

To summarize, do telecommuting right, and it will absolutely blow away anything that is ever accomplished “at the office“.

Oh my Adron, you’re such a hypocrite! You are always talking about TDD and BDD and Pair Programming and teams being together and…

YES! You have a point, so let me throw this prospective hypocriticalness of mine away and prevent any concern that I’ve missed a logical connection. I assure you, I haven’t.  🙂

I do support people working remotely. I also love to have a team close together with high communication (and here’s the catch) that is focused on the problem. This is what Jason is talking about! People generally don’t stay focused in cross-cut teams, with this focus and that focus and then throw managers on top of that. The next thing you have the dreaded M & Ms dramatically decrease any chance of work getting done.

If a team can be left to their work, especially if they have clear problems to attack, to pair on, to write tests against and to implement this is the precise example of why to work together. However, I’ve also seen successful, very successful teams working together remotely. Jason & the 37signal’s crew have done that before! They’re a prime example of it.

But How Does Remote Work, Work?

You have to be disciplined, you have to have check in points, but take 2-4 hours at a chunk and do work! Use e-mail and instant messaging as Jason points out. These are the keys to successfully getting things done! Where I currently work, we actually get this type of allowance. We even do remote pairing (albeit rarely, but it has been done)!  It can work, and it can work very well. However we often break away and have time chunked where we don’t talk, but instead leap forward in our efforts to get work done. Sometimes we pair, sometimes we don’t, it generally depends on if we’re writing code or just getting configs and databases put together to write code against. No reason to pair on a configuration file!  😉

So really, the key isn’t to be physically collocated, or that you have to be remote to each other. The key is to have communication, high levels of communication, but at the right moments in time! The communication must be focused and to the point. It much bring information that is needed, not long drawn out meetings of vacuous boredom and emptiness. The work is done when someone, or a pair, can focus on the problem at hand and find the solution to that problem – alone or with their pair. These are the keys to getting real work done!

Thanks TED Talks for getting me all fired up this morning!  🙂

Urban Lean Agile Tech Breakfast Meetup, Be There This Wednesday!

Are you hard core into technology and software development like Node.js, JavaScript, Ruby, Rails, .NET, Java, Clojure and more?

Do you like the ideas behind the agile manifesto, lean startup, kanban, and thinking outside of the box?

Are you digging that ASP.NET MVC Framework or waiting for the next ALT.NET meetup?

Loving that ease of Ruby on Rails to wow your user base with ease, to implement with Sinatra those clean JavaScript & jQuery enabled UX for your clients?

Want to talk shop, eat some grub, have a beverage, and get a nerd kick start in the morning?

In that case meet us for Urban Lean Agile Tech Breakfast Meetup at Mod Pizza @ 1302 6th Avenue @ 8 am on Wednesday, August 3rd.

Windows Azure SDK Unit Testing Dilemma — F5DD Plz K Thx Bye

I’m a huge advocate for high quality code. I will admit I don’t always get to write, or am always able to write high quality code. But day in and out I make my best effort at figuring out the best way to write solid, high quality, easy to maintain, easy to read code.

Over the last year or so I’ve been working with Windows Azure (Amazon Web Services and other Cloud/Utility Platforms & Infrastructure also). One of the largest gaps that I’ve experienced when working with Windows Azure is the gross disregard for unit testing and especially unit testing in a Test Driven Development style way. The design of the SDK doesn’t make unit testing a high priority, and instead focuses mostly on what one might call F5 & Run Development.

I’ll be the first to stand up and point out why F5 Driven Development (for more on this, check out Jeff Schumacher‘s Blog Entry) is the slowest & distracting ways to build high quality code. I’d also be one to admit that F5 Development encourages poor design and development. A developer has to juggle far too many things to waste time hitting F5 every few seconds to assure that the build is running and code changes, additions, or deletions have been made correctly. If a developer disregards running the application when forced to do F5 Development the tendancy is to produce a lot of code, most likely not refactored or tested, during each run of the application. The list of reasons to not develop this way can get long pretty quick. A developer needs to be able to write a test, implement the code, and run the test without a framework launching the development fabric, or worse being forced to not write a test and running code that launches a whole development fabric framework.

Now don’t get me wrong, the development fabric is freaking AWESOME!! It is one of the things that really sets Windows Azure apart from other platforms and infrastructure models that one can develop to. But the level of work and effort makes effectively, cleanly, and intelligently unit testing code against Windows Azure with the development fabric almost impossible.

But with that context, I’m on a search to find some effective ways, with the current SDK limitations and frustrations, to write unit tests and encourage test driven design (TDD) or behaviour driven design (BDD) against Windows Azure, preferably using the SDK.

So far I’ve found the following methods of doing TDD against Windows Azure.

  • Don’t use the SDK. The easiest way to go TDD or BDD against Windows Azure and not being tightly bound to the SDK & Development Fabric is to ignore the SDK altogether and use regular service calls against the Windows Azure service end points. The problem with this however, is that it basically requires one rewrite all the things that the SDK wraps (albeit with better design principles). This is very time consuming but truly gives one absolute control over what they’re writing and also releases one from the issues/nuances that the Windows Azure SDK (1.3 comes to mind) has had.
  • Abstract, abstract, and abstract with a lock of stubbing, mocking, more stubbing, and some more abstractions underneath all of that to make sure the development fabric doesn’t kick off every time the tests are run.  I don’t want to abstract something just to fake, stub, or mock it.  The level of indirection needed gets a bit absurd because of the design issues with the SDK.  The big problem with this design process to move forward with TDD and BDD is that it requires the SDK to basically be rewritten as a whole virtual stubbed, faked, and mocked layer. Reminds me of many of the reasons the Entity Framework is so difficult to work with for testing (has the EF been cleaned up, opened up, and those nasty sealed classes removed yet??)

Now I’ll admit, sometimes I miss the obvious things and maybe there is a magic “build tests real easy right here” button for Windows Azure, but I haven’t found it.  I’d love to hear what else people are doing to enable good design principles around Windows Azure’s SDK. Any thoughts, ideas, or things I ought to try would be absolutely great – I’d love to read them. Please do comment!

My Current Windows Development Machine Software Stack

I recently did a clean install of Windows 7 64-bit.  It had been a really long time since I listed the current tools, SDKs, and frameworks that I’ve been using.  Thus here’s my entourage of software that I use on a regular basis that is installed on my primary development machines.

Basic Software & System OS

Administration Utilities

Themes & Such

In addition to these packages of software another as important, if not more important to my day-to-day software development includes these software services and cloud hosting services.

SaaS, PaaS, and IaaS

Software I will be adding to the stack within the next few days, weeks, and months.

Anti-Test Driven Development Arguments and Myths

Ok, I have run into the anti-TDD arguments on and off over the years.  Generally it comes from two primary sources.  The person who doesn’t want to do TDD no matter what, nor test, nor learn anything about the latest and greatest tech, they simply want left in their corner of the universe to code whatever they are coding until they drop dead.  Then there is the other individual who is a decent developer, but just has honest hesitations about the style.

The developer who has honest hesitations I can understand, can talk to, and can usually at least get a “Well, that sounds reasonable, but I’m still not sure” response.  Which is much better than the alternative of disregarding TDD outright.  The hope, is that this individual can at least try out TDD and see if it would work for them.

Even with the more open minded developer it is still difficult to put TDD into practice.  Why?  That’s simple, TDD is hard and forces a developer to step back into the basics and really think the problem through first.  Most developers (at least currently, maybe it’ll change) have a very “just attack the problem with code” type of response.  Often the way to break down problems is taught in computer science 101 level classes, but after that is often lost in all the cramming for math, algorithms, and other such material.  But the core fundamental idea of thinking the problem through clearly still needs to be broached.  TDD puts that idea forefront in the process by making a developer write the test to verify the problem statement first.

With all this stated, there are a few myths that I’d like to bust.  These myths are often what cause the first person to cringe away cowardly in their corner of the universe, and causes these hesitations in the second more open minded developer.  After busting these myths I’d hope more of the open minded developers can use the power and thinking that TDD encourages.  As for the first corner cringing coder, they’re a dying breed and I wouldn’t bet on their recovery.

The Myths

  • MYTH: But I can’t test every single thing that is written, so TDD just isn’t for me.  The reality is, you can’t test every single thing and you shouldn’t.  You should stick to the logic, business process, and other parts of the code.  Don’t worry about the configuration, individual database nodes, or other arbitrary or configuration based bits.  The idea is to make you think through the problem spaces and architecture needed to work through those problem spaces.  So TDD is still something you should try, but don’t try to test every single line of code.  Focus first just getting through the logical, flowing, business related bits of the code you are writing with tests first.  This will get you appropriately experienced with TDD.
  • MYTH: You can’t test against boundaries, that becomes an integration test, so why even mock/stub/fake if I’m not testing the real framework/parts/features?  Again, why worry about testing parts that you know or are not responsible for?  Don’t test the integration parts.  There is a reason QA exists, and defining and testing boundaries is what QA does great.  But you still need to test and confirm that your code works against those.  Mocking or stubbing against that gives you the confidence that your code logic will work against these integration points and also provides you a basis in which to work off of.  If you write the tests first, you also know you’ve thought through these integration points to a fairly thorough level.

Do you have anymore myths that should be burst?  Please feel free to toss a myth or two to burst in the comments, I’d love to hear others input on the matter.