Code Blocks and Pictures of Dogs! Markdown Blogs from Here On Out!

Hey readers!

Exciting news! Remember all of my old terribly formatted blogs with the hideous lack of Code syntax highlighting? Well my dearest and most loyal readers, it thrills me to announce that I am finally making the switch to a medium of expression that my inner geek deems worthy.

MARK DOWN FOR WHAT!

Being far too lazy to learn a decent enough amount of HTML to make any kind of visually flexible posts for my dearest readers, the switch to the Markdown should come as a warm welcome for all relevant stakeholders. Thanks, StackEdit!

Expect code blocks!

public class Shrek () {
    public boolean isSexyFlyBrownBaldGuyWithBeard() {
        return true;
    }
}

More code blocks!

public class ShrekTest () {
    private Shrek shrek = new Shrek();

    @Test
    public void testShrekIsSexyFlyBrownBaldGuyWithBeardTrue() {
        assertThat(this.shrek.isSexyFlyBrownBaldGuyWithBeard()).is(true);
    }
}

And maybe once in a while even a PICTURE OF A DOG!


Exciting times! Keep an eye out for some new Tech Blogging from yours truly in the very near future!

Cheers,

Shrek

UPDATE: This markdown tutorial is awesome!

Gojko Selfie!! A Brief Introduction to Impact Mapping

Hey all,

Check out this bad ass selfie:

Earlier this week, Orion Health's Continuous Delivery guru, Richard Paul and I had the pleasure of attending Gojko Adzic's brilliant course on Impact Mapping!  For those of you who don't know who Gojko is, he's considered as one of the game changing minds in the Software industry today.  He travels the world consulting for Software firms in trouble and running courses on Agile, BDD and more!  

He is also the author of the hallowed tome of BDD, Specification by Example!

Impact Mapping is all about mapping from an organisational goal to a solution by identifying the impact the solution has on the relevant users.  Gojko argues that the only reasonable impact to observe is a change in behaviour in your users.

One great example he presented us with was a Facebook games development company he consulted to.  They wanted to introduce a whole host of features including the posting of levels and achievements, and invites to friends in the hopes of increasing their player base.  Before they went ahead and shipped all of these features, Gojko had them draw an impact map from their goal to their solutions as follows:

From this they identified slices through the map, one such slice being:

• Goal: 1 Million Players
• Actors: Players
• Impact on/change in behaviour of Actors: Players Posting more about the game on Facebook
• Solution: Ability to post Level-ups to Facebook wall

Using the divine powers of Agile, the company pushed out just this feature and paid close attention to the pertinent metrics:

• Are people posting more about the game to Facebook? (The Impact)
• Are we closer to having 1 million players on Facebook? (The Goal)

What they found was that there was no marked change in behaviour:  no one wanted to spam their friends' news feeds when they became a Level 7 Wizard.  No impact was observed and obviously, no progress towards the goal was made.

Following this, they sliced the Semi-automated invites feature and observed that there was indeed a large number of players inviting their friends.  But unfortunately, none of their friends were accepting the invites and the goal was no nearer.

Effectively, Impact Mapping is a decision making paradigm for Agile software development companies that focusses on prioritisation based on company goals, not features.  When implemented, it allows for informed business decisions to be made.  The over-arching philosophy is to deliver impacts, not software!

To pull it off effectively you need:

• A really really fast release process (I'm looking at you, Richard :) )
• Metrics that mean something to the business

I can only say so much in a blog post.  I have a million thoughts as to how this can be applied at my workplace and for my own projects and after reading this I'd imagine you would too.  If you would really like to dig deep into the topic, I'd strongly suggest checking out Gojko Adzic's Impact Mapping book or heading to one of his classes when he's in town!

Let me know what you think of all this below!

Cheers,

Shrek

The Most Irritating Software Development Attitude

Hey all,

Over the years of being a Software guy I've come to develop some serious irritations with some ways in which development is approached.  Be it BDD, Agile or Object Oriented programming, it seems no development paradigm has ever managed to avoid being completely misinterpreted and abused.

One of the typical issues I've seen with the uptake of a paradigm is developers thinking they're doing BDD just because they're using Cucumber.  I wrote a blog post about this.

The term "REST" seems to be thrown around whenever a service is written using Jax-rs.  There doesn't seem to be much consideration for the fact that REST is a specification for sound semantics around the use of HTTP, which you could find out by simply looking up what REST stands for and why.

Object oriented programming seems to have deteriorated to "I'm liberally using Java-isms", and the blight of 1000-line classes with names like "GenericUtility" continues to spread.

I could go on.

So what anti-pattern can we distill from this mess of paradigm-abuse?

From what I have observed, it all seems to boil down to this:

"Using the tool means I'm following the paradigm".

This may sound sensible at first glance.  Clearly tools like Java, jax-rs, cucumber etc. were written to support particular paradigms.  All I have to do to follow these paradigms is to use the tooling that supports them, right?

I'd like to make the case for why this is horribly wrong.

Let's take the REST example.  REST (representational state transfer) is a specification for clean use of HTTP semantics to support the design of fluent CRUD-based web services.  Jax-rs is a set of java APIs that support the development of REST web services.

Say our business problem is to create a web service API for the managing of documents.  Jax-rs can be used to create a "/documentCreate" service with a POST method for the purpose of creating documents.   It can be used to create a "/documentRetrieve" service with a GET method that allows you to retrieve a document.  However, as "representational state transfer" suggests, URL paths should represent resources, not actions, and HTTP methods should represent changes in the state of a given resource.

The above is clearly not a RESTful approach, the RESTful approach being to create a single "/document" resource with the appropriate POST and GET methods.  Jax-rs facilitates the creation of RESTful interfaces, but it cannot mandate that it is used correctly.  As a result, it is time and again used to create semantically unsound, noisy looking web services with the label of "REST" slapped onto them.

And on that note, I return to my point.  The attitude of "using the tool means I'm following the paradigm" is plain and simply damaging and un-conducive to writing good software.  But let's give this attitude a bit of merit.  I think it stems from the urge to get things done, a pragmatic mindset perhaps.  My take on a solution to this is to encourage a healthy balance between pragmatic and academic thinking.  Don't just get things done, hit the books regularly too.

So in summary, using Cucumber doesn't mean you're BDDing; using jax-rs doesn't mean you're following REST; using Java doesn't mean you're doing OO and so on and so forth.  Using the tool does not equate to following the paradigm, so learn the paradigm before you start using the tools.  Hit the books, develop an opinion on any given paradigm, then get to using the appropriate tooling!

Let me know what you think below,

Cheers,

Shrek