Software People Inspiring

Announcing A Powerful New Framework - Programming Language

Programming Language is a powerful new framework that enables developers to quickly and easily handle Dependency Injection, Inversion of Control, Model-View-Controller and many other common design problems.

Programming Language is easy to use and takes no time to master. There's a version of Programming Language for pretty much every platform - Java, .NET, Linux, iOS etc. You name it, there's a Programming Language for it.

Programming Language is completely object-oriented (providing you're working on an OO programming platform, of course.)

Here are just a couple of examples that illustrate the power and flexibility of the Programming Language framework.

Dependency Injection in Programming Language for Java



In this example, we use Programming Language to provide a mapping between a method parameter, declared as an instance of some interface Abstraction, and a concrete implementation of abstraction. These mappings are stored in a special, easily configurable file called a "Java class". The client method can now access features of Implementation without binding directly to it, and we can easily substitute Implementation for any other class that implements the Abstraction interface (e.g., for the purposes of mocking or stubbing it in unit tests).

Inversion of Control in Programming Language .NET



In this second example, we use the advanced IoC feature of Programming Language to define the explicit order of workflow in a user interface using a special mapping file called a "C# class". This gives us greater flexibility over the workflow. If we want to change the order of events, we simply edit the special mapping file, recompile and - bingo!

Of course, these are just two simple examples. But I'm sure even the least experienced developers among you will already see the incredible potential of the Programming Language framework.

Here's a list of some of the other powerful features accessible through Programming Language:

* Factories
* Builders
* Observers & Events
* Interpreters
* Undoable Commands
* Adaptors
* Proxies
* Persistence
* Role-based Access Control
* And many, many more.

You can download the latest stable build of Programming Language here.

Jason's Handy Guide To Evaluating Software Packages

I get asked this question a lot, but it never occurred to me to write down my usual answer.

How do we evaulate shrink-wrapped software against our needs?

Well, that's easy. You still need to do the usual business requirements analysis. Identify who will be using this system, and what their goals will be for using it. In the good old days, we called these "Use Cases". Yep, even if you're buying and not building the software, you still need use cases.

The next step is to flesh out the design of your use cases, as we might normally do, by describing how the user interacts with the software to achieve their goal.

When we're describing software we haven't built yet, this is design. When we're describing how we'll use software that already exists, this is a process of validation. Can the user achieve their goal using the software we're evaluating?

Even with the most feature-rich packages, we tend to find we don't get an exact match. It's not always possible to achieve every user goal using the software. So as we validate the software against our use cases, we may identify gaps. There are almost always gaps.

The next question we need to answer is can we fill those gaps? Let's say we're evaluating Microsoft PowerPoint for our training business. It doesn't do everything we need out of the box. Let's pretend we have a use case where the trainer needs to populate a slide with an organisation chart showing the reporting structure of the group attending the course. She has a spreadsheet with those names listed in alphabetical order and with information about who reports to whom. using PowerPoint's built-in scripting language, Visual Basic for Applications (VBA), it is indeed possible to take that information and automatically generate an Org Chart.

So that gap could be plugged, with some work. Write a reminder about it down on a blank index card. This is now a potential "User Story" for some programming work that would need to be done if we went the PowerPoint route.

Of course, people identify gaps in software all the time, and it's possible that someone somewhere has already found a solution to plugging some of your gaps with handy tools and utilities. Google is your friend here: search for solutions before you think about reinventing the wheel. If you find one, and there's money involved, write down roughly how much on the index card.

Finally, don't forget the non-functional requirements. A package may offer the right features, but it may not be able to handle a high-enough volume of users, or it may not be secure enough for your purposes, or it may take a long time for users to learn. Evaluate thye software against these criteria, too. Be as explicit as you can. Handwavy requirements like "it must be scalable" aren't very helpful for validating software. What do you mean by "scalable" - a certain number of users at any one time, or a certain number of transactions per second, or the ability to run it on more servers?

All too often, businesses buy a solution and then validate that it does what they need - often by actually trying to roll it out. Whether buying or building, the key is to have clear, testable requirements and to validate the software against them. Don't be seduced by their sales patter and let them lead you like a donkey to the slaughter to their feature list. What their software does is far less important than what we can do with their software.

Spring Is In The Air

Yesterday was April 1st - April Fool's Day. Lots of pranks were pulled; not that I would ever stoop to such levels, of course.

And pranks from April Fool's Days of yore also redid the rounds. One that did make me chuckle was this oldie from 2006 (Ah, 2006! Those were the days...) Someone claimed to have created an XML version of C#, demonstrating just how easy it was to write simple code using this new markup language.

The idea of writing C# code in XML is thus shown to be absurd and ridiculous. And yet, these days many of us do something very similar. "Dependency injection" and "inversion of control" frameworks do exactly this. They allow us to express things like object creation, dependency injection and flow of control in XML files.

The usual selling point of these frameworks, like Spring and Castle Windsor, is that they enable us to "soft-code" certain key dependencies to achieve a greater separation of concerns and make our applications easier to change. Some even tout the possibility of allowing non-programmers to edit these configuration files and thus make changes to, say, the flow of the UI without all that fiddly coding, building, testing and redeploying. Hooray for their side!

In reality, it's magic beans (powered by electric parsnips). If you edit an MVC mapping file, you can easily end up with the flow of the UI not matching the state of the user's session. A controller may end up having certain expectations - certain pre-conditions - broken because B didn't follow A as originally envisioned. In MVC, workflows are not infinitely flexible. So it's entirely possible to break an application by editing one of these configuration files. And if it can break it, then editing these files must be followed by retesting of the application. And, in my book, that makes them source code - something only a programmer who knows the system and works with good programming discipline can be trusted to modify.

The consequence of that is simple: when you embed DI or IoC or MVC logic in XML files, all you're really doing is converting C# or Java or Ruby or Visual Basic into the kind of XML representation we'd normally interpret as an April Fool's prank. (Okay, with Visual Basic it might actually be an improvement, but you get the point.)

It's entirely illusory that when you extract a dependency from your code into an XML file that you havr removed that dependency. All it takes is one change to the XML and the effect of that dependency can still be felt in the shape of failing tests and broken functionality, every bit as much as if you'd left it in the code. The dependency is still there, and no separation of concerns has been achieved.

The advantage of leaving dependencies in your Java or C# or Ruby or VB code is that they are easier to see, both by inspection, by the compiler and by static code analysis tools designed to help you manage dependencies.

Heavy reliance on these frameworks will also hit your unit tests where it hurts. They'll run slower and the test set-ups will get more complicated and difficult to manage.

And the funny thing is, I never had any trouble implementing patterms like Model-View-Controller, Dependency Injection or Inversion of Control before these frameworks started appearing. MVC is easy. If you want it really decoupled, try implicit invication (you may know it as the "Observer" pattern). Dependency injection literally just means passing in references to objects, making them more readily substitutible (helps with testability, for example). I mean, c'mon. How hard is it to write a constructor or implement the "Visitor" pattern? As for Inversion of Control; well, that just means that instead of baking in a workflow in the interactions between collaborating objects, we defer to a higher-level object that co-ordinates that workflow from above, making it easier to change and also introducing the possibility of changing the workflow dynamically at run-time.

Since those XML files are in effect source code, I see no real advantages in taking what would have been plain old code written in an elegant programming language with good tool support and translating into crappy markup and sweeping it under the carpet, in the vain hope that what the compiler can't see won't hurt us.

I find it better to have all the dependencies out in the open. It makes managing them so much easier.

A Short Rant About Generating Tests From Code

Grrr. Mutter. Grumble.

Just been noodling with Visual Studio 2010 and yet again it seems Microsoft have completely missed the point.

One thing in particular gets my goat: unit test generation from code. As far as I can see, this is a clear endorsement for not doing test-driven development. When you invent tools that work the opposite way around, what message are you sending to impressionable developers?

Generating tests from code is a great way to verify that your code does what it does. It promotes solutions to the role of problem statements, the antithesis of test-driven.

Yet again, Microsoft seem to encourage us to start with the code and work our way back to the requirements by handing us tools that encourage us to think in this direction. Increasingly I find trying to be test-driven with Visual Studio an exercise in planing against the grain of the tool.

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.