Guidelines for Meetings – don’t do in the meeting what should be done before or after
Quakers in Business, Science and Engineering – not ‘just’ in social enterprise, NGO’s, etc.
Managing Trust (specifically in software development) – do you measure estimates, outputs or outcomes?
Love Notes – we leave these in my house too 😉
Virtual Teams – Akari Software is increasingly like this
The best Super Bowl ad evvvver
How to refocus when you hit a snag
Make sure your work/life balance doesn’t disturb that of others
The danger of atrophy in agile teams
All green at Zemanta has me green with envy
Brad Feld used to be the human equivalent of the last page in the book
LiceCAP – an awful name for a great tool for capturing on-screen activity
Steve Blank thinks he was a jerk but he saved lots of people from wasting their time
Yes – a short story worth reading
Product Managers stay until the end – fits with my philosophy
Dark nights – we all have them so let’s be kind to each other
Personal Kanban – must improve my own system
Parents and Patience – more on kindness, I’m afraid
Rape culture – more about boys, men and what constitutes acceptable behaviour
LARGE x RARE == DIFFERENT – big companies don’t just have more of the problems of small companies
Alex Prager at Lehmann Maupin – some art for your soul
The Amazon Whisperer – quietly minting it
Three love poems – the last is my favourite
Soft Tissue – has its uses but beware
Iron Maiden as exemplars of data analytics
Privilege poisons all our thinking
Embrace Chaos – but I would say that, wouldn’t I?
What got you here – might trap you here
Decisive – a review of the new book by the Heath Brothers
I am still struggling with the Quaker Peace Testimony, so in the meantime Burn the Fucking System to the Ground
I don’t own a dog but I do love them and their antics
Node.js is big and getting bigger
Brian Eno’s Windows95 startup sound slowed down 23x
A good use of an API to provide a much-needed service
Usetrace.com – a Test Automation Tool For Web Apps
Finding Time – the wisdom of Grannies and Supreme Court Justices
David Heinemeier Hansson on not allowing others to define what success means to you.
I hope McKinsey research in other areas is better than this piece on software metrics – I may have to lump them into the same bucket as journalists 😉
Learn node.js via nodeschool.io – and why you should bother
A new way to look at your competitors
API’s are the future of good web software architecture – get good at API design
Applying data analytics to education – looks like Design Focused Evaluation on steroids
Kevin Mullins documentary photographer
What can next-generation database technologies do for you? – perhaps they can make you more agile. If you’d like to be more agile, you could get started with MongoDB.
Can you have too much information about your genetic makeup?
Break gender stereotypes – GoldieBlox Engineering Toys for girls
“You must kill your darlings” – Behind the scenes at TEDxDublin
Is it a CMS? Is it a database? No – it’s Silk
“some of us give so much there is nothing of us left” – we should pursue meaning, not happiness
“relational databases are best avoided if you want to do things iteratively” – fixed structure and dynamic requirements don’t mix
How complex systems fail – failure is ‘normal’
I spoke at the Dublin Agile Tour 2013 event yesterday on our experience trying to migrate to a product line infrastructure while implementing Agile in Akari Software.
My presentation was based, in part, on a joint experience paper with the University of Ulster submitted to the 2013 EuroSPI2 conference in Dundalk earlier this year.
A software product line infrastructure is one where a set of common software components is enhanced with a set of case-specific ones to build product variants based on technical, industry or user requirements. Implementing such an infrastructure is more expensive in the short run but gives a better return on investment in the long run – especially as your product portfolio increases.
One of the Principles of the Agile Manifesto states that ‘Simplicity – maximising the amount of work not done – is essential’. This principle has effectively been simplified as ‘Over-engineering is wrong’.
While trying to explain the tension created by trying to do Product Lines and Agile at the same time, I had a personal epiphany. I’m sure other have had the same thought but it seemed new to me – it’s impossible to do just the right amount of work in Agile. We either do too little, and accumulate debt in the process – or too much work, leading to over-engineering. I think this must be because we don’t have the information to let us know which we are doing, i.e. the only way of avoiding either mistake is to have knowledge of future events.
How I feel about it now is that over-engineering is the price we pay to avoid accumulating debt and vice versa. We shouldn’t feel too badly about either because we must be doing one or the other in any given case.
What do you think? Can you ever do ‘just the right amount of work’ in Agile?
In addition to everything else on my plate, I’ve been in stealth mode for the past few months with a concept called Innovation Island.
Universities patent technologies all the time arising from their research activities. Technology Transfer Offices help to spin out campus companies based on these technologies and/or license the technology out to third parties.
Inevitably, more patents come in to the system than can be spun or licensed out the other end. Many of the patents that miss the cut in their first year never make it at all because newer patents come along and continue to displace them. There’s nothing ‘wrong’ with the patents that don’t make it but there could be factors that make them more difficult to commercialise such as: an unwillingness of the inventor to become an entrepreneur in a campus company; or a lack of understanding of the applicable markets on behalf of the University. So these patents moulder in drawers until they expire and all the public money used to carry out the research and register the patent goes to waste (I’m simplifying here).
Innovation Island aims to stop this waste of public funds and to create jobs and generate economic activity by getting these technologies licensed out.
We are currently in private alpha but intend shortly to announce our first wave of patents available to license from an Irish University and hope to sign up others shortly.
We will have assessed the Commercialisation potential of the patented technologies on offer and ensured that they are ready to be licenced out.
We will then match the technologies to suitably qualified individuals or companies and will give them an exclusive, non-commercial Exploratory licence for a nominal sum so that they can determine how best to commercialise the patented technology.
The patent owner will provide information and support during the Exploratory licence and Innovation Island will provide access to other services and service providers including funding, mentoring, non-executives, consultants, lawyers and accountants.
At the end of the Exploratory licence period, a Commercial Licence can be negotiated with the patent owner.
