Fresh ideas at Refresh Belfast

I attended Refresh Belfast on Monday (summary here) and it was very enjoyable.

I'll not get into the whys and wheres (it's well summarised above) but it was presented by Front a Belfast-based web design studio. When I attend an event like this, the first thing I look for is to be challenged (mentally, not physically)! There's nothing worse than a "look at us, we're all web guys, aren't we great" presentation. I'm pleased to say that the Front guys did an excellent job in pushing the often over-looked design aspect of web site development.

As an IT guy, design means architecture mostly - which of course is important. But, when dealing with web sites, the whole experience of the site is something that is extremely difficult to describe and get right. A great architecture won't do it and a great graphics guy won't do it either. A lot of the techniques described by Front where similar to a talk I heard from Gerard Meszaros at Agile2008 called "From Concept to Product Backlog. What Happens Before Iteration Zero" slides here. He spoke about all the things you need to have covered before you start coding and Front pretty much came up with a lot of similar tasks. I suppose it's the solid design theory that's coming through here and is so often skipped over in pure IT houses. This is something that IT guys are becoming more aware of, thanks to people like Alan Cooper, but it's great to see a local company like Front pushing boundaries.

Paul McKeever and Jamie Neely both gave great talks on the importance of the design phase and how Front are very committed to strategy and social aspects of the web instead of just firing up a load of images and links. Very admirable. A mention must also go out to Andy McMillan who seems to be organising a load of good solid Web events in Belfast! More power to him as this is the kind of stuff we need to be doing to start innovating as opposed to surviving.

P.S. Thanks to Paul McK for the encouragement to blog this, I need someone to poke me every week... Blog now!

BarCampBelfast

I gave a talk at BarCampBelfast last week, which was good fun. The talk I gave was called "5 non-techie ways to be a good programmer". I wasn't sure on the audience level, so I decided to give a fairly general talk. I figured there would be a lot of web programmers and a lot of designers, so I sort of came at it from leftfield.

Here's the link - http://prezi.com/44606 (I used a funky presentation tool).

I wanted to outline the non-technical qualities I thought a good programmer should have. I didn't want to scare people away (I only had 30mins), so I kept the points quite straight-forward. I was also aware that a lot of attendees might be students, so I figured they'd be mad keen on the technical stuff, but wouldn't have heard much about the "people skills" of programming.

1. Question Everything
2. Take a wide berth
3. Be a realist
4. Measure don't guess
5. Be Up front.

The 'take a wide berth' was the only funny point. I wanted to keep a joke in there about giving programmer's a wide berth. But the main point was basically "generalise don't specialise". And funny enough, that's what I was questioned about. Maybe when you start off with programming, you want to learn one tool really well, as opposed to building up your overall skillset.

The unconference was a great way to spend the day and I'll definately attend the next one in November!

Would you ship shit?

I had reason the other day to re-read Uncle Bob's post on "We will not ship shit".

Uncle bob is cool - I heard him speak at agile2008 and although he is a show-man (nothing wrong with that), he speaks a lot of sense. No, you don't take everything he says literally, but I reckon he's spot on.

You are participating in a project as a technical guy. You answer these questions:

Can we do it?

When will we have it done by?

 Then you start and construction runs it's course. But, there are a few unforeseen problems... And you hit the agreed deadline (it's a hard deadline, no free and easy flexible deadlines here). The next question is:

Will we ship this?

This is a much harder question than the first two. It's way more difficult to say No because so much time and money has been invested.... BUT, you are the technical guy... Remember the old sayings of "Is it Done yet?" and Technical Debt? Your technical know-how was good enough in the conception phase, but what about now in the construction phase?

Masterchef - 45 mins to cook a dish. An amateur cook prepares a meal for food critics - it's a British TV show. The guy is cooking seafood and is running 5 mins behind schedule. Does he:

1/ make the customer wait?

2/ serve under cooked food?

 The inexperienced chef always hits his deadline, but one of two things can happen:

1/ Customer notices fault (raw seafood) and will not eat it. Bad Customer Experience.

2/ Customer is ignorant, eats the raw seafood (which is full of bacteria and bugs) and is sick the next day. Bad Customer Experience.

You have a responsibility as a technical guy to hold up the project if the quality is poor. Of course there is a business impact here, which has to be considered. But it's important that you communicate the risk to the stakeholders. A bad database table design might not sound bad and probably works fine in test, but when you throw a few million production requests at it over a few weeks - you know things will turn sour.

It's pretty simple, but if you say no and explain why - cause and effect, you should get the time to fix up. So, should you ship shit? No, never and absolutely not. Your job as a technical representative is to explain why we will not ship. To look at it cold and hard, it's your own fault if you ship rubbish.

97 Things Every Software Architect Should Know

One of the things that prompted me to start this blog was the inclusion in the book "97 Things Every Software Architect Should Know". Now, this may seem like a shameless plug, but it's not! Reason being, I'm not a "Thought Leader", "Technical Visionary", "Agile Skywalker" or whatever else, I'm pretty much just an ordinary, working software guy. This is the reason that makes this book so different.

Book for sale:

http://www.amazon.com/Things-Every-Software-Architect-Should/dp/059652269X/

Wiki with original axoims:

http://97-things.near-time.net/wiki

The book has been compiled from the open source community after a call was made to submit 97 different axioms offering general advice on real world software architecture. This is not the kind of detail you read in "Architecture For Dummies", it's actual working advice that may dig you out of a hole some day. Of course, none of the contributors get paid (it's open source) but I didn't contribute for financial gain.

For this book, O'Reilly have published it and Richard Monson-Haefel is the editor, these roles are essential to get something into print (and both have done an excellent job)! Asides from that important investment, the book is open source. I'm not sure if it's the first, but it could be the start of an important series of technical books.  I think it's great to see a publication with the kind of deep advice you get from a one on one talk with a real expert. Sometimes it's difficult to gather this information together because it covers such wide ground. I think  a book like this is excellent for those times when you are sitting back at design time/between releases thinking about potential holes in your system. 

Well done to Richard and all the other contributors!

Software factory - good or bad?

The term software factory has been around for a while now. I've heard it used both in a visionary and derogatory sense. I suppose it depends on who you talk to.


So, just to throw it out there, could a software factory actually produce high quality software to spec? Remember a lot of the Lean stuff came from the Toyota Production System, which looks at innovation, minimal waste and high quality.


What kind of comparison can we draw between a traditional software factory and a lean, agile, buzzword spouting coding shop? Both would admit targets of high quality and waste elimination. But is the atmosphere any different in a traditional software factory. A traditional software factory in my mind would be pushing teams through waterfall, have heavy process and leave little room for innovation.


Obviously the lean software shop would be doing XP/Scrum, 40 hour weeks and be a fun place to work! It sounds like both are at opposite ends of the spectrum, but could both describe themselves as software factories?


Maybe a true comparison would be between a Toyota factory and an old-style sweatshop factory. I don't think the term software factory is a derogatory term, but it's an ambiguous term.

So, that leads to the main question of the post - would you like to work in a software factory?

There are a few clarifications to consider before answering:

1. Is it a Lean factory or a harder, not smarter factory?
2. Are you the architect or the coder?
3. Who are you coding for? Yourself, your boss or the customer?

Point 1 is covered. Point 2 is interesting in the sense that it's cool to be dreaming up improvements and architectures for the team to be doing, but is it any fun being a coder in a team where you have no say in the direction? Well, that all depends on how open the architect is. If the architect is pretty open, he/she will listen to the team and involve them in such things. Share the "fun" work of design and improvements.

Point 3 is off the wall. That's personal preference, I suppose. But there are a few coders that lose sight of the fact that this is a job and sometimes you have to use an uncool technology or something that you don't personally like. That's a whole different subject...

So, software factories - good or bad? Like any company, it depends both on the goals and how they are achieved.

the quick intro

Hi there, just a quick hello.
I don't intend to be super regular on this, but I want to have a place to post the odd thought on software. I've been thinking about starting this for a while, but the 97-architects book (http://www.amazon.com/dp/059652269X) has spurred me on.

This may well be the first and last post. We'll see. I've been reading enough of this guff recently, so it'll be interesting to see what kind of garbage I come out with.

BTW, I'm gonna try and stick to software here and cool the ranting. File under boring, nerdy stuff!

G'luck,
Dave.