Quick and Dirty Teamwork

There has been a dearth of posts to this site. Part of the reason for this is that I got busy playing Overwatch by Blizzard. The underlying mechanics of the game are team based and players must work together to achieve success. Failures in the game are often due to players not working together effectively. These sorts of failures can have lessons for teams working on projects in a professional capacity; today we’ll look at a couple of team failure modes and consider ways they can be rectified. ...

September 19, 2017 · Michael Hughes

On Quality

Today’s post is short essay concerning the value of development led quality. There are no code examples or short tips for things in this post. I hope you enjoy. ...

February 18, 2017 · Michael Hughes

Software Development Knowledge Handoff

Today’s post will cover a couple different approaches to transfering techinical knowledge of a software system between individuals or teams. There are often transfers of ownership as a software product progresses from conception to feature development to ongoing maintainence. Effective knowledge transfers between owning individuals or teams help to ensure that ongoing development of a product is not totally stalled whenever ownership chagnes ...

January 16, 2017 · Michael Hughes

Unknown complexity and estimation

Developing new software involves resolving a frequently unknown quantity of problems of unknown complexity. Even when working on existing projects, new initiatives and features can contain a unknown total amount of complexity. While being appealing modern product management methods, scrum and other related methodologies focus on relative estimation which has limitations when starting brand new work. Today’s post looks at some of our limitations when it comes to estimation and what is implied by those limits. ...

August 22, 2016 · Michael Hughes

Building it wrong and wronger

A 1stgeneration software product will likely miss the mark. It might have missed being that best that it could be by costing too much, being too complex, or just not targeting the right market. In any case, a 1stproduct may lead to another, 2nd, product that is cheaper, simpler, or just hits the right notes with the intended customer. Today’s post is about building the wrong product (the 1stone) in the right way so that the 2ndproduct can be built better, faster. ...

October 25, 2015 · MichaelHughes