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 

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 »

Tweet This Post 

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 »

Tweet This Post