The debate on software craftsmanship

So this one keeps rumbling on. Are programmers software craftsmen ? Are we employed to execute a craft ? What does that even mean ? If it is a craft, does that mean some people are not in the club ? Does it matter if we are ? Or are not ?

I've written some really shit code over my years, and I've written it for some terrible reasons. And some good reasons. What do those reasons mean as a person ? Or a programmer ? Or a craftsmen ?
I've written code that was crap for the following main reasons :
1) I didn't know any better, and was doing as best I could
2) I was under krazy-with-a-K timescales, the company didn't give a rats arse about quality, and just wanted it, *anything*, out the door
3) I was lazy and/or disinterested in the task at hand

Uncle Bob (and I'm a big fan - "Clean code" was a wake-up call for me a few years ago) would most likely say that those 3 reasons for writing crap code are what made me not a craftsmen - I was a disgrace to my name as a programmer.
He wants to be able to distinguish between script monkeys banging out that kind of crap code, and the people who actually give a rats arse. And fair play to him - I get the sentiment.

Dan North would also say those 3 reasons for writing crap code are inexcusable too - but for differrent reasons. I'm guessing his argument would be that none of those reasons for writing code was actually focused on business value. If I understand his position (and I may not!), he would possibly argue that the main reason for writing code is to give the business employing you value - in terms of cost, return, and investment.

What's funny is that to me, I would guess (and I say guess, because this is all just conjecture - I don't actually know Mr North or Mr Martin) that both of those guys would agree that code should be focused on business value/deliverables, and also on code quality.... with a slight caveat ....

Business value isn't always equal to code quality. It *usually is* - but not always.
(Side topic - who the frick makes that decision eh ? Most times a dev makes it, they've got it wrong in my experience).

So why all the hoo-ha ? Who gives a frick if we're craftsmen or not ? Well, Uncle Bob and Dan North seem to, but I just don't get why.
As I see it, crap coders will write crap code all the time. Thats not a craft, nor is it adding business value.
Good coders will write good code, that adds business value.
Good coders, under pressure, will mostly write good code, sometimes crap code.
Great coders under pressure will write crap code - but will go and fix it asasp - and will lay awake at night, worrying about it.

Now to me suddenly, that does sound like a craft - in as much as novices do crap stuff, intermediates do much good stuff, experts write great stuff most of the time (no-one writes good stuff all the time).
There was a talk that Dan North did ages ago that talked about the transition from novice to expert - its a sociology thing ... can't remember it right now - think it was a oredev 2008/9 talk.

Good coders focus on the value to the business.
If we're good coders, then we use the principles laid out in "clean code", and other great books by luminaries in the programming world. We adhere to SOLID (unless we have a reason not to), we employ our refactoring techniques, we test our code, we drive our code from the business endpoint. We are "craftsmen" by default. But are we ? Are we not just doing *** our job ***. Surgeons don't get a pat on the back and a badge just because they did their homework on (sorry, I don't mean it) "best practice", and keep their tools clean and sharp. You know what they get ? They get "yeah - you did your job ... again. Cheers. Next please".

We're not l33t mofos that are at one with the ways of the coding ninja.
We've got a job, that some of us enjoy, and some don't.
Good companies hire good programmers.
Shit companies hire shit programmers (and good ones sometimes).

Being good at your job doesn't make you a craftsmen, it just makes you good at your job. It doesn't mean you can't take pride in your job, or mean you can't consider yourself to be expert (or journeyman, or novice or whatever). It just means we're doing a job like any other - its just that the people best at our job are the ones that are in-tune with the business, and also know how to write clean code.

Ranges header with Silverlight HttpWebRequest

Trying to download a large piece of content, and using the Ranges header to do a pause/resume feature or recover from a network problem during download ?
If you're using Silverlight, and using the HttpWebRequest, you'll find that the Ranges header is not allowed! WTF Silverlight team ?

All is not lost though - more magic settings come to your aid. Before creating the request, add these two magic little lines :

WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
WebRequest.RegisterPrefix("https://", WebRequestCreator.ClientHttp);

This works in SL4 (think it works in SL3 too)

Sliverlight SMF smooth stream player

Can't get your silverlight player to play smooth stream ? Driving you mad ? Yup me too, and this aint the first smoooth stream player I've written ... but not having access to the code for the previous ones, it was driving me crazy.

I kept getting the dreaded AG_E_NETWORK_ERROR 4001 - very helpful.

Anyway, all is not lost. If you're using the SMF (Silverlight Media framework) player as the base player, check you have the following references :
Microsoft.SilverlightMediaFramework.Plugins.SmoothStreaming.dll
Microsoft.Web.Media.SmoothStreaming.dll

And also, make sure you have this magic setting when setting up the PlaylistItem :

DeliveryMethod = DeliveryMethods.AdaptiveStreaming
MyPlayer.Playlist = new ObservableCollection {
new PlaylistItem
{
DeliveryMethod = DeliveryMethods.AdaptiveStreaming,
MediaSource = new Uri(url)
}
};

51 Degrees mobile redirect and Orchard CMS

51 Degrees current version doesn't support Orchard CMS at its current version (1.0.4.1).
This is because part of the "should I redirect this page for the current request?" logic is slightly flawed.

Part of the logic checks that the request context's http handler class type is in the following list (or has a base type of an item in the list):

internal static readonly string[] PAGES = new[]
{
"System.Web.UI.Page",
"System.Web.Mvc.MvcHandler",
"System.Web.Mvc.MvcHttpHandler",
"System.Web.UI.MobileControls.MobilePage",
"System.Web.WebPages.WebPageHttpHandler",
};
Thats not going to work for Orchard, because it's http handler does not inherit from any in the list.

So the fix is to alter the list as so :

internal static readonly string[] PAGES = new[]
{
"System.Web.UI.Page",
"System.Web.Mvc.MvcHandler",
"System.Web.Mvc.MvcHttpHandler",
"System.Web.UI.MobileControls.MobilePage",
"System.Web.WebPages.WebPageHttpHandler",
"Orchard.Mvc.Routes.ShellRoute.HttpAsyncHandler",
"Orchard.Mvc.Routes.ShellRoute+HttpAsyncHandler"
};
The list is in the class FiftyOne.Foundation.Mobile.Redirection.Constants - which is in the file named RedirectionConstants.cs

It's not a great fix - but thats because the code is breaking OCP quite severly, and I don't have time to fix right now.
Hope this post saves someone else several hours of debug !

Open Source Software - my mullings

I spent 8 years running an open source software project - so I kind of have an idea what its like. Maybe I don't - maybe I just know what its like running an OSS project that is small.

I pushed some software OSS because, at the time (and this was back in 2002), I felt the best competitors at the time were buggy, and feature poor. I thought people would benefit from my software, and I think some people did.
I had some big people using it at some point - Xerox and Maersk were the biggest I think.
But mostly, it was fairly small companies, just looking to solve a problem they had, like me.
I wrote a Java connection pool - it was going against the main competitor, Apache's DBCP, and a few other OSS offerings like C3PO. You get what you take, and you take what you can get. Some people preferred mine, and some people preferred others.

So its cool for a while - you get people interested in your project, and thats great. You do some bug fixes, you feel good - you feel like you're part of the community. Jetbrains gave me an OSS IntelliJ license because I was OSS. Cool - part of the solution, not the problem.

But after a few years, you get a bit bored - most developer's I've met do.
I wound download my OSS a few months ago (well, say wound down - I just switched off the site - bad I know). But why did I do it ?

There were a couple of reasons -
1) To me, no-one ever seemed to contribute. I used to get a few "here's a bugfix" emails, and that was cool - and I appreciated them wholeheartedly - but on the whole I was contacted by hundreds of people over the years that would seem angry that "x" wasn't implemented or "y" had fricked over their site.
Now I worked hard to fix the critical bugs - I remember even taking a day off as holiday from my work position to fix a particularly bad bug (no - I wasn't supported by my workplace to work on the project, even though they were using it in their key systems).
After 8 years, 3 bug fixes from external sources makes you think "this is all take, no give".
2) I got better at coding. I started to get ashamed of the lack of unit tests, and shoddy coding. I wanted to retire it because I no longer respected the code.
3) DBCP caught up ! Its now, I believe, better (in the main sense that its better supported and no longer barfs under load (they had threading issues)).
4) I've moved on from Java ... I no longer see Java as a relevant language.

I've had a few emails since saying "where's it gone ?" and I've given them the source code ... but to be honest, I don't think my little project would be missed.

Which brings me on from the navel gazing to the real point ... I've been using a lot of not-well-known OSS lately, and I'm not really chuffed about the quality of it (which was one of the main reasons I got out of my own OSS offering).
I get that its great that you're giving out to the community - I did it too - but in 2011, is it OK to ship OSS software that isn't tested ? I'm going to go with no.

A lot of these guys are just people out there trying to give to the community, and I do respect it. It just feels there is no-where to when they don't know. Or when they get bored, like I did.

How do we (as a community) write quality OSS when the demand is small (but probably important to those using it) ?

Maybe there's an answer out there, maybe not.

Writing a JSONP codec for openrasta

So it seems Openrasta supports json out of the box, but I needed it to support jsonp - in order to do cross-domain calls.

Stealing the original json codec, I've implemented a jsonp codec, code below.

Really enjoying openrasta so far - very quick to get up and running, simple conventions, and easily extendable !

To use the codec :

ResourceSpace.Has.ResourcesOfType<MyStuff>()
.AtUri("/mystuff")
.HandledBy<MyStuffHandler>()
.TranscodedBy<JsonpDataContractCodec>();

AppHarbor - Continuous delivery done right

So I've just joined a startup dev company - http://www.agilex.co.uk , and we were wondering what to do about environments.

We didn't really want to run a bunch of hardware out of our office, as we couldn't really afford it, nor could really be bothered with it.

We'd heard of, and used Heroku in the past in a non-commercial sense, and it looked pretty cool, but only supported ruby based apps. Then we fell upon AppHarbor - Heroku for .NET, or as they say "Azure done right" (cheeky little hook , but I love it !) .

If you know nothing about appharbor or heroku - the principle is this : we'll host, compile and deploy your code. Oh, and we'll also run your unit tests, and if they fail ... no deploy. Its all hosted on Amazon's EC2 clound offering, so can scale nicely.

So it sounded great for us, and to be fair we were only looking for a couple of things - we wanted to push our code somewhere where we didn't have to maintain the hardware.

But after a few days of using appharbor, it slowly started to dawn on me that appharbor is so much more than a hosting platform which compiles and deploys your code.

Its flippin' continuous delivery. With a single click (or git command). And they're doing it - right now. And you can too :)

As someone who's being in the agile space for a while, I'd always looked upon continuous delivery as a bit of a golden unicorn (or do I mean goose ?)- I've heard people do it, and wanted to get there, but the implementation was always elusive to me.

If you think about how hard continuous delivery is - its quite tricky. OK, maybe its not rocket science, but places I've worked in the past would have trouble implementing it.

Thats what is so amazing about appharbor - they've done all the legwork - they've automated the frick out of the whole process.

New IIS site ? Clickety click. Done. New DB ? Mysql or SQL Server sir ? Done. Deploy your code sir ? Push once again to the appharbor master, default master branch, with the build behaviour, with the build behaviour ....

I feel liberated - I don't care about system teams, DB teams, copying code to here, maintaining that CI server there -I just "push once again", and my code is live (and if you want to roll back the code, you just click "deploy" on a previous version. Yay !).

So its been weird - I suddenly have continuous delivery. And all I had to do was sign up to appharbor. Its that simple. It can be for you too : http://appharbor.com .

Their tagline is "Azure done right". I'm sure thats true - but for me, its more than that - its part of the agile journey done right.

BTW ...

@ferventcoder has some great videos on appharbor where he throws the magic of roundhouse & other chucknorris goodies into the mix : http://geekswithblogs.net/robz/archive/2011/02/18/appharbor---azure-done-right-aka-heroku-for-.net.aspx

If @appharbor is reading this - please find a way of pulling that chucknorris craziness into the DB space !

Kanban and Scrum.

Whilst I've been trying to do agile for several years, I've never been in a scrum team that I would consider as really working. I'm sure there are scrum teams out there that estimate well, sprint well ,and deliver great software. But I've never been in one, and I'm sure there are a lot of people out there that have had a similar experience as me in implementing scrum. The point of this post is to offer an alternative - something that might work for you, if scrum isn't.

There will be some people who read this that will argue that I've never done Scrum properly - that my pain-points are due to the fact that a lack of engaged product owner, or overzealous project managers, or an undisciplined team.

Whilst that might be true, I've tried to do scrum in 4 companies over the last couple of years, and I feel a theme is emerging (and yes, I know that theme could well be "you is doin' it wrong").

On paper, Scrum seems good - estimate some work, check your velocity, fit the the number of stories into the sprint as will fit that velocity in order of priority. Do the work; sprint ends, demo to the customer; accept feedback. Rinse and repeat.

Waterfall says analyse some features, work out how long it will take, commit to a deadline. Do the work, timebox ends; demo to the client.

But in my experience, Scrum often feels a bit like mini-waterfall.

Scrum's not exactly the same as waterfall - there are some clear improvements that exist in the scrum approach - quicker feedback, ability to change course & react to stakeholder input. Estimation of work is better because you're estimating every 2 weeks rather than once at the beginning.

But when I'm doing Scrum, I feel that its not enough - the feedback isn't quick enough, and the project managers start to treat it as a sequence of mini-waterfalls. They start asking why we didn't manage to fit in all the stories we put into the Scrum, and start micromanaging.

Now there are several reasons it feels like this - the main ones probably being that the PM's never really get on board with Scrum, and push the "feeling" of it to mini-waterfall. Coupled with that fact that the team is probably not very good at estimating, and we're not really engaging with the stakeholders, and still using PM's as proxy stakeholders.

But thats one of my problems with Scrum - its almost too easy to fall into mini-waterfall when you don't have available all the aspects that would make Scrum succeed - access to stakeholders, and either PM's that embrace Scrum (or dare I say it no PM's at all).

I'm also not particularly engaged with the idea of velocity or timeboxing.

When does a business care about velocity ? What does velocity mean to them ? Businesses deal in money and days. I've never been comfortable with this fibonaccian sequence of abstract points. I don't know what they mean. I'd rather say "small, medium, large, crazy big". I know that small is a couple of days, medium is a few days, large is a week, and crazy big needs to be broken down.

Timeboxing feels like overcommitting - in the same way waterfall is overcommitting. In most sprints I've been in, we've either delivered everything, and pulled in more work, or not delivered everything we'd estimated we would. I've rarely delivered exactly what we'd estimated.

Now that could be a problem in estimation, and I'm sure there are teams out there that are making it work, but I'm sure there are plenty of people who arn't.

So why do I think Kanban sorts out the pain-points I've experienced with Scrum ?

Scrum "pushes" work (a bunch of features) into a timebox. Kanban "pulls" work on a feature by feaure basis.

I like that for several reasons.

Firstly, it leaves little room for PM's to take control. Work is done when work is done.

The business just cares about delivering features - and Kanban gives that. The business doesn't care about velocity. The business knows if a team isn't delivering software quick enough - you don't need velocity to tell you developers arn't up to scratch. A business should employ developers that care - if they care, then you'll get good software delivered quickly. Its about trust, and respect.

Secondly, the feedback cycle from Kanban is immediate - you don't have to wait for the sprint to end. Couple with continuous delivery, the business sees immediate results.

The pipeline is simplified - get feature, clarify it, code it, push it.

I think Kanban can also work for PM's as long as they back of a bit. PM's need to engage in costing and timesheets - a fact that developers often don't understand, nor care about - but businesses often need. But with Kanban, costings and timesheets are done at the end of the pipeline - after the fact, not before it. They'll work in facts, not estimations, because the feedback cycle is so short (ie features get completed and signed off every few days, not every few weeks).