Techn@gerial

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.

Continue reading »

Tweet This Post 

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.

Tweet This Post 

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.

Tweet This Post 

Why is it so difficult to accurately determine the path of any given software development project? What are the constituent aspects that create uncertainty and inject risk? Why do software development projects invariably end up exasperating senior management? Why do they slip?

Quite simply, software development projects are different to other projects. The mass of moving parts, different people, legacy support and integration and a whole range of other components and dependencies can be mind boggling.

Software is intrinsically complex. To the untrained eye, code and software architecture is quite literally like a foreign language. It can be learnt however, and some people have a natural aptitude for the work. But, as with any learnt skill, capability comes in degrees, people vary enormously and in this particular field of work, this variation makes a big difference when trying to plan for delivery. This article outlines some of these variables and how to prevent them being an issue.

Continue Reading » Software project entropy

Tweet This Post