On occasion, usually during times of corporate stress or when high levels of change are occurring, the “calibre” of people can be drawn into question. “Calibre” is one of those deeply meaningful management metaphors that hides its completely subjective nature and is often regarded as a binary switch or a gauge. In the long run; someone either has the calibre or they don’t.
Morale is the de facto measure of corporate contentment it would seem, often featuring in weekly meetings as an agenda item and cited in “Company of The Year” awards as a key indicator. But what is morale and is there anything you can do to keep it high and buoyant?
I have an unusually “glass half empty” theory about morale and that is that it is an indicator in a process which is actually pretty much the same for all people. That is a gradual decline from the heady first few days in a new job to the gut wrenching day someone decides to move on to a new role.
Various posts on this blog have discussed the vagaries of planning for software development projects. This post goes a little further than that and will explain what can happen when you get good at delivery and confidence grows in your ability to deliver. This may not be easy to read if you are currently delivering successfully.
There are many things in life, day to day, that we take for granted; especially in the developed world. Clean water, available energy, medicine, longevity, the list is enormous. However, when one of these "certainties" is disrupted, for whatever reason, the impact can be quite disastrous. On the whole, disruption to these mostly (seemingly)mundane amenities is quite rare, but to those that are impacted, see New Orleans storm refugees, Gloucestershire flood victims and New Yorkers during their prolonged power outage, these outages of normal function are extraordinarily disabling.
On a more personal level, the day to day can be thrown into disarray by a mere or inch of snow or a flat car battery. Depending on your personal circumstances, the things you take for granted are only really evident when they are momentarily, or sometimes permanently lost. Clearly a software project lesson is upon us…
Finally upgraded the site software and all plugins. Twittered it all up too! Loving the new UI and looking forward to blogging the various topics I have had listed for months now. Shame IE8 doesn’t wordwrap proprerly in textarea type interfaces though… 
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.
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?
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.
Tweet This Post links powered by Tweet This v1.3.2, a WordPress plugin for Twitter.
![[Post to Twitter]](http://www.matanza.net/wp-content/plugins/tweet-this/icons/tt-twitter.png){kind=icon}