The Duck

Microsoft is working on it's new mashup technology named Popfly.  The current image associated with it is this.

Popfly

As you can see, building mashups will make your bill go green and give you a pink complexion.  It's nice that they have such a cute and warming mascot though.

The project I just got off has it's own feathered mascot.  Unlike working with (on?) Popfly, we were a little more hardened and jaded.  At one point in time The Duck was even sported a wicked anchor tattoo.  I think he grew out of that rebellious phase of the project and, when hard times started, he started toking.  Sometimes you have to do what ever you can to make it through the project.

The Duck

Published at

When is a Defect a Defect?

For the past 9 months I've been working on a project that is dominated by a desire to have heavy documentation created prior to development work commencing.  As a result of this there is a trend to having things laid out in a place that the developer and tester can access.  Even with this style of development (also known as BDUF or waterfall) there are a lot of little things that don't get written in the documents and some larger things that get missed completely too.  Regardless of the tone I take in this post, those things need to be coded and provided to the client (assumption: the client really needs them).

What I've seen happen on my project in the last 9 months is a trend towards calling everything that is either broken or not included a defect.  The problem that I have is the determination that these are actually problems in the code.  Take for instance a scenario where the design document simply states that a screen should have a date picker on it and the ability for the user to select the date.  How is it that a tester can subsequently test that screen and then log a defect claiming that the date picker should not allow the user to select dates in the future?  I'm not arguing that this isn't what the client wants or needs, but rather how is this determined to be a defect?  I, as a programmer, can only code within the specifications and environment that I'm provided with.

If your process is to rely on heavy design documents, I will fall back to stating that "...the document didn't say it should do that", which is a very poor place to position myself.  The problem is that I can fall back on that with full confidence that I have a piece of verified and vetted paper that will back me up.  Another of my problems is that the testing is obviously being done based on a different set of expectations then what I am developing with.  Where does that second set of expectations come from?  Why does it exist?  Why are we fighting over the words on a piece of paper instead of working to get the client what they want?

For me, a defect occurs when we have created a piece of functionality that does not meet the needs of the client.  There are some gray areas (UI standards, consistency, etc.), but the majority of the time I find that answering "No" to the question "Is it what the client wants?" is the most effective way to make a determination.

I've never worked on a strong agile project before.  How do they handle the creation/definiton of defects when there can be so much client interation during the coding phase?  I assume that the increased client prescence dramatically decreases the opportunity for defects to arise, it's just how they are handled that I'm not overly clear on.  I'm going to be very glad to work on something non-waterfall in the future.  Let's just hope it's not two projects away.

Forgotten Purpose

Today I got an email from a guy who appears to have become disillusioned with what he sees in our industry.  Unfortunately I, and probably a large number of other developers, can relate with his frustrations.  To summarize his email, he’s basically saying “I can’t believe that we do this to clients”.  ‘This’ could be anything you’ve seen or imagined in the past; Low (poor) estimating with expected over-runs, dropping the application in the client’s lap one month before go-live and expecting them to test it and be happy with the what is provided, business requirements not being gather and having developers make their best guess.  The list could go on and on.

I’ve seen all of this in the wild.  Heck the project I’m currently leaving has this in spades.  So why do we continually do this to the people who pay our rent?  I could just tramp out the Agile Manifesto here and start saying how it can work with you to reduce the friction between your team and the clients, but I’m not.  Instead I want to explore what makes us think we can or should run our projects in these ways.

Software development (for LOB applications) usually happens in a sequence of events.  First, a business decides that they need software to help them run their business.  A project is struck and a team (internal or external) is raised to begin creating the software requested by the business.  The project team works away at the SDLC and produces an end product (software we hope).  The business implements the software as part of their business and said project ends its initial development life cycle.

In all of those steps there is one constant…the business.  They start the process by creating a need for a project.  They participate during the running of the project by dictating what is required in the final result.  At the end, the business takes the software and works with it, ensuring that payment was made for the work done.

Those steps can be translated into:  The business creates a job for people doing software development.  The business dictates the results that they expect from those people they have created employment for.  The business consumes the final product created by the people in their employ.  Interestingly, when we look at it this way, we (software developers) owe our employment and paychecks to the business.

For me this points out two things.  One is that we developer work for the business at a larger level than is normally acknowledged.  Secondly, the business should demand more from us as our roles were created to meet their desires and requirements.  What I don’t understand is how it has become so regular and common place for software development projects to dictate to the business.

When did it happen that we could get away with statements like I’ve heard in the past year?

The business needs to change because of how we implemented the database.

Or

I’m gathering all the BAs and dev leads so that we can decide what client stories we will remove from the project for go live.

Why do we feel so capable of telling a business what it does or doesn’t need?  I have no idea how to run any of the businesses that I’ve built software for.  I may understand things in their terminologies and even how those concepts relate to each other, but I have absolutely no idea how to take that information and translate it into a sound business decision.  My job, as a software developer, is to help the business have the information necessary for them to be able to make those decisions.

The business should be relentless in their desire to have the information that they need.  They should also be aware that sometimes we can’t display something in the way that they want.  There is a difference between we can’t for technological reasons (how do you create a 4 state checkbox?) and we won’t because the development team (including the BAs) doesn’t think it’s needed.

Often the ‘can not’ and ‘will not’ statements get blurred together by the project team in an attempt to turn the ‘will nots’ into ‘can nots’ for the project teams benefit.  Instead the project should be actively looking for ways to minimize the occurrences of ‘can nots’ and eradicating the ‘will nots’.  If we are going to build software that actually does serve the business in the way that they are hoping for when they initially strike the project, we must do this.  Allowing projects to deteriorate, which they seem to start doing immediately upon their inception, into a stream of ‘can nots’ and ‘will nots’ is a sure fire way to have the business consider the final product a failure.

Don’t think that I’m all about the business getting everything that they want all the time.  I think that it is imperative that the project impose some of the same caveats on the business that the business desires on the project.  If they are giving the project a set in stone completion date, it’s not unreasonable (in fact it’s probably prudent) to put time constraints on their decisions.  Because we are in this together, there has to be an expectation that each party will work to ensure the success of the other.

Published at

The transformation of an igloo

I finally got some time today to migrate my blog from Community Server to SubText.  Part of the transformation also includes the unveiling of my new logo.  Stuart at Design Goblin has done a fantastic job working with me to come up with the face of igloocoder.com Consulting Inc.

Part of the transformation was for me to migrate all of the data from the CS database into the SubText database.  I posted here in the past about some of the ridiculous data storage that I found in CS and I managed to overcome them.  Here's a SQL script that you use to make the conversion.  Read the info in the header comments to see what you will need to change in the script to make it work.  If you look through my blog, you can see that it converts pretty much everything that you need.  I didn't run anything other than the script to get the content into the state you see here.

This skin is a work in progress.  Over the next month I'm going to clean it up and get it working in a way that I'm happy with.  In the mean time, if you see anything not working, ill-formatted or just plain wrong, drop me a note and I'll add it to my fix list.

Desert Code Camp files

Here is the stuff that I worked with on two of my presentations at DCC.  I'm not going to post anything from my C# 3.0/.Net 3.5 presentation.  If you want to see something from it take a look at two of my screencasts here, here and here.  I promise I'll be getting a third, on Lambda Expressions, published in the near future.

RhinoMocks:  I've put the source code that I wrote into a zip file that you can download here.  It also includes the nAnt script that I used for my CCNet presentation.

CruiseControl.Net: The nAnt file and the ccnet.config files for this presentation can be found here.  If you're looking to play around with this you'll need to download CruiseControl.Net version 1.3.

Desert Code Camp Wrap-up

We went, we saw, we sweated.  Desert Code Camp 3 finished up yesterday with another great turnout.  For Tom and I, it was a day of Agile goodness.  We talked on TDD, RhinoMocks and CCNet, but in my final session (CCNet) the attendees directed the discussion more towards Agile.  For the last 15 minutes or so, we had a fantastic conversation about Subversive/Guerrilla Agile.

Huge thanks to Lorin for having us down to Phoenix/Tempe for this event.  He did a fantastic job of running the whole thing.  I only hope that he had some time to get to sessions.  To all the people that came out to my sessions, I will be putting up a post with the content shortly.  To the young kid that attended 2 of my sessions, keep coding dude and send me an email any time that you have a question.

Published at

Desert Code Camp -- Day 2

Well, it's actually day 1, but it's day two in Tempe (tem-PEE) for me.  Here's the summary.

C# 3.0 Beyond Linq:  This was my presentation.  Nothing special here.  Take a look at the Simple Properties and Extension methods screencasts that I have posted and you'll get the basic gist of the presentation.  I swear that I will finish the Lambdas screencast soon....honest.  The coolest thing in this presentation was the 10 year old kid that attended.  What I was covering wasn't rocket science, but this kid asked some of the most intelligent and pointed questions.  He was really groking potential limitations and implementations of the stuff I was showing.  After the presentation I spoke with him and his mom and this kid is working, with a mentor, on writing an ASP.NET application for a real live client.  I really wish I'd had opportunities like this when I was a kid.

Intro to Linux for Desktop Users:  Painful.  These guys were trying to show how easy it was to use Linux as a desktop OS.  Well....I admit that I don't use a projector at home, but when that doesn't work and the presentation is done by holding up a laptop screen in front of the room, I begin to thing that there still might be a problem.  The guys were good enough to provide a CD with Ubuntu so that we could follow along.  This was very painful to watch and didn't, unfortunately, give me the intro that I really wanted.

ObjectBuilder/Composite UI Application Block:  This is the first time I've sat in a technical presentation and felt like JP would in a presentation on DataSets.  It's obvious that this guy knows CAB.  Ha!  He just muttered "It seems so complicated"....a sure sign that it is more complicated that it needs to be.  CAB looks like a beast.  I don't like the fact that your type mapping (i.e. when asking for ICustomer please give me the Customer object type) is burned into the code.  When I asked why you'd want this the response was that it allows you to compartmentalize your code so that no knowledge of it is made outside your "module".  Apparently putting the mapping into an XML file, like Castle Windsor does, would expose to much information for potentially nefarious uses (what they may be eludes me, but whatever).  CAB will not allow you to provide dependency injection to the first form that is being loaded by the application.  I guess you'd better hope that the first form doesn't have any smarts.  I hope that this is not his standard coding practice....multiple public classes in one file...blech.  The ProfileCatalog is how the modules are registered with CAB.  It loads the objects in reverse.  Oh my.....Single Responsibility Principle hasn't made it to this part of Arizona yet.  This is some nasty shite.  Looking at this I don't see how it could be easily mocked.  It would probably take a lot of proxies and wrappers just to be able to mock.  I might be wrong on that, but I don't see why I should have to go to all that extra work just to mock a layer.

My analysis....CAB is a plug-in architecture that is using dependency injection.  Not something unreasonable to be hand-rolled in a day or two with the right tools.  If you did that you'd have something a little less "elephant-in-a-china-shop" and it would probably expose a lot prettier interface to the developer that was consuming it.

Wrapup:  Well, according to Lorin they gave away about 400 handouts so this has to be considered a big success.  The content was good and the attendees were pretty intense.

 

Well, we're off to a Google piss up.  Like always, I'm going to see if I can bankrupt one of the biggest computer companies in the world through alcohol consumption.

Desert Code Camp -- The Night Before

Tom and I made it into the Phoenix/Tempe (pronounced tem-PEE we've been told, not TEMP-eh?) yesterday.  First impressions:  Holy crap it's hot!  We stepped out of the airport and into the direct path of a blast furnace.  I suppose if we are acclimated to Canadian winters, people can get used to these summers.  Regardless, it's just not comfortable for people like us.

In the afternoon we hit Mill Avenue in downtown Tempe and found a nice Irish pub.  If you're ever in the area, Mill Avenue appears to be a lively and well visited part of the town.  Located next to Arizona State University, there is a vibrant community and some fantastic looking venues.

Lorin had a small gathering in a park near Mill Avenue where we met some of the locals and other speakers.  Probably the most shocking thing was that the sun went down at 630pm and 2 hours later it was still over 100F.  Did I say that it stayed hot here?

After some socializing, a small group of us went to the bar in Monti's and had some more laughs, talks and beverages.  I have to say that I traveled about 1400 miles to get damn close to the Mexico border and then we found the one place in all of Tempe that didn't have nachos.  Such is my luck!

Pre-Desert Code Camp gathering

Tom and I are on the move on Friday as we head down to Phoenix for the Desert Code Camp.  We'll be arriving in town during the middle of the day on Friday and will definitely be looking for some people to pour down a drink or 15 with.  Being first-timers to the Phoenix area we're also looking for some ideas on good places to go, drink, eat and converse (I also want to put a review up on GeekTukka just to prove that I was sober enough to go out at one point).

If you're interested in joining us on Friday evening or suggesting an establishment, leave a comment with an email address, or ping me at igloocoder (at) igloocoder (dot) com.

Refactoring goodness

Today I spent some time in our code at work (I know...shocking that I was writing code).  One of the things that I found was a group of three files that each contained anywhere from 3 to 20 public classes.  I'm at the point where this is no longer shocking and instead I just turn to immediately looking to refactor instead.  While I was hammering through the process of changing the namespace, moving to a new file (thank you Resharper F6!) and physically moving the files, the ease of the process struck me with a thought.  Resharper is not just a great tool for refactoring.  It's a tool for placating your worries about the difficulty of the refactoring.

If I had not had Resharper to help with this process I very well might have looked at the class and then walked away from it thinking (more likely muttering) about the difficulty of fixing someone's past indiscretions.  Resharper gives developers the piece of mind to make significant changes with little effort impact.  That, plus the consistently error free results, makes the decision to improve the code so much simpler.

I did run into one small issue with the refactoring at work on v2.5 of Resharper, but when I tried it at home I was unable to reproduce it with v3.0.  All good in my books.

Upcoming Events

My fall schedule is starting to book up and I'm looking to be quite busy.  If you're interested in becoming a groupie of mine, you can find me at the following places in the next few months.

There are at least 3 other things that I'm working on, but none are announcement ready.  Mix into that schedule the fact that my current employment status will be changing at the end of September, and a desire to do a little bit of pleasure traveling, I think you can see that things are definitely changing pace.