Software Development is complex. The problems it solves will always have a level of complexity. In this podcast I talk about why.
Or listen at:
Published: Wed, 24 Jul 2019 15:33:24 GMT
Transcript
Software Development is part science, part art ... it is the act of turning ideas into reality.
It is, at its heart, problem solving.
A Software Developer will need to take a request presented to them, evaluate that request against their knowledge of any existing system, evaluate that request against their own technical capabilities and knowledge, then formulate a potential solution to that request.
Problem solving.
And once they have their potential solution they then need to implement it – which in itself will generally lead to a whole series of further challenges to solve.
Problem solving.
And the whole time that the software developer is working on that, there will be part of them asking “is this the best way to solve the problem?”.
And this is where software development really gets complex – there is rarely a single correct answer to a software development problem. Rather there will be a number of potential solutions that can each have a variety of pros and cons.
This should be a familiar state for most business managers.
The higher you rise within an organisation, the more you are having to make decisions on incomplete information – if everything was known prior to making the decision – then to be honest you wouldn’t be needed – people would just follow a defined procedure – if this, then that.
Much of management is about making a decision when the way is not clear. You will evaluate the incomplete data you have available to you, you will assess and evaluate potential answers, you will weigh the pros and cons and arrive at a decision which is often the best available rather than some perfect answer.
And only later you may find something that affects your decision. Maybe some assumption you made or some piece of the original puzzle wasn’t correct. From this you may choose to make a course correction. Maybe that correction is a trivial thing. Maybe that correction amounts to a complete do-over. Again you will be assessing the pros and cons of various solutions.
Largely it comes down to your judgement as a management. And then only time will tell if you have acted wisely.
And that is what is happening with software developers.
They are constantly having to make judgements and choices over the best approach to solving a particular problem.
And they have to do that at the same time as not being held back by analysis paralysis – being too conflicted with completing solutions that they simply do not progress.
I’ll talk more about that particular problem in a future episode.
Rather, for the rest of this episode I would like to look at the comparison of software development to building a house.
This comparison has been voiced to me by various executives.
There is an expectation that house building is known, understandable process - and that surely software development is equivalent.
And with it having been raised to me so many times, I’d like to use that analogy to explore the complexity of software development.
Now I love to use analogies.
Analogies can be a wonderful tool in bridging the technical divide – but can also lead to loss of meaning if over relied on.
Sometimes one party can buy into the analogy too far – making assumptions based on that analogy, to which there is no correlation.
No analogy will be 100% correct.
So back to building a house;
This analogy is deep with potential benefits. Barring significant cultural differences, you can assume a good amount of shared understanding when it comes to house building.
There are some great parallels that can be drawn from building a house.
We can have comparable roles for example.
In Software Development, we can have a variety of “trades” similar to construction – all of which work together to produce the finished article. We even borrow some of the names and terms such as Architecture. In Software Development it describes how a solution will be built out and interact with its surrounding environment – very much akin to a building Architecture.
We can also understand the value of good solid foundations.
We know that if we want our house to last the test of time, that we will need solid reliable foundations. We then need all the good things that we expect from modern house building – security, protection from the elements, utilities such as water and electric, etc. We also expect that we will need to carry out maintenance during the life of the property – the costs do not end with the build.
And this is true also of Software Development – our cost is much more than the initial build. We also have to factor in the maintenance and upkeep of it over its lifetime. And in keeping with the house building analogy, the better the job we do in the initial build, the cheaper it will be to maintain during that lifetime.
If we use cheap products and poor construction techniques in our building, then we will have a very expensive ongoing maintenance cost. Potentially, if we’ve done a really poor job, we may need to pull it down and start again. Luckily, in construction, we have evaluators (Building Regulations in the UK) to ensure that reasonable standards are adhered to.
There is no such evaluation in Software Development. It’s is more than possible to build something that looks externally correct, but is built on quicksand or built in such a way that it will not stand up to operational use. It is often time that will tell us if we were correct.
Another great use of the House Building analogy is when considering change after the initial build.
If you want to add an extra room to your house, you would expect to go through the appropriate steps to ensure that it is integrated into the original house correctly. That may require changes to the original foundations or architecture so that the addition is in sympathy with the rest of the property.
Otherwise you run the risk of making your entire house unsafe and unsustainable.
Again the same is true in Software Development. But it isn’t visible, thus will not be as instantly recognisable. Sometime we may want to add what seems to be the most innocuous thing – but requires significant change to ensure that the integrity of the overall solution is not compromised.
Ok, so onto where the building a house analogy falls down.
One of the biggest gripes I have is the expectation that any Software Development project should be able to provide 100% correct cost & time estimates up front – just like “building a house”.
In response to his, I’d ask is if the requester has ever commissioned building work. Certainly my personal experience is that construction is not a yard stick by which to measure the infallibility of predictive estimation. It’s common for delays to occur due to weather, suppliers or a host of other factors – and (depending on how the work is finances) increased costs as well.
The more bespoke a house is, the higher the risk of an upfront estimates being wildly out. Anyone that has ever watched the UK Grand Designs program will be well aware that a custom build is far from a clear cut thing.
But putting that aside;
The construction trade has been around for thousands and thousands of year. There is an immense collection of tried and tested practices for both the estimation and execution on which to rely on.
Take for example the role of quantity surveyor; who’s role is to calculate the amount of materials needed for building work and how much they will cost. Given precise architectural design they can calculate how many bricks would be needed for a wall, how much cement would be needed and the labour time to erect it.
They work from a body of known knowledge. If a wall is built using this type of brick, using this type of building process – then they largely have a formula to work from.
If the building process or material or architecture is foreign to them, then it can only be expected that any estimates is an educated guess at best … a stab in the dark at worst.
Now if software development, yes we will have known development process, tools and architectures – but they are constantly evolving. Software Development is still a very immature disciple – especially when compared to building.
You’re comparing an industry which goes back thousands of years – to something that has only really been around for 60-70 years.
And with its youth comes a constant stream of changes, improvements, evolutions.
I’ve been working professionally in Software Development for over 25 years and I can tell you that the changes during that time have been staggering.
Even year to year you can see substantial change to what has come before.
As an illustration, if you are at your computer do a quick experiment;
Go to Amazon and do a search for "Programming" ... then down the left hand side select Computer Programming under department.
Results will vary, but I'm getting over 22 thousand results.
Now select those released in the last 30 days on the left hand side; I'm getting 360 books.
360 new books on Computer Programming in the last 30 days.
Hopefully that gives you some idea how much the industry is in flux.
And all of that flux adds to the complexity of the problem solving for the software developer.
As the industry matures, so previously valid approaches fall out of favour, while new approaches are promoted.
A constant challenge to finding the best answer to our problem.