Monday, 24 September 2012

On quality and constraints

Woah, the past six or so months since I last posted to this blog have been a bit hectic in my personal and professional life! I still have about seven draft posts to write up. So hopefully I'm back on track for about one every week or two :-)

mild warning for tenuous link and conclusions jumped to ;)

Last week I had two conversations on very different subjects that boiled down to the same thing - constraining options (or ways of working) to ensure quality without change the quality of any other part of the system.

The first one was entirely work related. One of our project teams is extending a feature that had been sent for design review for input, in my role as an internal technical consultant and as probably the last person to do extensive work in this area (about six years ago!) I followed up and had a chat with the team's senior dev and his team mate. We talked through the possible options and the technical debt that could be repaid. The option with greater opportunity also had the downside of greater risk in time taken. Limiting the technical debt to just one half of the library, directly involved in the feature, massively reduced the risk and allowed a fairly accurate estimate to be produced - with the added bonus of taking an entire legacy class out of technical debt!

The second conversation was about a subject close to my heart ... food! and more specifically ready meals. I was discussing with our office manager that the finest ranges are usually limited to being oven cooked and not microwavable, this constraint ensures a level of quality without any change in ingredients. They often "force" you not to microwave the meal by packing it in a foil rather than plastic tray. A clever way of constraining and limiting the options within the system. The same is true of jacket potatoes - you can microwave them, but it won't be as good as an oven baked spud

I think that's one thing that experience teaches you and is expressed through expertise - knowing when to put your ready meal in a foil tray and when plastic is OK. Or to put it another way when the solution has to be framed in a way that repaying the technical debt is a natural consequence of the option.

Further Reading

A vaguely related link on the overpowering nature of choice in the modern world
The tyranny of choice: You choose | The Economist

Sunday, 19 February 2012

On motivation and management

Well, it's been a while since starting this blog and drafting 5 posts that I've never finished! This is the first proper post and I expect it to be a bit rough and ready as I get used to writing again. 

Recently I've been thinking about motivation, more specifically in keeping morale up and motivating a small but busy support team, staffed by junior graduate and student devs. These are talented people with degrees related to their field of work. I'm mindful however that the environment can be high pressure and the learning curve of joining the team steep. I think that true motivation comes from within, but how to unlock it?

Reading Simon Baker's blog on having a goal today sparked something in my brain, a memory lodged there from one of my Master's courses on managing software development. So looking over my notes I find that Humphrey (1997, p. vii) lists the following elements for successful management of technical staff:

1.                   a challenging and worthy goal
2.                   talented, motivated, and capable people
3.                   the training and support to enable the work to be properly done
4.                   a manager with the drive and vision to make it happen
5.                   a leader who understands and cares about his or her followers.

Bingo, number 1 is having a goal! The others are mostly already in place or being worked on, for example I have identified some process improvements for point 3 that I hope to get in place soon (and will provide a blog post once presented internally)

One thing that is biased in that list is the reliance on the manager/leader, perhaps due to the age of the research. I think that this Inc blog post by Ilya Pozin Founder, Ciplex sums up how I feel about the positive impact from effective team work:
empowering your staff to work together as a team rather then everyone reporting to one individual can do wonders. Think about it. What’s worse than letting your supervisor down? Letting your team down! 
perhaps the manager and leader from the last two points would create that environment?

The challenge now is how to provide meaningful goals in a support environment where a spanner can (and is!) frequently thrown in the works by an unexpected production issue.


Humphrey, W.S. (1997) Managing Technical People: Innovation, Teamwork and the Software Process, Reading, MA, Addison-Wesley.

Saturday, 14 January 2012

Welcome, an introduction to my blog

Why hello! thanks for stopping by on my blog. I'm not sure I have much to say or that I'll get around to actually writing it with all the avenues for creating on the web these days :-) The thing is that all these different channels on the internet tend to express an aspect of who we are - say the professional, hobbies and interests. I have:
  • Facebook for posting notes to my friends,
  • LinkedIn for shorter posts on matters related to my professional life
  • Google+, flickr and 500px for photography related matters
  • Twitter for short links on all of the above
So why have I started a blog? Well, I'm lucky to work in a field in which I have a strong intellectual interest. I read a lot of blogs, papers and reports on the area I work in. I also have a lot of discussions with my colleagues and observe how the teams I interact with work. Previously I have done a few academic courses to keep my mind ticking over, organise my thoughts and provide a space for writing this down. It's been a while since I've done this, so I'm feeling a bit mentally "flabby" in the same way that I don't run, or exercise as often as I used to, and I feel a bit physically unfit :-)

However, with all the social media I currently use I don't have anywhere to write longer posts on any of this. I could use LinkedIn, but I want somewhere with a nicer blogging experience that I can link to from LinkedIn or Twitter. I'll probably be writing on topics like ... the software development lifecycle, risk, projects, knowledge management. I won't be writing about my cool new algorithm in C++ or interesting new ways of using for loops.

I've been mulling over some ideas for the past week about company hierarchy, responsibility and the business/technical divide.

Further developing an onboarding process for a green field product

This is  part of a series  about my side project  Bashfully , which aims to give graduates and other new entrants to careers a seasoned prof...