Techn@gerial

If you’re not willing to throw all the code away, and I mean all of it…it’s not a prototype.

I you’re not willing to press SHIFT+DEL on the entire code folder after you’ve learnt what you needed to learn… it’s not a prototype.

If you put it in Source Control… it might not be a prototype*.

If you start coding from the prototype codebase in any, way, shape or form… it’s not a prototype.

A prototype serves a specific purpose: to aid learning. Use the technique to figure out things you don’t know about your design or product idea. Use them to figure out what UX features work and don’t work. However, do not use them to form the basis of the alpha codebase or as an excuse to start coding without a design. A prototype should have a specific purpose; the object of the exercise should be to learn something, the code is simply a by-product of that learning, nothing more.

However, if your company or environment do not allow for prototyping, then don’t use them, not even a little bit. By that I mean if the purpose of a prototype is not understood or it’s considered too expensive to “throw code away”, then you’re better off not having the code available at all… you’ll only be forced to use it; the upside will be that you’ll gain the learning, the downside will be that you’ll have to fix production code as a result, which is code that you cannot simply throw away. In these situations use the Tracer Bullet technique… the subject of a future post.

O.H.

[*] Prototypes really should not have that kind of longevity, but you may benefit from branching the code to create a number of prototyped scenarios – but you’re better off avoiding source control, it simply promotes the wrong idea: that the code is important.

Product and service roadmaps are notoriously hot topics in most software or technology businesses.  They are there to represent the aspirations and communicable plans a business wants to surface and use to keep their customers and partners engaged.  There is no doubt that they are an essential aspect of demonstrating and evaluating your delivery capability but getting them right and keeping them meaningful is a challenge.

Continue reading »

There is no doubt that agile development techniques (of which there are several, Scrum, XP, Lean etc.) are an excellent way to empower a development team and enable them to really engage in the process of delivering software.  I will focus, such that I need to, on scrum; my preference.  These techniques delegate responsibility (not accountability) to the technical team, led by a scrum master.   This enables them to decide what is done when and how these decisions are made relating to any given set or state of the requirements.  The daily scrum meeting assigns priorities for work and addresses issues arising.  It is a technical forum where the team frankly raise and discuss their issues and experiences.  Scrum is usually composed of a series of sprints where requirements/features/stories (use cases) are solved in design and code.  But how do you surface this kind of project within your business and how do you report on the unknown?

Continue reading »

I have often sought the latest and sometimes the greatest of note taking tools. I despise paper for many reasons; its impermanence, “losability” and “unsearchableness”. Above all though, paper is not available, on a general basis unless you want to carry reams of it everywhere you go.  My handwriting skills are also pretty poor on account of an IT career…

Some of my favourite tools have included mindmapping tools, standalone wikis, brain replacements and most recently Microsoft OneNote. At least with these you are carrying a uniform weight around, a laptop. But still, your notes are locked away inside unless you take it everywhere too.

So, armed with my new iPhone I was happily browsing the Apple App Store and came across Evernote. Initially I thought “nice, mobile note taking” but no, it is more than that. Evernote has various versions. It has a client app to install on your computer, a “portable” app for installation on portable memory or devices, an iPhone app and full web access too. For me, this allows me to take and access my notes from anywhere and the “freeform” mode works a treat with my Tablet.

The searching and indexing also seems to use OCR and handwritting recognition for images and handwritten notes which is good for imported OneNotes as these come across as images during the special OneNote import option.

Doubtlessly I will find another fascination in due course but for now, Evenote does it all for me.

My previous post about software project entropy was slightly abstract. I thought I should therefore address this in light of more thought about the subtleties of software engineering and planning for software projects.

Previously the context of the post was the disconnect between management expectations and practicality. Software projects are very difficult to plan accurately, primarily due to the means of production; people and more importantly, their imagination. Consider this scene: an open top bus with cats in it. Abstract, because the effect I want to explain is much more pronounced when dealing with new or uncommon concepts. If you were to ask a group of people to describe this scene to you, with no additional input on the scene, you would get a series of very different descriptions. This may seem obvious but the issue here is that they will all describe the same thing.

Continue reading »

Edward Tufte is an information design specialist, his work is absolutely outstanding; he has written four wonderful books on information design and the presentation of information. Whilst browsing his site recently I stumbled upon this thread: Project Management Graphics (or Gantt Charts), which starts with a Tufte reader outlining their issues with using Gantt charts when dealing with a large project - an issue which I’m sure we’ve all encountered, printing 10’s of pages and gluing them together on an entire wall. Just to get a feel for the project’s timelines, dependencies and resource usage - Tufte offers a solution; a brilliant one at that.

  Say “no” to GanttEdward Tufte:

Most of the Gantt charts are analytically thin, too simple, and lack substantive detail. The charts should be more intense. At a minimum, the charts should be annotated–for example, with to-do lists at particular points on the grid. Costs might also be included in appropriate cells of the table….more.

For the project minded among you, I am very keen to hear your thoughts on Tufte’s design as well as what alternatives you might have to the ghastly Gantt.

OH.2008.05.15

Design patterns are - to most established and successful software developers - reusable, known good starting points for specific applications in writing software.  They are proven, best answers to some of the most basic problems encountered when writing code.  The seminal  work on this subject is the eponymous 1994 Design Patterns or “Gang of four” book, which deals with design patterns for object orientated programming.  There are several types of pattern: constructional, structural and behavioural and latterly even more.  They have names such as Singleton, Facade and Mediator.  In simple terms they provide a way to stop software engineers from assessing and reinventing common solutions time and time again; if it needs to roll, these are the plans for the wheel.

My experience in working in systems and software development has often required the same answers to the same questions.  How do requirements get written? How should the development process work?  How do we prioritise our projects?  Why can’t we deliver on time and to budget?  How do we maintain our software?  Fundamentally, the answers to these have been, in essence, the same, the foundational structure of  the answers being common, from large global businesses to small niche players.

Whilst large scale frameworks like ITIL and Prince can provide best practise in terms of execution, I am not sure they provide the actual pattern, more the instructions and rules.  They seem to err away somewhat from the foundational definition, or even assume it is already in place.  This enables generic suitability, but what role could specific patterns for these common, business challenges play.?  What would a prioritisation pattern look like?  What would an estimating pattern look like?  A peer review pattern…

Some formative work on this subject has been done, certainly in the 90’s, but there is little published specifically for these more process based patterns;  the capturing of wisdom to enable new businesses to learn from the established.  To have some of these patterns would save the effort and waste of rediscovering how to fundamentally operate as the start-up spark fades and maturity needs to prevail.  I am wondering where these patterns are, perhaps they are locked up in the “IP” of integrators and consultants, but surely there is enough experience out there to bring them into the open.

More to follow…

Having refreshed my IT and being able to use my new personal PC without ear defenders, I have been catching up on some reading.  Seth Godin has a great snippet on his blog about the relationship between The Story and The Work.

I’m not sure if it is an instinctive behaviour on account of the highly technical environments I have worked in, but this concept resonates with me strongly; I need to see The Story in most things I undertake.  Moreso, I also need to see The Story in a situation to fully engage in changing the aspects of it that may not be relevant or appropriate. 

I guess The Story is the sum of the “narrative” parts of the solution to any given problem or challenge; the root or “beginning”, the situation or the “middle” and the solution/vision or the “end”.  Any one of these elements will have domain experts that can ensure you have everything you need to understand each part.  However, to be able to rewrite things the way they should be or the way you want them, you have to be able to see them all together to begin to visualise or “write” the possibilities and variations available to you.

Seth’s Story may be slightly different to mine, given his particular focus, but the concept is portable.  If The Story is a good one, something that will sit easily with others, then this helps making The Work all the easier when coming to getting it done.

In several previous posts I have alluded to the importance of assessing the capability of your workforce.  Having worked in several software and service product companies, the emphasis is somewhat different depending on market and the need for speed, but generally, knowing as much as you can about the skills your people have is extremely important.

Consider my previous article “Mind the gap!”, where the capability is irregular.  This shape, i.e the quantities of differently skilled people you have at your disposal in different areas, may be completely intentional.  However, it is likley to bear a significant burden of constriction, in places,  due to attrition and, perhaps less so, oversupply due to failed initiatives or declining products/markets.

When it comes to getting strategic about your future direction, understanding how this shape needs to look is a key pointer to setting budgets and engaging your management teams in gearing up for the strategic plans you have. 

Continue reading »

Is it a project?  Is it a programme?  This is a topic that is occupying my mind this week, on many levels.  There is a good short paper, Managing Successful Strategic Programmes to be found at www.nixonbrooke.com it addresses the fundamental differences between a programme and a project and provides some useful help for determining the difference.  The paper, by Ian Jones (some relation) can be found here.

On a more fundamental basis, I need to make some deterministic evaluations of what makes a Strategic Programme Manager rather than a well tooled Project Manager…