Continuous Thinking - Home

Daniel Parker accident

2010-05-17T01:54:00Z

Daniel Parker, a colleague, friend, and coworker of mine passed away this evening. Daniel was competing in a triathlon on Friday night when he got into a biking accident. Daniel was airlifted to the University of Michigan hospital and underwent two surgeries between Friday night and Saturday, but during the second surgery they stopped because it wasn’t helping Daniel’s condition.

You may know his name if you’re a developer, because so was Daniel. You may know him from his work with Quickbooks and Ruby or maybe his GMail rubygem or one of his many other projects that he authored or contributed to.

You may know him as a Christian, because so was Daniel. While he wrote code because it was fun and he was quite good at it, he first and fore-most lived for the Lord.

You may know Daniel as a fervent competitor with a kind heart and a powerfully analytical mind. You may know Daniel for a number of other reasons, and if you didn’t know Daniel then I assure you, if you did, he would have left nothing but an impact of an honest, energetic, intelligent, warm hearted, analytical, yet loving person.

I knew Daniel because of his work in the Ruby community and in the Ruby community in the midwest and specifically Michigan. Last fall I attended GRGivecamp with Daniel. Four months ago, Daniel came and began working with me at Mutually Human Software. Daniel and I worked closely together for about 30 hours a week every week. Every day we’d pair program (or party as Daniel would call it). Almost every day we’d eat lunch together and talk – sometimes about work and sometimes about everything else in life. I never imagined that four months of my life with someone could have such an impact. That’s also the kind of person Daniel was – impactful in all the best ways.

Before I had ever met Daniel personally, my colleague John Hwang had told me that he was the kind of person we wanted to work with, not just the type of developer, but the kind of person. At first I was skeptical, but after I met and began workingw ith Daniel I knew John was right. Daniel was more then just a developer—he was human. He was the kind of spirit and person who anyone would want to build a team around. He was an amazing developer, but even more-so he was an exceptional person. It’s hard to believe that Daniel was only 23 years old.

I will miss you Daniel, as a friend, as a colleague, as a human. May your life go on to impact countless lives. I know you have impacted mine.

P.S. – when you get to heaven be sure to teach everyone Rook, they’ll love it just as much as you did when I introduced it to you. That will forever be a cherished night in my life.

UNIX tee in real life

2010-04-29T02:13:00Z

I wrote a nice little article on using the UNIX tee command in real life. If you’re wanting to see the purpose of tee or learn something new about bash, check it out:

http://mutuallyhuman.com/2010/4/29/unix-tee-in-real-life

Happy coding!

activerecord-import gets basic SQLite3 and PostgreSQL support

2010-04-09T03:44:00Z

A few weeks back I started working on extracting the import functionality from ar-extensions into its own library. The initial extraction involved pulling out all of the MySQL functionality first, test by test, piece by piece. Well, tonight I pulled in the basic support for SQLite3 and PostgreSQL.

While it’s working great for MySQL, SQLite3, and PostgreSQL it has not been released as its own rubygem yet. I expect that to happen in the near-term future. In the meantime you can always check out the project on github:

http://github.com/zdennis/activerecord-import/

In the past folks have emailed about sparse documentation. When the gem is released documentation will be provided by the github wiki ( http://wiki.github.com/zdennis/activerecord-import/ ) and the most up-to-date will be provided in the RDOC itself.

I’ve ran some benchmarks recently against MySQL 5.1 and you can find the results here: http://wiki.github.com/zdennis/activerecord-import/benchmarks

More to come!

ActiveRecord Import Updates

2010-03-12T05:17:00Z

Nearly four years ago I embarked on figuring out ActiveRecord internals enough so I could have a library which allowed me to perform bulk inserts of data in an optimized way based on the database adapter being used. Over those four years, I’ve maintained and updated the functionality with contributions from the community. A big thanks to Blythe Dunham, James Herdman, Gabe da Silveira, Thibaud Guillaume-Gentil, Marcus Crafter, and Mark Van Holstyn.

Now that Rails is nearing a 3.0 release, it’s time for to revisit this import functionality, make it compatible with the heavily refactored and cleaned up ActiveRecord internals (thx Rails core team) and add some more polished features and implementation.

The import functionality which was in ActiveRecord::Extensions is being extracted into its own library, activerecord-import. This library will be smaller and its only purpose will be to provide mass import functionality.

The work has already begun over on github: http://github.com/zdennis/activerecord-import

I look forwarding to officially releasing this in the upcoming weeks!

Binary Chop Shop in Scala

2009-11-03T02:25:00Z

In an effort to start learning Scala again (i started in the summer then got busy) I decided to tackle a simple yet fun code kata from Dave Thomas called karate chop

I ended up using Specs to make sure I passed Dave Thomas’s test criteria. I’m sure my below two solutions (recursive and while loop) are quite clunky compared to someone who’s familiar with Scala, but the goal of this was to get something running and passing. In a week or two I’ll revisit again after learning some more things about Scala and hopefully be able to tidy things up a bit.

Anyways, here’s my code:

class BinaryChopShop {
  def chopRecursive(target: Int, list: List[Int], args: Int*): Int = {
    if(list.isEmpty) return -1;

    val offset = if(args.isEmpty) 0 else args.first;

    if(list.size == 1){
      return if(list.first == target) offset else -1; 
    } else {
      val index = list.size / 2;
      val value = list(index);
  
      if(target < value)
        return chopRecursive(target, list.slice(0, index), offset);
      else
        return chopRecursive(target, list.slice(index, list.size), offset + index);
    }
  }
  
  def chopWhile(target: Int, list: List[Int]):Int = {
    var nlist = list;
    var offset = 0;

    while(!nlist.isEmpty){
      if(nlist.size == 1){
        return if(nlist.first == target) offset else -1;
      }
      
      val index = nlist.size / 2;
      val value = nlist(index);
      
      if(target == value) return index + offset;
      if(target < value){
        nlist = nlist.slice(0, index);
      } else {
        offset += index
        nlist = nlist.slice(index, nlist.size);
      }
    }
    return -1;
  }  
}

Summary of thoughts on data and migrations

2009-10-17T20:16:00Z

I shared a summary of my thoughts today with my project team (we’re distributed, multi-national team)... and I thought what the heck why not share with the rest of the world to. Here goes…

I’m not sure what everyone’s conventions or views are on handling the removal of data in the app that is no longer used, so here are some of the guidelines I follow to help promote sharing and consistency.

Seed data

To load data that has to exist for the application to run, I like to use seed data and I am a big fan of Michael Bleigh’s seed-fu plugin. Seed data should be setup so that it can be loaded at any point during the lifetime of an application. It should not destroy data that leaves orphaned data and it should not duplicate data.

Updating data

I like to use migrations to update existing data. If the migration and data update is complex and irreversible I will add a unit test around the migration because due to the high risk of causing irreversible damage (unless a full DB backup is loaded).

Updating application-required data

When the data that the application depends on changes (ie; the seed data) I tend to update both the seed files as well as add a migration to properly handle any existing data, whether this means removing the data, marking it as delete or inactive, etc.

Updating data

In development modifying data directly through MySQL or ruby scripts is much more forgivable and often very fast and efficient. We have no risk of causing users of the application harm or loss of data. Once something is figured out I like to either add a seed-file and/or a migration if it’s a change that needs to get made on staging and production.

In staging modifying data directly is less appealing because staging is supposed to represent what happens when we go to production. If we have to modify data directly in staging then we’ll probably have to modify it in production, so a migration and/or seed-file is a better place to track the change. I find it tempting sometimes to script/console and modify data directly.

A problem with this is that we risk screwing up staging for folks who are using it to preview features, check out bug fixes, etc. I find it better to dump the database and pull it over to my local development machine. Once I have it I can load it up locally, recreate the issue, and do whatever I need to do to find the source of the issue. This removes the risk that you fill further break staging for any users using it. Once I find the issue if I need to I will add/update a migration and/or seed file.

In production modifying data directly is super dangerous. It’s a change that occurs outside of version control and potentially without being run in development and/or staging which could catch bugs in the updates. The risk of causing irrevocable damage is so high I think doing this should be avoided.

I find it’s always been better to take an extra few minutes to make sure the fix is right and then to deploy, then it is to make a quick fix directly in production and find the change caused new issues. Production should never turn into a debugging sandbox. Pulling over a backup if necessary is safer and allows us developers more freedom to freely change the data to find the appropriate fix.

If you have to use script/console not MySQL

If you find you need to update data directly it’s better to use script/console, then by touching the database directly using MySQL. For example, Scott once asked me to change his user name. Changing his user name was a very low risk change, so I loaded up script/console and made it.

The benefit of script/console is that you let all of the rules and validations inside the application be run when you make the change. If I had made Scott’s username too short, too long, include inadmissable characters I would not find out if I did it directly through MySQL, unless I had duplicated all of the logic in MySQL stored procedures and triggers (which I cringe at the thought of).

Conclusion

Well, that’s pretty much a summary of my personal guidelines when it comes to dealing with data updates, migrations, seed-files, etc. If you have any other guidelines you follow that you find helpful please share. I think being on the same page here will help us as we push forward.

git review

2009-10-01T01:15:00Z

I’ve gotten into the habit of review code that comes down from every other developer, rather than blindly merging in. For a while I was typing “git log master..origin/master” but it became to tedious to type out. I’ve updated my .gitconfig to provide the following alias:

[alias]
  review = !"git log  master..origin/master"

Now I can simply say:

git review

If you want to view actual code changes rather than simply the changelog just add the -p flag:

git review -p

A little nicer.

BDD not so much, really? Part II

2009-05-28T07:38:00Z

I think there’s a confusion that BDD == toolset (ie. Cucumber, Cucumber+RSpec, rspec). That needs to stop. BDD is an approach to software development. You drive your software by focusing on behaviour. This is usually done by focusing on behaviour from the outside-in. This starts by identifying the behaviour of the application, then driving inward until you get down to the low level components.

Focusing on behaviour may yield different tools throughout the process. Cucumber and RSpec are just two examples. You could very well use Cucumber plus test/unit, or perhaps just RSpec, or maybe nothing at all. These are just tools to support a development style. They are NOT the development style themselves. You can use Cucumber in a way that doesn’t support BDD. Same goes for RSpec and any other tool.

I realize there are people who don’t buy into the RSpec philosophy. To them it’s just another take on unit testing. I do buy into RSpec. From day one RSpec’s goal has been to be a BDD tool that tries to get the words right. Can you use xUnit libraries in a way to achieve the same affect? Yes you can, but most of those usages have been heavily influenced by RSpec which was built on the ideas and motivation for BDD and “getting the words right”.

Without this focus many of the high level test/unit style add-ons (especially in the ruby world like context, shoulda, test/spec, etc.) wouldn’t exist. So to me, this makes the subtle differences very important as it changed how everyone wrote their tests.

For me personally, testing is an activity after you write code. I find it refreshing to talk about writing code examples to drive design and tests to talk about actual testing. Perhaps it could be phrased as, you start with examples and when you’re done you end up with tests. Similar to starting with user stories and ending up with features. Right now that works in my head, but it’s late and I may need to revisit that thought after a few hours of sleep.

Example is just a better word then test to. When you talk to someone and you don’t understand what they’re talking about you don’t say, “give me a test”, you say, “give me an example”. Well, that language is more natural. You are providing an example of how something should work. This example ends up providing regression (test) value once its implemented, but you didn’t start with a test, you started with an example of the code you wanted.

BDD not so much, really?

2009-05-28T06:05:00Z

Updated May 29, 2009

This rant is in response to http://robertlally.com/post/bdd-not-so-much

BDD didn’t start off as a replacement for TDD. It started off a way to better understand and explain the process of TDD. The name change as I understand it was to communicate the intent of TDD in a clearer and more direct way. You’re not writing tests for the sake of writing tests, you’re driving behaviour. Focus on the behaviour you want to achieve first and foremost. Use that behaviour as the driving force for your examples (or tests).

Corey Haines nailed it on his comment to the same post, “BDD is no longer a replacement for TDD, but, rather it is a workflow for creating a system that more closely resembles what the client is looking for.” I think two of best tools which exist to support the BDD workflow of outside-in are Cucumber and RSpec. Cucumber for higher level system behaviour and RSpec for driving lower level design.

In the article, the author criticizes the “should” language. Rather than simply scoffing at the idea of replacing “assert” with “should”, I tend to think about it in terms of natural communication. The reason I like “should” language over “assert” language is that when I’m communicating with another developer I don’t say, “assert equal one day to do things good”. That doesn’t make any sense. I say, “one day to do things to should be good”. It’s much more natural for me to write closer to the language I think and communicate than it is to translate it to assertion-speak. I want to communicate in my code more closely to how I communicate to other people.

While the term BDD is a few years old it takes a while for dialogue to happen, and understanding to occur. I’m sure a lot of people hear about BDD, read about it from Dan North’s Introducing BDD . BDD started as a way to explain and better understand BDD, but what I think was realized was that it was much more than simply TDD.

Many tools are emerging which claim to support BDD-style development. It’s important to note that BDD isn’t the tool. You can have many tools support BDD style development in different ways and to different degrees. Although a good tools makes any process easier, what makes BDD is the mindset you have and how you go about writing software. Certain tools emerged with this in mind and are thus labeled BDD tools. Cucumber, RSpec, and JBehave are some examples.

The article mistakingly sheds Cucumber in the light of solely driving the design of code and suggests its a bad tool to do that. Of course it is! It is not a tool intended to drive the design of your code from a low level. It is to communicate in plain text how the application should behave. The plain text is something that is business readable, something that adds value not at the code design level, but at a higher level: communication and understanding requirements!

Cucumber is equivalent to a high level integration test for those of you who come from a testing background. It runs the entire application (or whatever can be reached through automation, different types of systems have different limitations). It works in combination with a tool used to drive out the design of your application using lower level code examples. For example, RSpec.

The #1 output of BDD is a working application that is behaving as expected. In addition to that you have an application-level regression suite in which you can run against the code base at any time. You also end up with smaller, more focused code examples which provide regression against isolated behaviour of the system.

Combined, you end up with documentation at two critical aspects. The first is business readable scenarios that the system supports. The second is developer documentation made up of the lower level code examples. Since these are often written more clearly than assert-style syntax it’s easy to produce human readable behaviour specifications for focused pieces of behaviour. And in the end you have a repeatable process which allows you to confidently produce the working software.

I also don’t see where UML to BDD comparisons make any sense. UML is a modeling language. BDD is more of an approach or methodology. A more accurate comparison would be plain text scenarios vs. UML. Although that makes little sense as a comparison because UML is not something you can give a non technical person to write, read, and edit.

BDD by itself doesn’t fix any problems. It provides an approach which focuses on behaviour first. To me, there’s no point in building a low level library if you’re not aware what higher level problem you’re solving or objective you’re adding value to. This boils down to a person still has to “do the work” to make it successful.

At the end of the day though I cannot speak for anyone else except myself. Shifting my focus on behaviour rather than “tests” led me to write better code examples. Often times I would write less of these because I was writing better examples. It’s also helped improve communication between myself and my team, customers, and other developers. BDD may evolve into something else, or perhaps a new perspective will come around that will take the world by storm. I am all about continuous learning and improvement. And I invite any ideas Mr. Lally or anyone else brings to the table.

Also, BDD never claimed to be THE answer. Any process that claims to be THE answer will surely not be THE answer for everyone in all situations. BDD has been an answer for many people though and as of now it will continue to be an answer for me in how I work.

A good resource worth checking out for BDD, it’s philosophy, and how to apply it in practice is The RSpec Book

rspec/cucumber ML email etiquette

2009-05-09T03:18:00Z

Aslak Hellesoy requested on the rspec/cucumber mailing list the other day that folks stop top posting. His words:

I find it really hard to follow conversations that use top posting (http://en.wikipedia.org/wiki/Posting_style). If you have a [Cucumber] topic, please respond with inline comments. And use plain text email – not html.

I agree with Aslak’s request for the most part. There are times when top posting is perfectly acceptable, but those are too often blurred by the countless times where people are just plain lazy. While most of the replies have been rather humorous in response a couple recent replies have the look of actual requests to the community: snip out things not pertaining to your reply and the removal signatures.

The only part I don’t agree with is the text email. I’m sorry, but if you use an email client which can’t show html, or can’t not show the html part of an email then you need to find a new email client. I have the feeling Aslak was referring to folks that only send HTML email, void of a plain text part. If that’s the case I am in full agreement with his request.

Aslak’s request was well intended and thoughtfully brought about. I hope the replies stop before there is a giant list of dos and donts, followed by a flamewar that will most likely have a negative impact on such a wonderful community.

RSpactor, love Cucumber

2009-04-28T10:02:00Z

If RSpactor loved Cucumber it’d be even more amazing. From the ticket request:

It would be amazing if RSpactor integrated with Cucumber although 
it would need to be a different than how it currently works with 
RSpec. Now that Cucumber has tag support I think this good be done 
in a reasonable way that improved the developer workflow for 
projects that utilized Cucumber.

Here's an example. When I am working on changing how money is 
managed in my app I know that I want to run the features tagged 
@accounting. At the start of my work it'd be great if I could 
add the @accounting tag to RSpactor so it would run those 
features after it successfully ran specs. 

Perhaps there would also be a preference setting which auto 
ran the Cucumber scenarios after specs ran, or one that forced 
you to manually hit play. Although if you had typed in tags, 
it the play button would run cucumber with those tags.

Got a better idea for Cucumber integration? Join the discussion! http://github.com/rubyphunk/rspactor/issues/#issue/1

Managing Client Expectations

2009-04-08T01:15:00Z

Managing client expectations is simple, but like most things simple—it’s very hard to do, do right, and do consistently. I think this is a common problem in today’s web development companies. The industry has a lot of young, creative, and smart people building companies with little to no experience in customer relations. For every person who is naturally gifted or good at managing client expectations there are probably several more people who just don’t get it. And the worst part, is that they probably aren’t aware of the fact that they don’t get it.

I’m one of those young, creative, and somewhat smart people in the industry trying to build a company in the web industry, but this is an issue that has been nagging me for months, and it’s to the point where I feel like it needs to be shouted from the mountain tops (although this blog is probably more like a anthill). It may not be the best business decision on my part since it encourages competing companies to become better. If they do it will make us humans work that much harder.

I’m sorry to say it, but few web development companies seem to do a good job of development and a good job of managing client expectations. Maybe your company is good at development, but stinks at managing client expectations. Or maybe it’s the other way around and you are great with the customer, but your team is a bunch of junior developers who crank out crap. Oddly enough, if your company falls into the latter you have a much better chance of being successful and surviving than the former.

Before look at some of the effects of managing (and failing to manage) client expectations let’s start with a simple definition:

Managing client expectations is the ability communicate proactively with the client in a reasonable and realistic manner that allows them to take ownership of decisions that may affect their project or business.

Managing client expectations is about communicating honestly, openly, and often with the client. It requires informing them of things that have the potential to impact their business or their project. I use the term proactive in the definition because you’re not doing it right if you do something and than communicate after the fact. Heck, doing that is like this the plumber who came to your house and failed to manage your expectations:

A plumber comes to your house to fix your toilet. At first glance it looks like it’ll take an hour to do so you set aside $100 on the counter to cover the cost and leave so the plumber can work in peace. While working the plumber discovers a much bigger plumbing problem. He’s really in the zone though, so rather than calling you he just does what’s necessary to fix the issue. You get home later in the day, and on the counter you see your $100. Next to it is an invoice for $2,200 and a note that reads: I ran into a bigger problem, but I was really in the zone so I replaced the plumbing in the basement because it would have had to have been done.

Do you feel the plumber did a good job of managing your expectations? Would you hire that plumber back? Would you pay the bill? I would answer three hell nos. Yet, many web developers and young web entrepreneurs find this perfectly acceptable and they wouldn’t think twice about doing it. To them it’s just how you move a project along its merry little way.

For folks who aren’t aware this is a problem—it is a problem and you should stop doing it. For folks who do it and know they do it, wake up, its unhealthy for your client, you, and your business.

I think it’s universal knowledge that finding a new client is more costly then keeping a client. Every time you interact with a client you have a chance to increase or decrease your likelihood of keeping them as a client. When you manage their expectations well you will most likely keep them. Here are three general reasons why:

build a healthy relationship
build trust
empower the client, giving them ownership

Positive effects of managing client expectations

Build a healthy relationship

Every time you interact with a client you have the ability to build a slightly better relationship. Setting clear expectations with the client with good solid communication strengthens the bond between you and your customer. Customers who have a healthy relationship w/their suppliers are not likely to jump ship.

A new developer joins your team. Every time you work with him you notice he takes the time do things right rather than just quick. He also seem to ask questions and raise questions at all the right times. You find yourself comfortable working with him and before you know if you even think that you do better when working with him. When the developer’s 90 day review comes up you’re first to speak up and ask the team to keep him.

Build trust

Part of building a healthy relationship is trust. To me, trust is like trying to level a character in EverQuest. As you build up stats and level you gain a new skill or perhaps a new magic. The higher you level the more your character is capable of. The same is true for the relationship with a client. As you achieve new levels of trust with your client you achieve new capabilities for doing things. Perhaps your client sends you more work. Perhaps your client refers you to his peers and to other companies. Perhaps your client invites you to more business-oriented meetings because he wants you involved in streamlining technical aspects of their business. Perhaps you become the goto shop for your client’s organization. Without trust this is not possible.

A new developer joins your team. After the first few months of working with her you find she is a good, honest, hard working, and capable developer. You build up trust in her as a developer. A potential client comes in and you need to send over a couple developers to help kick off the first Planning Game and do some story estimation. You send her. You know she’ll do a good job, ask questions, and be honest.

Empower the client, giving them ownership

Empowering the client is something that we really need to do a better job of in our industry. Managing a clients expectations lets the client own the decisions that need to be made that impact their project or business. These decisions are not ours to make, they are our clients. When the client owns the decisions, they own the project, they own the direction of the project. This isn’t to say we don’t guide or assist our clients in finding that direction. This is one of the many reasons we are often hired, however, when a client gives you permission to make decisions for them, they made that decision. When that’s not the case and we make decisions for the clients we are simply being lazy and bad vendors.

As a developer who practices Behaviour Driven Development I want my customers to own the scenarios that are written to drive the development of an application. The customer may physically write any of the scenarios. I may type them while sitting with the client, or during a phone call, but I am merely being a scribe. They own the scenarios. I never want the customer to feel that scenarios are written simply to translate business speak to technical speak, I want the customer to own the scenarios so its clear to them what they are paying me to build. Doing this empowers the client, it gives them ownership. They are usually much more engaged in the project when this happens.

Negative effects of failing to manage client expectations

Now, when you don’t manage client expectations you can have the opposite effect:

hurt the relationship
lose trust
empower yourself, taking ownership away from the client
increase the risk you negatively impact the clients business

Hurt the relationship

Not managing client expectations hurts the relationship. You may get away with it once, twice, or even three times, but sooner or later you will guess wrong and your customer will be ticked off. This is usually when they start looking for a new vendor.

Your customer has a feature they want added. You estimate 50 hours. It ends up taking you 110 hours. You don’t tell the client, you simply send them a bill. The customer is ticked, he asks that you stop working until the bill can be addressed. He wants to do a phone call with you to dispute the bill. Your customer is not happy.

Lose trust

Losing trust is a part of hurting a relationship, but trust is so important on its own. Most companies want to be a partner with the client. They want the client to leverage their expertise in solving a problem. If we don’t have that kind of relationship we lack the trust required for the customer to to utilize us in that way. Every time we fail to manage a client’s expectations we lose a level of trust. At some point its gone, and we’re out of the picture.

Empower yourself, taking ownership away from the client

Making decisions that affect the client’s project or business are a big no no. It takes ownership away from the client and only empowers yourself, but that empowerment only lasts a short while. You may have won the battle, but you will surely lose the war. First of all, decisions that impact the client’s project or business are theirs to make—not yours. Sometimes an emergency arises, the app is down! Chaos ensues! What to do? One of the very first things you do is call your client and give them the ability to say “no, don’t fix it”. Even though that answer may be highly unlikely, its not your decision to make, unless you have an arrangement with your client to make those decisions. Perhaps you have an agreement which covers what to do in those circumstances. If you do, more power to you. If you don’t, you may want to consider getting one.

Maybe you’re wondering what happens if you can’t reach the client? Do you wait to fix it until they call you back? I would say that depends on the nature of the issue. At minimum you should leave a voicemail and send a quick email, both which have your contact information. Doing this allows you to do everything reasonably possible to contact the client of the issue. And it may add 30 seconds to 2 minutes of overhead. This is usually reasonable. However, this is one of those times where it depends based on the relationship you have with your client. Fixing the issue first and responding later may be acceptable based on your arrangement. My belief is that if that’s not your arrangement than you should be contacting your client. Well, you should be contacting them anyways—that’s just being a good vendor.

The client’s site goes down. You get a call from one of their programmers (not a decision maker or gold owner) about it. You log in, evaluate, and decide to tackle it. Some time later you get it fixed! Woot! Invigorating, wasn’t it? Then you send a bill to the client. The person who pays the bill and has decision making power for paying the bill is very upset. Why a $1,200 bill? And why wasn’t he made aware of it? He heard from his one of his programmers their was an issue, but that it got resolved, why is the vendor sending a bill?!!

Increase the risk you negatively impact the clients business

Every time you make a reckless decision on behalf of your client without having some kind of prior arrangement or relationship in place you increase the risk that you will negatively impact their project or business. These are risks that are not yours to own, they are your clients. They always deserve the ability to say “no” even if it seems highly unlikely. The only time they shouldn’t have that option is if someone’s physical health is in immediate danger, but I haven’t seen any webapps running medical equipment, handling stop lights, or coordinating the release of water at Hoover Dam.

BDD w/Rails Class

2009-04-03T02:30:00Z

Shortly after RailsConf and while The RSpec Book is hitting the printers I’m going to be teaching a BDD w/Rails class with the amazing guys at Collective Idea

Official announcement – http://mutuallyhuman.com/2009/4/3/bdd-with-rails-class
Offical Course – http://ideafoundry.info/behavior-driven-development

Hope to see you there!

Scenario Observation

2009-03-20T00:00:00Z

One of the hardest things about being the developer and the scenario writer is that we’re in the thick of it. Once we get something written down we want to get it to work and then move on. This may involve copy and pasting part of an existing scenario to just get the job done. We get antsy.

One of the benefits of having the customer (or someone else) write the scenario is that we get to be the critic and not the author. We can focus on the scenario and ask questions like: does it read well? Is it doing too much? Is doing little? Can I understand its intent? etc. etc.

When working with a pair our pair should really challenge us to write good, communicating, intention revealing scenarios (just like they should be doing with code). This can be hard when we are working solo because we may just be staring at the screen for too long, and we can’t see the forest for the trees. If that’s the case grab someone else for a quick review, even if it’s after you finish implementing the scenario. Refactoring applies to scenarios to.

Scenarios are like code, if we don’t tend them well, they will grow messy and hard to maintain. We are best served to spend a little time upfront to keep them tidy rather than wait until we have hundreds of steps that don’t do a good job of communicating and require people to have to read through all of the step definitions to figure it out.

Go forth and code! ;)

ar-extensions 0.8.2 released

2009-03-17T02:09:00Z

ar-extensions 0.8.2 is released. This release fixes compatibility issues with Rails 2.3.1 and Rails 2.3.2. It should show up soon at a rubygems mirror near you.

Thanks to Stephen Heuer, Glenn Rempe, and Michael Murray.

gem install ar-extensions -v 0.8.2