Techn@gerial

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…

Continue reading »

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 

An estimate is the cornerstone of your ability to deliver a project on time. Without a decent estimate you’re just making it all up as you go along. You would not build a house on sand or without a solid foundation; you would not pour your own money into a new development (be it software or a new house) if you did not think that developers had used the most modern techniques and practices to lay the foundation on which all things will be built. However, people (I use the term “people” as opposed to naming the obvious job titles like Project Manager or The Business as there are many culprits in the whole cycle or process that allow this kind of activity to go unhindered, including the developers themselves) are more than happy to go to work on a baseless, unfounded, unjustified, unsubstantiated, groundless estimate!

But this point you must be asking yourself why is this? The answer is simple: it’s hard to do it properly. Mr Steve McConnell has produced an excellent work on estimation called “Software Estimation: Demystifying the Black Art” and here he deliberately says this book is not about the science of software estimation but on the art of software estimation. Even if you never read this book there are two things (only two things, come on you can do it) you should take away and apply today to start moving out of the sand:

1. Don’t Guess, Count
2. Use Previous Data, Your Data

Don’t Guess, Count

Your gut will be wrong, it might be close some of the time, but ultimately it will be wrong. Experience is a very valuable tool and thing to leverage, but not with an estimate. You can get tee-shirt size estimates for projects (small, medium, large etc) from your gut, but to take that any further is putting you back in the sand. Don’t be fooled by the pseudo accurate numbers like 3.2 weeks or 45.37 man days, it’s still a guess.  Find something to count, estimate one and then apply it to the others - this is surprising accurate over time (this is where you can leverage your experience) and is better than just a gut feel; but nothing replaces real data, previous data, your data - something nobody else has.

Use Previous Data, Your Data

People keep throwing away their valuable previous history - refusing to learn from their own hard work, information that they have already paid for. They keep paying the “learning” cost, the “setup” cost over and over, keeping the whole process of software estimation a mystery from themselves. It’s like they’re deliberately making it hard to know the answer to the estimation question, like there is some perverse pleasure in not knowing the answer. But the truth of the matter is that it’s easier to say you don’t know, it’s too hard, just make it up or use your gut instinct (“I’ve been doing this [enter you number here] years, I know what I’m doing - a 20% variance in either direction is a good result”. So you’d be happy with only an 80% chance of your house staying up would you?)

There are industry level datasets that you could employ if you have no previous data available, but there is no software on the planet that already knows how your team/company will behave during a development or project; but you do - you’ve done it before, but where’s the data? Why can’t you leverage it? Simple: you don’t track it and you must. Write down all your starting estimates and adjustments along the way; then the actual figures once the project completes, even if the project ends with non completion of the original goal, that in most cases would be considered a success too (maybe another post another day as to why failure to complete a project is a success) then analyze it and use it for the next project and the next and the next and so on.

Start laying the foundations today; mix some concrete into that sand to make a decent foundation.

Tweet This Post 

Ryan Norris has posted an interesting article about estimating software development projects, including a nice analogy to meteorology. We all know and love Michael Fish in this country; but he was lambasted for completely missing the devastating hurricane that swept the UK in 1987. It would seem that weather commentators and project managers alike suffer the indignity of persistent recollections of their inability to bring certainty from what is often chaos.

Ryan’s main point though, is that “The process of estimation is what is important.” This is an opinion close to my own which asserts the need to decide to positively estimate to get good at it, rather than constantly guess and ultimately be constantly wrong.

Tweet This Post 

Scott Hansleman recently wrote an article: Remember that Targets are not Estimates.   It lays out some good thinking about estimation and the problems with estimating software projects.  He also references the “emerging oracle”, Steve McConnell and his book on demystifying the black art, and so he should.  More interesting though, are the comments; the variety and level of confidence in such a wide range of estimating techniques.  I think this underlines the fact that no single approach will suit all situations.  Although that could be a trite statement, in this context it isn’t.  There is no “silver bullet” for estimating accurately, the myriad of techniques and sciences are all good in their own ways but they will not suit all businesses or situaitons.  Learning how to estimate as a business is a gradual process and whilst tools and books can help get you there faster, what you end up with will be a derivative of one or many of the techniques available.  The “bingo” aspect of Scott’s post is the historical view, this is where the learning comes from; then processes, polices and tools to capture the actuals are  needed before any business can start learning how they can estimate more accruately.

Tweet This Post 

It’s always the way, despite your better instincts and your years of experience, there is inevitably a point when you are asked for estimates and dates on the spot or at unreasonably short notice. Thomsett International in Australia have a great article that explains all the methods, ploys and games people will try to use to force the issue. I have come across most of these over the years but the relief and humour for me comes from the Timeout section of the article which gives some tips on how to assault the madness. I especially liked the “Let’s play” and “Blame your brain” approaches.

If you are in the position of being squeezed for estimates on the basis of guesswork, predefined dates or bullshit, this article will at least make you feel you’re not alone.

Estimation Games – Thomsett International

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 

Estimation is an essential part of any project, but software development projects are notoriously difficult to estimate accurately, especially if you’re not experienced in understanding what is required to deliver the end product. Often a project manager, resource manager or executive will go to the “horse’s mouth” (lead developer, pronounced expert or architect) to get numbers to help build a plan. It’s not difficult to understand why, developers are experts in software development and the intrinsic technical details of what’s needed to develop software. They are also often domain experts in the field they work in. But, they are usually not naturally good estimators and they only hold some of the knowledge you will need. In my experience, using only the “horse’s mouth” approach is as useful as going to the other end of the horse, you’re going to end up with a similar output!

I am not saying that software developers and architects are not capable of estimating, certainly they will be, but it is “what” they are estimating that is easy to misunderstand. To ensure clarity and adequate coverage of a particular development project, it is imperative that a structured approach is taken when soliciting for estimates. The following article will describe a simple methodology and point to simple tools to assist in devising a reasonable estimate that should be suitable to cover any software development project.

Continue Reading » Estimating software development projects.

Tweet This Post