Nervoustych

What me, cheap?

Jim Burger — Wed, 11 Mar 2009 08:33:46 GMT

In a recent post, Jimmy Bogard goes on the offensive and asks why are we, as developers so cheap when it comes to buying tools for software development?

Jimmy points out as soon as a dev wants to use a productivity tool, the requisition department seems to kick in and find a reason why not to spend money on it. Sometimes that department is the developers LHS of their brain kicking in, other times its a whole team of accountants waving their bottom lines at the dev team in dismay.

I’m going to defend my apparent frugality. And the LHS of my brain.

I’m not cheap, I just have a low tolerance for frustration, am lazy & dumb, and have a surplus of free stuff available to me. Like many others, I’ve also been burned by snake oil merchants more times than I care to remember. If that makes me cheap then chuck me in the deep fryer and throw me to the capitalists.

Jimmy is completely correct though, the issue lies with the people setting the budgets for tooling in the first place. They are conditioned to purchase software in bulk, so when asked for a diff tool, they automatically extrapolate that cost over every desktop and come up with some scary figure.

This is the wrong approach. Give each developer control over the tools they are going to need to automate their daily work. They are as power tools are to a tradesperson. Each developer will need different tools. Let them sort out the overlap and find the bulk deals if they exist.

I’ll tell you what I consider cheap:

Employers who expect developers to ‘just do it’. Serious development requires serious power tools.
Employers who don’t allow developers to augment their own toolset. ‘You will use the standard toolkit and NOT deviate from it.’
Developers who think that their employers should fork out for every tool that their heart desires. Go augment your own toolkit FFS.

I know point three is going to put some noses out of joint. I don’t care. I’ve long been a believer that a developer should be in charge of their own toolkit. In a very real sense, this means you are in charge of your own productivity.

I also believe that a developer should be afforded a regular tool allowance by their employer. Tools break or become obsolete; they need replacing or upgrading. The best person to decide when and what, is the developer.

Finally, in the case of a dispute, a developer should be encouraged to purchase the tool of their dreams, and upon proving its worth to the employer, be reimbursed.

Oh…and besides all that…. I don’t personally see what’s wrong with being cheap anyhow ;)

Please use this content in any way you choose, all I ask of you is to pay it forward. Code snippets are licensed under the LGPL

for the REST of us

Jim Burger — Thu, 05 Mar 2009 01:13:20 GMT

Probably the only POST about REST that I GET that PUTs everything in simple terms so that I don’t feel compelled to DELETE it from my blog reader.

http://tomayko.com/writings/rest-to-my-wife

Please use this content in any way you choose, all I ask of you is to pay it forward. Code snippets are licensed under the LGPL

My –isms

Jim Burger — Tue, 10 Feb 2009 02:06:02 GMT

I AM

Dogmatic about pragmatism.

Cynical of cynicism.

Prone to scepticism.

Attracted to absurdism.

Suspicious of capitalism.

My feeble attempt at a blog meme. Go here and pick 5 of your –isms. Its poetry made easy :P

If you’ve read this and have a blog of your own - consider yourself tagged!

Please use this content in any way you choose, all I ask of you is to pay it forward. Code snippets are licensed under the LGPL

Giving a damn about the broken windows

Jim Burger — Mon, 09 Feb 2009 08:28:27 GMT

Leon Bambrick has been writing some great posts lately, and two things have really struck a chord with me.

Firstly, in 6 ways to become a better programmer in 8 minutes (or was it the other way around) he drives home the point that attempting to increase code coverage in your project by 1% is a Good Thing. Especially given the fact that its likely that your code coverage is 0% hmmm? The biggest gain in unit testing probably arises from that initial attempt to bring your code base under some semblance of control.

Secondly, in an earlier post he finishes up by espousing the importance of passion.

You've got to give a shit about the code you write and the people who use it. If you don't care about it, you're never going to enjoy it properly.

“Give a shit” about your code – otherwise coming to work is pointless. Go home and find out how to care about the project before coming back.

I give a damn about unit testing, because I give a damn about my code. It saddens me to think that the majority of code bases out there have a code coverage of 0%. More so, it saddens me that there are people who don’t even try to understand unit testing and how it can work for you, rather than against you.

IMNSHO if you haven’t wrapped your head around unit testing by now, then you’re are not doing your job properly. You can’t possibly remember all the permutations of a complex problem, nor can you verify them all. So when you figure one out, you should verify it, code it and check it in. It is also a shame that prominent members of the coding community can’t get their story straight.

There are still plenty of people out there who just don’t seem to get it. Even with a test suite in place, it may become neglected. Progressively it too, falls into the category of legacy code. So how do we improve the efficacy of our test suite if we have one? I find the following to be advantageous, in no particular order.

Have tests run as part of the build, and fail the build if the tests do not pass.

This should be a no brainer. There are so many benefits to having tests and automating them that I cannot begin to summarize them here. Just do it.

Of course this is no good, if other team members aren’t compelled to fix the build. Which lead Leon to the conclusion that some form of build monitor that everyone can see to be a further improvement.

If you don’t have a laser guided USB missile launcher pointed at the person who broke the build, then your still fighting an uphill battle to make people care.

So, failing office warfare, you can try lowering the cognitive effort of understanding unit testing in the first place. The testing newbie usually finds the combination of mock objects, test fakes, test runners and testing frameworks all a bit too much to bare. Besides, test code should be as neat as production code, after all, it defines it. I like to impose the following rules on myself.

Use plain English when naming test classes, methods and variables
Avoid obnoxious acronyms
Clearly name test fakes and mocks
Differentiate between the ‘expected’ and the ‘actual’ value
Minimize the asserts in your tests
Use language features to full effect in order to improve readability
Refactor your tests as ruthlessly as your code

Use plain English when naming

Testing should be about specification, and should read as such. Having a class called FooFixture makes sense to some, but everybody understands WhenEmailingACustomer.

Similarly, a test named ShouldThrowWhenNullParm(), is too obscure. Should throw what exception? Which ‘parm’… schnitzel or olive parm? Avoid such cryptograms and defer to a more English style. ShouldThrowANullReferenceExceptionWhenProvidedANullFooParameter might be a little long, but at least it doesn’t need to be deciphered to understand it. Hell, we are all coding on 24” widescreens and better right? :P

Some people say that the code should document the test and the method name is a little superfluous. Sorry, but I say: nuts. I should be able to skim a list of test methods and fixtures and determine how a program works, as well as what it does, without reading the code, and so should my team members.

I also advocate the use of underscores, to further improve readability, however I realise this to be a personal preference. For example:

[TestClass]  

public class Concerning_the_person_controller 

{  

    [TestMethod]  

    public void It_should_retrieve_the_tallest_person_from_the_person_model() 

    {  

        //TODO: Write
a READABLE test 

    }  

}

Avoid acronyms

I’m a fan of marking the “system under test” and I used to be a user of the acronym, SUT to do so. However, I’ve come full circle and realized that having a CreateSUT method is taking it all too far. You will only serve to confuse the masses who aren’t up to speed on the latest BDD TLA.

Clearly name fakes and mocks

You might remember that you faked out the FooService in the TestInitialize (Setup) method, but by the 5th test, I can guarantee you that the testing newbie will have forgotten. Keep reminding yourself and others by sticking ‘fake’ in the name of the variable somewhere. Please do name the actual fake class as such also. If you are going to hide behind an interface, call it out explicitly. Remember, you are coding a specification.

[TestClass]  

public class Concerning_the_person_controller 

{  

    [TestMethod]  

    public void It_should_retrieve_the_tallest_person_from_the_person_model() 

    {  

        IPersonModel fakePersonModel = new FakePersonModel();  

        //... 

    }  

}

Differentiate the expected and actual value

Similarly, if you are going to cache an expected or actual value, make it clear as to what its purpose is. People who haven’t memorized every overload of Assert.AreEqual will quickly forget where what goes where. Keep reminding them with verbose naming.

    [TestClass]  

    public class Concerning_the_person_controller 

    {  

        [testmethod]  

        public void It_should_retrieve_the_tallest_person_from_the_person_model() 

        {  

            IPersonModel fakePersonModel
= new fakePersonModel(); 

            var expectedPerson
= new Person();  

            expectedPerson.FirstName
= "Joe";  

            expectedPerson.LastName
= "Hill";  

            expectedperson.height
= 203.00; 

            fakePersonModel.Persons.Add(expectedPerson);  

            //...

Minimize your asserts

I’m no ‘1 assert per test’ nazi; sometimes it makes sense to group asserts. however, aiming to keep them to a minimum will further help the readability.

Newbie's (and refactoring tools) don’t always realise that Asserts are really potential method exit points so keeping them close to the bottom of the test helps a lot too.

    [TestClass]  

    public class Concerning_the_person_controller 

    {  

        [TestMethod]  

        public void it_should_retrieve_the_tallest_person_from_the_person_model() 

        {  

            IPersonModel fakePersonModel
= new FakePersonModel(); 

            var expectedPerson
= new Person();  

            expectedPerson.Firstname
= "Joe";  

            expectedPerson.Lastname
= "Hill";  

            expectedPerson.Height
= 203.00; 

            fakePersonModel.Persons.Add(expectedpPrson);  

            var personController
= new PersonController(fakePersonModel); 

            Assert.AreSame(expectedPerson,
personController.RetrieveTallestPerson());  

        }  

    }

Use language features to improve readability

Extension methods are a boon to readable tests. Practice a little language oriented programming and write a more readable testing interface for your colleagues to grok quicker. Or use a test framework that has done some of the work for you.

For instance I have been putting together a library for internal use that has extension methods for common assertions to make them more English Readable®. Every time I come up with a new sentence, the test drives out development of my internal library, which has a nice side benefit of being useful in other projects.

[TestClass]  

public class Concerning_the_person_controller 

{  

  [TestMethod]  

  public void It_should_retrieve_the_tallest_person_from_the_person_model() 

  {  

    IPersonModel fakePersonModel = new FakePersonModel(); 

    var expectedPerson = new Person
{ 

      FirstName = "Joe", 

      LastName = "Hill", 

      Height = 203.00

    }; 

    fakePersonModel.Persons.Add(expectedPerson);  

    var personController = new PersonController(fakePersonModel); 

    var actualPerson = personController.RetrieveTallestPerson();  

    actualPerson.should().be_the_same_as_the(expectedPerson);  

  }  

}

You might even consider going one step further and providing a project specific DSL to really capture your intent. However the further you go down this route, the further you might obscure things, so be cautious.

Refactor your tests as ruthlessly as your code

Don’t repeat yourself, and refactor your tests when you see opportunity. By all means, take full advantage of the testing framework - as long as it works to your advantage. [TestInitialize/TestCleanup] or [SetUp/TearDown]routines will get missed, but explicit calls to a function will not. Furthermore, allowing for reading ‘top-down’ will win you extra brownie points.

[TestClass]  

public class Concerning_the_person_controller 

{  

  private Person TallestPerson;  

  private Person FirstPerson;  

  private PersonController CreatePersonControllerWithDependencies() 

  {  

    IPersonModel fakePersonModel = new FakePersonModel(); 

    var person = new Person { 

      FirstName = "Joe",  

      LastName = "Hill", 

      Height = 203.00

    }; 

    TallestPerson = person;  

    fakePersonModel.Persons.Add(person);  

    person = new Person { 

      FirstName = "John", 

      LastName = "Alfred", 

      Height = 200.00

    }; 

    FirstPerson = person;  

    fakePersonModel.Persons.Add(person);  

    return new PersonController(fakePersonModel); 

  }  

  [TestMethod]  

  public void It_should_retrieve_the_tallest_person_from_the_person_model() 

  {  

    var personController = CreatePersonControllerWithDependencies();  

    var actualPerson = personController.RetrieveTallestPerson();  

    actualPerson.should().be_the_same_as_the(TallestPerson);  

  }  

  [TestMethod]  

  public void It_should_retrieve_all_people_in_alphabetical_order_of_last_name() 

  {  

    var personController = CreatePersonControllerWithDependencies();  

    var allPeople = personController.RetrieveAllPeople();  

    allPeople.Count.should().equal(2);  

    allPeople[0].should().be_the_same_as_the(FirstPerson); 

  }  

}

If you haven’t figured it out already, then what all these suggestions amount to, is this: Treat your tests as well as your production code if you want people to bother keeping them up to date.

It is simply the broken windows idea from pragmatic programmer. If you haven’t got some sort of mechanism to hold people accountable for build breakages, then simply getting in there and caring enough to fix the broken windows might be all you have left.

Broken windows? Don’t live with them. Give a damn.

UPDATE: Apologies to those who have read this in Google Reader, I have updated the code snippets to be more readable.

Please use this content in any way you choose, all I ask of you is to pay it forward. Code snippets are licensed under the LGPL

Visual Studio Fonts & Colours

Jim Burger — Sun, 08 Feb 2009 07:53:00 GMT

I’m a customizing junky at heart. I’ve always liked to tinker with things. It’s not that I don’t believe in the saying, “if it ain’t broke, don’t fix it.”, its just that my definition of “broke” is broader than others.

Besides, if by tinkering with something breaks the object, then the object was probably broken anyhow.

Some people like their IDE to be as pristinely untouched as a neatly folded pair of freshly starched underpants, and I am not one of them. Much like my own pants, my IDE(s) have an earthy, lived in quality about them.

I’m also a mind changer. One of those annoying people who decide they want their coffee with 2 sugars today, and tomorrow it will be black and none. The part of my brain that decides what I like and dislike seems to be attached to a seriously good random number generator.

As such, I have a backlog of Visual Studio 2008 themes that I thought I would share. I know its a bit of a bore* to do, so please forgive me. I also don’t claim them to be necessarily complete for the types of coding that you do – especially web development. Use with caution if you choose to do so.

Anemic

This was inspired by Damien Guard’s Humane theme. I’ve softened it further, hence the name. I love his font face Envy Code R and I used this for almost 6 months which was a record for me. A very low contrast theme.

download

Neon

After using Anemic for a long time, I decided to go in the opposite direction. I have always liked coding on old UNIX terminals, so I decided to capture the look and feel. It uses the Monaco font face which is still quite a nice font for developing.

download

Fantanic

Much like a pendulum, I swung back towards a pale background, however the high contrast was kept for fantanic. I have decided I prefer earthy colors, using blues and purples to highlight, rather than using it for keywords. I tried the Droid Sans Mono typeface and went for larger fonts (I think I needed my eyes checked) and I’ve stuck with it since. Works great on the projectors and large screens.

download

Hart

My current theme leans toward a darker, lower contrast theme in colours I don’t see used often, giving it a distinctive look. Having my eyes checked and rectified, I reduced the font size. I’ve been coding at night lately and its quite easy on bleary eyes.

download

Feel free to download and adjust to your whim. If you like or dislike these themes, I encourage you to leave a review on IDE Hot or Not.

* Personally, since X is the new Y; I think that labelling something as “that is so [1|2][0-9]{3}” is the new (annoying|uncool|stupid).

Please use this content in any way you choose, all I ask of you is to pay it forward. Code snippets are licensed under the LGPL

Software changes

Jim Burger — Thu, 05 Feb 2009 07:48:51 GMT

How you react and prepare for change is very important; it can make or break a project. Allow for changes that wont come and you’ve written too much code. Forget to allow for other types of change and your application becomes either brittle or unwieldy in the face of change.

Software change has been divided into 3 flavours in the past:

Re-architecture

Re-architecture is a more ruthless variety of change that involves changing the very foundations of the software to cope with new requirements. A classic move would be from a single tier application to an n-tier design in order to allow for multiple users.

Re-engineering

Re-engineering is essentially refactoring; the process of re-writing software to make it easier to understand, without adding new functionality. Its the type of change developers love, but project managers hate, and architects put up with. Simplification, removal of duplication, consistency etc. All the good stuff.

Software Maintenance

Maintenance is the act of reacting to a change in software requirements, however the fundamental software structure is not changed. This is the change we tend to deal with the most as developers, requirements are forever changing from the end user, to the very platforms we work on. I’m mainly picking on this kind of change, however I’m going to split hairs even further.

2 Kinds of Requirements Change

There are possibly more, but I’m thinking of two types in particular:

Changes that are unilateral
Changes that… aren’t

What I mean is this. If you cannot avoid changing something in all layers of your software in order to accommodate a new or updated requirement, then you have a unilateral change. An example would be in a typical line of business application. The product owner would like you to add support for a second telephone number. The software currently supports one. No matter how many layers you have, you will likely need to change all of them to support this change. Having a PersonDTOFactoryServiceFactory class might get in the way of a good time here.

In this same application, the user now informs you that the business rules for the concept of “Deferred” has changed. This is a localizable change – handled properly. Good apps will have this sort of logic tucked away in its own layer, and will not need to be replicated in either the UI or the DB. Badly written, tightly coupled apps will have you writing code in UI event handlers and SQL change scripts.

Localizable changes happen daily and they cost developers time by the bucket load. I expect them to occur and I lovingly call reacting to these changes as ‘my job’.

Unilateral changes on the other hand, tend to come en masse with deadlines attached. They can be mistakenly given too much weight in the design process as a result. It’s these changes that can cause a developer to contract a phobia of layers. Personally, I expect these changes to occur almost as often as the former, however I like to call these changes ‘version next’ where at all possible.

Defence

The real issue is defending oneself from change and how much defence to put up, and how much that defence costs you.

The method of protecting yourself from unilateral change, is to minimize the amount of layers you have to deal with when unilateral changes occur.

Defending yourself against localizable changes, is often done by increasing the number of layer in your application, mainly to improve the chances of changes only effecting one layer at a time.

“Layer” is a difficult term, and I use it in the sense that they to one another via an interface. They do not depend on one another in order to perform their function. Think ‘abstraction layer’.

Conflict

The tension between these two types of change could be seen as a manifestation of Conway’s Law. I also believe that this tension is why n-tier applications tend towards a layer count of 3 and above.

Adding layers can be the simplest way to turn what appears to be a horrible sweeping change. For instance you can use the MVC pattern to separate the UI from the DAL.

The danger now is that you now have more work to do when a change comes along that will effect the endpoints of your application. If the user demands that second address, then the PersonView, the PersonController, the PersonModel, the PersonService, the AddressRepository, the AddressAdapter and the Address and Person Table will need to be changed. Oh I wish we had only 2 layers again.

However, the moment that the Address needs to be formatted differently, depending on which view the user is using, you will thank yourself for having that PersonController there.

Conclusion

It is clear to me that, both types of maintenance changes occur and both need to be allowed for. Dismissing one type over the other is a mistake. Favouring less layers to account for the 50 columns you know the user is going to add is as foolish as over engineering a solution to protect oneself from imaginary gremlins.

Another point is that there are already so many layers in an application, and that can be seen from two perspectives: that one more layer wont hurt, or that one more will be the straw that breaks the camels back. Its up to you.

However, a pragmatist will employ rigorous application of YAGNI. Don’t create more layers until you absolutely need them, but do not shy away from creating layers when change is on the horizon.

Leaving design decisions as late as possible will ensure you learn to Say No to frivolous layers of abstraction. TDD (When Used Correctly™), SRP and IOC, will guide the developer to produce code that will cope better with change without over engineering it. Oh, and you’ll be able to join the TLA club too.

Please use this content in any way you choose, all I ask of you is to pay it forward. Code snippets are licensed under the LGPL

Languages are tools, use them.

Jim Burger — Fri, 17 Oct 2008 04:38:15 GMT

While I think its great that I can use C# to express functional concepts, I also think that for anything more than the odd lambda expression, that I'm using the wrong tool for the job.

If large portions of your code begin with <Expression<Func<T, ... then step back and have a look at what you are trying to achieve. Sure, the usage may look fine, the fact remains that you're trying to express concepts at a level of abstraction that C style languages aren't equipped to cope with. Personally I think the well rounded coder would feel more comfortable writing an F# library.

Why bang your head against C# to write DSL's when Boo will go out of its way to make it easy for you?

Found yourself falling in love with AOP techniques and have consumed 3rd party libraries to get it done? Did you provide an interface layer to decouple that dependency? Why aren't we just naturally breaking out into IronRuby here?

The only reason I use C# 3 to write unit tests these days is there isn't really a viable testing language created yet.

A few years ago and beyond we had an excuse. Each language usually had its chosen platform and it didn't play well with others. Using Erlang made sense for telecommunication work, but it would be considered counter productive to write a windows GUI in that language. Similarly, you simply wouldn't bother using VB to write code for massively multithreaded environments.

Today, we have no excuse. The fact is that the Common Language Runtime provides us a mechanism to use the right language for the task at hand, and not only that, compile in a cross language solution, such that the net result is completely seamless to the untrained eye. The 'core strengths' that the average business application developer is available for any CLI language.

Today, we are only restricted by those who refuse to learn new languages, when in fact, learning has never been simpler.

Please use this content in any way you choose, all I ask of you is to pay it forward. Code snippets are licensed under the LGPL

Strongly Typed Data Binding in F#

Jim Burger — Thu, 16 Oct 2008 01:31:06 GMT

Jason recently produced this post where he demonstrates some lambda expression tree parsing and extension methods in C# 3.0 to do windows forms data binding sans strings:

nameTextBox.Bind(t => t.Text, aBindingSource,
(Customer c) => c.FirstName);

I happen to like the idea so much that I thought about how this might look in F#. There are some juicy language features in F# sharp that lap this stuff up. Take Jason's C# implementation:


          public static class ControlExtensions 

{  

    public static Binding
Bind<TControl, TDataSourceItem> 

        (this TControl
control,   

        Expression<Func<TControl, object>>
controlProperty,  

        object dataSource,   

        Expression<Func<TDataSourceItem, object>>
dataSourceProperty) where TControl: Control 

    {  

        return control.DataBindings.Add(  

            PropertyName.For(controlProperty),   

            dataSource,   

            PropertyName.For(dataSourceProperty));  

    }  

}  

public static class PropertyName 

{  

    public static string For<T>(Expression<Func<T, object>>
property) 

    {  

        var member = property.Body as MemberExpression;  

        if (null ==
member) 

        {  

            var unary = property.Body as UnaryExpression;  

            if (null !=
unary) member = unary.Operand as MemberExpression; 

        }  

        return null !=
member ? member.Member.Name : string.Empty;  

    }  

}

While this gets the job done, the fact that every last type needs explicit declaration gets in the way of some otherwise damn elegant thinking. The signature for the Bind extension is crazy long, and the phrase "angle bracket tax" comes to mind.

What if our compiler would infer these types for us while preserving compile time type checking? I still want to provide some generic type constraints but beyond that, I don't care. Using F# we can have these all of these things to give us readable solutions to difficult problems. Also note the extension method syntax:


          #light  

open System.Windows.Forms 

type Control with  

    member this.Bind (control_property : #Control->'b) datasource
datasource_property =  

        this.DataBindings.Add(

            property_name_for
control_property,   

            datasource,   

            property_name_for
datasource_property  

        ) |>
ignore

I've deliberately left the implementation to property_name_for till now because it uses some little known constructs. Quotations in F# allow the developer to inform the compiler that a particular piece of code is to be dealt with as an expression tree. To quote code we use the <@ expression @> construct. Being a functional language (amongst other paradigms) F# also allows us to pass lambdas around as variables and parameters unevaluated without any ceremony, thus yielding a readable approach to finding the name of a property in a lambda expression body:


          #light  

open Microsoft.FSharp.Quotations.Patterns 

let property_name_for (p:'x->'y) =   

    let rec parse_expression
e = 

        match e with  

        | Lambda(var,
body) -> parse_expression
body  

        | Let(var,
lhs, rhs) -> parse_expression
rhs  

        | PropGet(opt,
info,  expr) -> info.Name  

        | _ -> ""  

    parse_expression <@ p @>

Note the usage of active patterns Lambda, Let & PropGet provided by the latest CTP of F# in Microsoft.FSharp.Quotations.Patterns we can analyse the expression p to recursively hunt property gets in the lambda body. The Quotations.Expr class conversely, allows us to construct these patterns. The latest CTP has simplified the Quotations namespace dramatically and now utilizes the standard .NET reflection libraries consistently. The list of patterns and constructors is extensive so rather than going through them all here, here's the link to the docs.

Full listing with example usage:


          #light  

open System.Windows.Forms 

open Microsoft.FSharp.Quotations.Patterns 

let property_name_for (p:'x->'y) =   

    let rec parse_expression
e = 

        match e with  

        | Lambda(var,
body) -> parse_expression
body  

        | Let(var,
lhs, rhs) -> parse_expression
rhs  

        | PropGet(opt,
info,  expr) -> info.Name  

        | _ -> ""  

    parse_expression <@ p @>  

type Control with  

    member this.Bind (control_property : #Control->'b) datasource
datasource_property =  

        this.DataBindings.Add(

            property_name_for
control_property,   

            datasource,   

            property_name_for
datasource_property  

        ) |>
ignore  

(* EXAMPLE ONLY *)  

type Customer = {  

    FirstName   : string;  

    Age         : int;  

}  

let nameTextBox = new TextBox()
let ageSelect = new NumericUpDown()
let bs = new BindingSource()

bs.DataSource <- { FirstName
= "Jim"; Age = 29 }

nameTextBox.Bind (fun ctrl -> ctrl.Text) bs (fun c -> c.FirstName)  

ageSelect.Bind (fun ctrl -> ctrl.Text) bs (fun c -> c.Age)

Please use this content in any way you choose, all I ask of you is to pay it forward. Code snippets are licensed under the LGPL

Seriously, Why Test First?

Jim Burger — Wed, 01 Oct 2008 07:34:17 GMT

Is TDD over the top? Surely can I write my tests 'alongside' my code?

Short answer: No.

Long answer:

To borrow Michael Feathers, author of "Working effectively with Legacy Code" the definition of legacy code is code without tests. By writing a function without a test first, you've just banged out a whole bunch of legacy code. It might not feel like it, but you could have just wasted your precious time.

OK, so lets pretend we have some of this legacy code in front of us. We begin writing some tests to cover it. What you'll find is that many programmers do one of a few things:

Coder A will write four or five tests for every method and generally not have to change their implementation much, if at all.
Coder B writes less tests overall, but in order to get it there they had to change their code due to recognising some unnecessary coupling or logic.

The next few examples are people who would have used TDD or no tests at all...

Coder C used TDD but strangely the end result looks like Coder A's code.
Coder D thinks unit testing is a waste of time, and has already deployed to production by now and is currently smugly sipping on Kool Aid.
Coder E only wrote a few tests, each test concerned with what the code should do, not what the code currently does, or how it goes about doing it.

Now that we have brutally put everybody in a box with rash generalizations and assumptions, lets come up with a way to throw a cat amongst the pigeons. Generally the best way to do this to a developer, is to ask them to add a new feature to their code.

Coder A when finished, finds that all the old tests wont even compile let alone pass because the new requirements severely altered the required architecture. Time is wasted rewriting all the tests to facilitate the new architectural requirements.
Coder B finds that only half of the old tests build or pass after implementing the new code. Because they removed some coupling it was easy enough to add, but they wasted time on some old tests that were obsolesced by the new architecture.
Coder C decides that the existing test suite isn't going to facilitate the new requirements. After they rewrite most of their tests they rewrite the code to satisfy them. Its like much Coder A's experience just in reverse.
Coder D deploys the new code to production or QA, only to find that the new changes stomped all over old functionality. What do you mean it 'doesn't work'? That's impossible! Time for a week long debugging session.
Coder E on the other hand writes one more test to the test suite and adds as little code as necessary to make it pass, then brutally refactors anything possible. None of the tests needed rewriting in the process. All user requirements are met and the project is delivered on time and on budget. If your lucky that is...

What some people fail to understand, is that using TDD doesn't prevent you from writing bad code. On the contrary, it can encourage you to over specify things. When you over specify, you increase the places in your test suite that depend on how your implementation is structured. The very same thing happens when you write a function, and then a test or write tests 'alongside' your code. This is the mistake that Coder C makes, taking the bull by the tail, instead of the horns.

Coder E has no idea that he/she is in part practicing BDD. Its a natural progression from blindly banging out tests to cover every feasible outcome. Eventually you get a feel for tests that give you maximum 'bang for buck'. These tests provide maximum (quality) coverage for the least effort. In other words, we aren't bothering with a test per function. We are writing one test per desired behaviour.

OK so every now and again, you head down the wrong track and tear up a few behavioural tests. Usually that's because you misunderstood the requirements, not how to code it, and that's where the value lies. If you cant write a behavioural test, then you haven't understood the problem fully. If you don't understand the users problem, why are you coding?

That's why initially, its tempting to TDD blindly, you can ignore certain aspects of the users problem and just simply code until you think you got it right. Of course there are a few other aspects to BDD that I'm sure you're either aware of, or hopefully discover after reading this, but its important to remember:

BDD isn't something new and funky fresh. Its not the latest soda pop fad. At its heart its simply TDDDone Well.

Please use this content in any way you choose, all I ask of you is to pay it forward. Code snippets are licensed under the LGPL

Its great, but what is it for?

Jim Burger — Mon, 29 Sep 2008 07:16:31 GMT

In my previous post I espoused my latest love affair for Stackoverflow. I still think its an awesome site, however I recently got stung by the ever present reality that there are some people who think its for programming questions only, and others who think its for all questions, as long as they relate to programming.

I asked this question.

Sure its subjective, sure it can involve answers that apply to life in general. I even knew that it might yield answers that were opinions rather than fact. However, its firmly under the banner of questions that can be answered. Your answer might work for you and not for me, but that doesn't mean we haven't answered the question, it means the question has more than one answer. Much like the difference between a maze and a labyrinth.

I'm of the opinion that this site was created toprovide value to its members. Clearly the response to the question indicates that many members found it to be a useful one. Unfortunately I'm at the mercy of editors who may or may not have a clear grasp of Venn Diagrams. I was told that my question is not about programming because its answers can be applied to any profession.

"This is nothing to do with programming - it applies to all working people"

Given the above diagram we can posit that a question that applies to all professions also applies to the profession of programming. Especially since I'm a programmer asking other programmers!

In another comment, emphasis mine:

"It's like asking how to make a peanut butter and jelly sandwich suitable for eating while coding - just because it's valuable to many programmers does not make it a programming question."

I'm concerned that semantics is more important to the commenter than good content when I see this. If peanut butter and jam sandwich recipes were truly useful to many programmers then why would we want to stop people from using the site to discuss it? If its useful, its a tool like any other. Discussing techniques to combat lack of motivation are as important as techniques to combat code coupling.

Furthermore, in light of the fact that the site creators clearly condone this question I'd say that the FAQ was deliberately using soft terminology when guiding the end user what not to ask:

"Avoid asking questions that are subjective, argumentative, or require extended discussion."

Blind adherence to the literal meaning to such a mantra is what gives us such wonderful things as fundamentalism. The spirit of what is going on behind such a sentence is to prevent questions like "Which is better, C# or VB?", not potentially useful discussion.

The key here is that if you choose to take the FAQ literally then you should also take this literally:

As long as your question is:

detailed and specific

written clearly and simply

of interest to at least one other programmer somewhere

... it is welcome here.

I realize that there is a worry about Signal to Noise ratio, but the site is tagged and searchable for heavens sake. Presumably in future releases we'll have the ability to filter out tags in your search results at whim and will anyway.

The fact remains, subjective questions are some of the most popular on the site. Some see this as a scourge that needs to excommunicated. Personally I think it demonstrates that programmers on the whole :

a) Like to have a bit of fun from time to time,

b) Recognize that there is more to programming than code.

All of this is moot however, given that those people who think that all time management solutions in the profession of personal training necessarily applies to that of a surgeon and therefore programmers are clearly wrong.

Let me demonstrate with a small sample of the sorts of differences we are likely to find across two different professions:

Q: When is it a good time to stop coding?

A: Whenever you feel tired and unmotivated. Get up and walk around, maybe get some exercise and get the blood flowing.

Now lets apply this to the profession of say, soldiering:

Q: When is it a good time to stop shooting at the enemy?

I think its clear that ceasing to fire upon the enemy and then getting up and having a walk around when you are simply tired and unmotivated, could result in the untimely cessation of your career as a soldier.

I'm keen to hear others thoughts on the matter.

Please use this content in any way you choose, all I ask of you is to pay it forward. Code snippets are licensed under the LGPL