Software People Inspiring

Marketing Codemanship: What Search Terms Do I Pick?

 

I recently got about $50 of free Google AdWords vouchers to help promote my company web site, codemanship.com. Yay!

Only, not so yay... You see, I've stumbled across something of a puzzle. I don't - repeat, DO NOT - want to tout myself as an "Agile Coach", or indeed, an "Agile" anything. Because, when I use that word - even just in passing - I immediately get pigeonholed by clients as a Scrum Master. Happens every time. And that's not business that particularly interests me, but it's a tough expectation to break once the perception's been established.

But if I'm not selling Agile coaching, then what, exactly, am I selling? And this is my puzzle. What keywords could I choose to have my Google ad appear when IT or development managers search on them looking for my kind of services?

Would an IT manager search for "software craftsmanship"? Very doubtful. Indeed, these days very few people are searching for "software craftsmanship". I know this because the SC2009 web site ranks second in Google's search results for that phrase, and my web stats tell me interest via search engines is very, very small compared to, for example, "use cases".

So I'm a bit stuck as to what keywords I should hang my hat on here. If a company's software/systems are poorly crafted - unreliable, untested, untestable, overly complex, hard to fathom, riddled with duplication and the worst kinds of dependencies - how could I use search engine advertising to find my quarry? Indeed, would a budget holder ever be actively seeking what I'm offering?

Free Pencil & Paper UML Trial Edition

 

When people ask me what my favourite UML modeling tool is, I tell them that pencil and paper is the one to beat (or marker and whiteboard, if you need team modeling capabilities).

It's possibly a sign of our times that many software developers have not heard about "pencil and paper" before, and the follow-up question is usually "where can I get a demo version of that?"

So as a service to all your pencil and paper novices out there, parlezuml.com is giving you 10 blank sheets of special UML modeling paper which you can use to evaluate the tool today.

Devin Townsend's Ki

 

Hoorah!

Devin Townsend's latest album "Ki" (pronounced "Kee") is almost upon us and you can preview many of the tracks on YouTube.

This Canadian chap is, in my humble onion, by far the most talented singer/writer/instrumentalist I've had the good fortune to listen to.




Full Title Track, Ki

Twitter Re-Educates Me On "Value"

 

Twitter is currently teaching me a valuable lesson in - er - value.

Whenever I try to log into the service at the moment, be it via the web site, from my mobile phone or via TweetDeck, it's 50/50 that I'll actually get a response from the site.

If I am successfully logged in, when I submit an update it's 50/50 again that it'll actually get successfully posted.

Add to that some "logic quirks" with the functionality itself and some very dodgy AJAX nonsense going on, and we have one demonstrably flakey Web 2.0

And yet current speculation from those in the know (though the crisis in our financial markets maybe suggests that these people know nothing) values Twitter at some ridiculous, astronomical figure. We're talking the GDP of a small, but developed, economy here.

I am still convinced that a team of 4-6 good developers could deliver Twitter pretty much as it is on the Google App Engine in less than a fortnight. And deliver a far more reliable and robust implementation at that.

But how does the relationship between reliability and value work in this case? It calls into question the simplistic predictable relationship - a commoditised version of "value", if you like - that we've been assuming when we talk about things like "value streams" and "sustainable delivery of value".

If Twitter runs on just a few thousand lines of code, and I suspect there's very little under the bonnet in reality - then, if the service is valued in the billions, each line of code could be carrying the weight of millions of dollars in equity.

Imagine writing a line of code knowing that! How much time and effort would put in to making it right, and into making it scale?

Except, of course, Twitter's developers had no idea when they wrote it. And neither, I suspect, do any of us when we're writing code. No idea at all.

SPA2009 Session Practical - Scalable.NET Design Reviews Using Automated Code Analysis

 

If you can't make it to Software Practice Advancement 2009 this afternoon (or of you did make it and you want a reminder), here's a Flash movie of the practical elements of the session created in advance using the indispensible Camtasia Studio.

The thrust of my argument - because my arguments tend to thrust, dontcha know - is that code/design inspections are a form of testing, and when we do testing manually it's very labour intensive and doesn't scale cost effectively. For the exact same reasons that we automate functional tests, we should aim to automate our design/code quality tests as much as possible so that we can spot problems early and deal with them cost-effectively.

One thing we'll probably discuss is how we tackle design/code quality in an Agile, Scrum-like process. Well, if we're doing TDD, then I would suggest beng test-driven about it might work best. Along with your user stories, you could write "quality stories", like "As a design authority, I require that methods are kept short so that they're easier to test and easier to understand" and then developers could stick that in the backlog and champion it's inclusion in iteration planning*. When someone picks up that quality story, they could go to the design authority and agree acceptance tests - and this is where our automated analysis comes in. We could use a tool like NDepend to detect long methods, and if they fall outside of an agreed tolerance we could raise the alarm almost as soon as a method grows too big. Maybe it makes the buid fail. Maybe we have to refactor it there and then to get the build green again. Well, a man can dream, can't he?!

The examples use NDepend, but the principles can be applied using a whole bunch of tools that focus on a whole bunch of different aspects of design quality.




* And yes, I know giving the customer the choice will almost certainly mean that no quality stories ever get scheduled. In which case a portion of the budget should be controlled by the developers (e.g., 20%) so they can make sure at least some of it gets done.

Spurious ID Theft Statistics?

 

A sales representative from the bank that issued my goldcard just called to try and sell me the services of an "identity theft alert" service from one of the credit reference agencies.

She quoted the statistic that 71% of people have been victims of identity theft. When I questioned that figure, she then claimed that it included attempted ID theft. I then asked her what proportion of those attempts were successful. She didn't have that information to hand.

I then asked her where she got the figure of 71% from. Apparantly it was from a completely independent survey conducted by the very same company whose services she was trying to sell me.

Hmmmm.

Undaunted by my skepticism and rejection of their ID theft alert service, she then went on to ask me if I would like to transfer cash from my credit card account into my current account.

This was literally while we were waiting for a credit card bill payment from my current account to go through...

They seem to be getting a bit desperate, one suspects.

Are Dynamic Languages The New Black (Again)?

 

I must say, I'm not so big on accepting things at face value.

And in my line of work, there's a whole bunch of "facts" and "accepted truths" that are anything but. Much of our understanding about why things tend to work (or don't work) is arm waving at best, and totally non-existent at worst.

Take the current perceived trend towards dynamically-typed scripting languages like Ruby and Groovy. Proponents of such languages cite the relative flexibility of dynamic typing compared to statically-typed languages like Java and C++. Type safety, they argue, can be achieved through unit testing. Write a test for a.b(c), and if a or c are of the wrong type in that scenario, the test will fail when the interpreter gets around to checking what's in those slots.

True enough: provided your unit tests provide adequate assurance. And, let's be honest now, 95% of teams' tests don't. Not even close.

More important to me, though, is this underlying assumption that we should make the extra effort because it's worth it to allow us to work in dynamically-typed languages. Why so, I wonder? I've worked in a selection of such languages, practicing TDD very fastidiously, and found no net benefits.

And now I see .NET folks relying more and more on var declarations, because - well, apparantly because they can and the books and blogs say that they should. But I'm not sold on the reasons. Greater run-time substitutability? Perhaps. But why not just make all methods virtual by default unless otherwise specified? Why not make it so that any class can be extended and any method overridden, if that's what we apparantly crave? For sure enough, if we call a.b() and a doesn't have a b() when it comes to execution time, then what have we really gained?

I put it to you that the current fashion for dynamic languages is excatly that - a fashion. And many people are using them because they've seen other people using them, and they want to be in with the in crowd.

I'm not saying dynamic languages are bad, or that we shouldn't use them. I'm just questioning the received wisdom that they are somehow better than statically-typed languages. In the absence of any hard evidence to support that, I'm forced to remain agnostic.

UPDATE: Reading people's email and blog responses has highlighted another issue with dynamic languages, which is that we don't all seem to agree on whast we really mean by "dynamic".

XDepend - Like NDepend, But For Java

 

Master of understatement, Patrick Smacchia, has quietly introduced a Java variant of his insanely revealing .NET code analysis tool NDepend, which - because the name JDepend was already taken - is called XDepend.

It supports the same dependency analysis, metrics and Code Query Language as NDepend, and people who have built tools that integrate with NDepend outputs files will no doubt find their investments reusable here, too.

Hoorah!

Next stop, I suspect, is a LINQ for code analysis, which will allow some very sophisticated queries indeed, making it possible at last to automatically search for complex code smells and other design quality problems (I have the specs all ready to go) - possibly in NDepend 3.0?

Aspect-Oriented Programming On The Cheap

 

If you're sat at home alone twiddling your thumbs - or whatever it is that you twiddle when you're sat at home alone - why not take on a little project to keep your mind and your thumbs (or whatever) busy?

In spare moments - which these days come mainly while I'm on the crapper (if you only count the spare moments when I'm awake and sober) - I'm pondering the whole problem of cross-cutting concerns and what to do about them.

If you're not sure what I'm flabbering on about, a cross-cutting concern is a piece of logic that, because of the limitations of procedural and OO programming langauges, gets spread throughout the software causing much heartache and howsyourfather when the inevitable time comes when we have to make a small change to that piece of logic.

For example, say we wanted to log every public method call. This is not easy to do in a language like C# or Java or Ruby. Or Commodore BASIC, come to that. We end up with a block of code inside each public method that has to be invoked before the body of that method. If we decide to change the way the logging interface works, then there'll be tears before bedtime. We'll be forced to make that change in every public method. Boo hoo!

Yes, I know we have a way around that now. It's called aspect-oriented programming. And it's mighty fine for dealing with cross-cutting concerns. In an AO language, we can put all our logging code into a single aspect and then specify that it must be invoked before the body of every public method. Simple as. Bish bosh.

Then if we want to change the logging interface, we only need to do it inside that aspect. or if we decide that we only want to keep a log of methods called that begin with the letter "P" (it could happen) then we just change the rules about where our aspect is to be invoked, and it's done.

There's just one fly in the ointment. Who gets to use aspect-oriented programming languages? Most development organisations I know are still living in the 70's, where objects and windows and instant soup with croutons are considered space age technology, and they are unsurprisingly very reluctant to dip their toes into super-modern AOP water. To your average CTO, AOP comes from the future - probably sent back to kill John Connor and wipe out the resistence.

It's new. It sounds complicated. It sounds risky. Will it actually work? Who will support it? Where do we hire AO programmers? Are they expensive?

So most of us don't get to keep AOP in our toolbox of potential solutions. We make do with scattering cross-cutting concerns through our code and suffer the inevitable consequences.

But it needn't be like that. I reckon some bright spark out there (he may be called "Antony" and live in Penge - who can tell?) might be able to cobble together a sort of "AOP-lite" in a language like C# using things like attributes, reflection and dynamic code generation.

Let's imagine, for example, an attribute called Aspect that you can apply to a class. And in this class you specify some behaviour, and even find a way to pass in instance variables (perhaps in an array) and info about the calling method. And let's say you had another custom attribute called Pointcut that took, as an argument, a regular expression that described a set of method signatures that the behaviour should be applied to.

Finally, a custom attribute called Advice could be used to attach a body of code to be executed at the join point in the code picked out by a pointcut.

It's not the whole AOP shooting match, but I reckon someone with their thinking cap on could put together a passable .NET library that would allow developers to specify basic aspects, pointcuts and advice to enable maybe 80% of what a language like AspectSharp could do. And it would do it using vanilla .NET and C#, so no need to go cap-in-hand to the boss for permission.

That would be a nice little open source project for someone (perhaps called Josh, for example. I couldn't possibly say.)

Multithreaded Unit Testing Utility for .NET

 

Thanks to Tim Ross who sent me this link to some code written by Roy Osherove that helps you write unit tests that involve multiple threads.

I haven't tried it, but from his blog post, I think whatb it does is ensure that your threads all finish before your test does. Or that they all time out at the same time.

It doesn't answer the question of multithreaded code being non-deterministic, so it won't eliminiate the problem of random failures, for example. But it does at least simplify the business of applying multiple threads of execution in the same unit test.