you are here: Home Blog Development

A common concern I hear when working with teams is how much time should we spend in design or architecture of our product.  I had a real nice conversation with a team last week around this topic and wanted to share some of that discussion.

The conversation started with a comment around 'we were told in agile we don't do any design. That seems crazy.  How do you find the right balance.'  No design or architecture consideration ever is crazy.

Del.icio.us!StumbleUpon!
  • 0 Comments

Growing up the youngest child meant that my closest brother (6 years my elder) would terrorize me with threats of the boogie man coming to get me.  It was a rather effective tactic - how to deal with the boogie man wasn't well known and the internet was just a glimmer in Al Gore's eye.  I see and have been part of a similar tactic in software development.  I have terrorized product owners and business sponsors with the concept of technical debt.

'Ooh, that change is going to take a long time. That code that so-and-so wrote 3 years ago is real bad.'

Del.icio.us!StumbleUpon!
  • 0 Comments

You are a responsible developer, practicing TDD and keeping your code clean through refactoring.  Your 'bar' is always green, but are you living and developing in a world of 'False Green'?  Is your green bar continuous or is it only measured at points in time - when you run your tests for example.  At the Lean Conference in April, Joshua Kerievsky gave an excellent presentation titled 'The Limited Red Society.' A summary of this presentation can be found on Joshua's site here and the video can be found here. Synopsis: we need to be aware of the state of our code at all times, not just when we run our tests.  In the real world, things may break at non-ideal times, like during the middle of a refactoring, and we must fix them. Joshua's session really hit home about a month ago when I felt like I was refactoring with fire.


To set the stage, I was working solo on some custom code for a customer.  I developed it test-driven and had solid tests.  After I delivered the code to the customer, I saw a great spot for refactoring and simplifying the code so I dove in.  Then the customer came back with a change...but I was in the middle of refactoring! The change would only take me about 10 minutes but the refactoring session would last another hour or two to get to the point where I wanted it.  Right then I felt like I was refactoring with fire.  This was only a 10 minute change but a production emergency could go on quite a bit longer and I would be leaving my codebase unstable. I vowed to not let that happen again.

Del.icio.us!StumbleUpon!

I've said it myself before - this software needs to be designed properly; You know, foundation of a house, and such.  Once the design is solid, oh just trust me, we will create some software real fast.  And then we went off to ponder and pontificate, and create documents showing how elegant this solution would be.  We used and diagrammed all of the proper patterns, creating interfaces and abstractions along the way.

We wrote code; tons of code.  We deviated as we learned more of the system, as time became tighter, and so on.  Once the project was released, 'Someone should really update that design document'...and no one does.

Its common, it happens.  I've done it.  But this isn't about the benefits of emergent design, lets look at the common idiom of our software being a house.

Would you want the real version of the house based on the software you build?  Would you want your contractor to agree to a set of prints up front, but once you move in realize that the only way to turn on the lights was to flush the toilet?  How about that study you wanted?  Would you be happy if your carpenter decided that you, 'the user', wouldn't need a study?  Would you feel better if afterwards, the architect came back and updated your blueprints?

4,192,876,492 - that is my estimate of the number of unneeded interfaces in code out in the wild right now.  Would you want that many light switches in your house, you know, in case you wanted to switch something else on besides the ceiling light?

Houses can have blueprints because they are based upon static principles with high commit costs.  A foundation is made of concrete.  You can change it but it will cost substantially and can create structural risk.  Software is malleable and code is not concrete.  We should be exploiting that benefit instead of trying to move towards a less flexible model.

Lets take this a step further.  Houses are built upon civil engineering principles - stress loads of materials, heat dispersion, pressurized values of systems.  For example, the beams supporting your walls are probably slightly over 14 inches apart.   That is not because that was a good number to go with.  That is because we know, through testing, that the stress load we can expect a wall 2 by 4 to support is actually 24 inches on center but because of the varying in woods (drying, species), most carpenters build at 16 inches on center.

What would be similar in concept to this?  Programming languages, platforms, maybe containers or frameworks.  We know how languages function in certain applications and situations; what platforms work best for certain targets; what containers will provide for us.  Even these can be changed - swapping containers shouldn't be painful.  These items are addressable upfront.

Finally, have you ever heard of a civil engineer say 'concrete isn't good enough for this common residential house, I am going to invent something new.'?  You don't, it would be ridiculous, overly costly, and people could die.  But in software, too often we design and say something similarly absurd. 'We need a custom web server, Apache wouldn't scale for our special problem'.  That statement is as ridiculous as trying to make your own concrete.













Del.icio.us!StumbleUpon!

I was recently asked to do a prototype for migrating some, well, lets say not very recent user interfaces to a more web based view on them. The first test was to just make sure that a web based application could perform fast enough and we didn't need to go swing. For the record, I'm not a swing fan because of all the layout finagling and I sure don't like GWT doing all my work for me. Call me a purist or an idiot, your call.

I check out what the users want and come up with a nice thin app using JQuery on the front end communicating via REST services responding with JSON for the datasets. Pretty standard stuff. Nothing too revolutionary there. If you're not using REST, I'd recommend it but I can get on that soapbox later. What was interesting was the request that these workers prefer to use keyboard shortcuts. In essence, I was asked to make a web based application that didn't use a mouse. Pretty interesting and different than usual.

I toss together this prototype and demo it - first suggestion was could I make it so there was just a text box interface where users could type in shortcuts and then use key combinations to drive functionality.

The solution I ended up with uses the hotkeys plugin for jQuery -
It is crazy easy to use, here is binding the f4 key to execute whatever is typed in the text window:

$(document).bind('keydown', 'f4', function(){ executeCLI();});

function executeCLI()
{
var cliString = $("#prs_cli").val().trim();

//Process cliString, call more functions, etc
}


Its crazy simple to bind functions then to key combinations. You can even bind key combinations, i.e.

$(document).bind('keydown', 'ctrl+c', function(){ executeCopy();});


Why would anyone do this? At first I asked the same question. The mouse is there, use it. But then I started using the CLI interface for the web. Think about how faster you, the maven, are with CLI? Think about the experienced user being able to interact with web apps this way. Pretty cool and effective stuff.

So check out hotkeys and maybe think about some CLIs for your super users of your web apps.

Del.icio.us!StumbleUpon!

To the contrary of my previous post, I thought I would say what we do know. Without further ado, What we do know (an abbreviated list...well, hopefully)

  • We know that its hard to keep an architecture simple
  • We know that if you have a solution or tool in place that has a 'large impact for replacement' - boy oh boy, did you either eff up the use of the tool or did you purchase one sh1tburger of a tool to start with
  • We know that if you want your employees / team / co-workers to be engaged and highly productive, you have to allow them to be engaged and highly productive.

Perhaps I will dive into this in more detail in future posts.

Del.icio.us!StumbleUpon!