Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
If I only had more time I could… With a little more investment we could…
These sounds familiar to pretty much every Software Engineer and are probably uttered on most if not all projects. Every software project has constraints. Sometimes it’s a simple as time and effort.
We could all ‘do better’ without constraints, or can we? Are there times when constraints are a good thing?
On a visit to the Science Museum in London last year I took in an exhibition – ‘The Digital Age. On display was the ARM microprocessor. This chip was built on a very low budget – there wasn’t pots of money available or a large team. It was probably because of and not in spite of these facts that the ARM chip was created. By contrast Intel had large teams and big budgets, so it’s seemed unlikely at best, that a very small team with limited funding could ever create a new processor under these circumstances.
Constraints can help provide focus on what you can do and not what you could do. With unlimited resources it’s possible for progress to be slow or stop due to the Paradox of Choice when there are too many options, not knowing which one to pick, or worse still constantly waiting for the next best option to appear.
As humans we are extremely creative and resourceful, we can overcome many obstacles with creative thinking, passion and collaboration, these are a vital set of ingredients that and available to us in abundance and cheaply.
In Simon Sinek’s book ‘Start With Why’, in the first chapter he discusses the Wright Brothers and how they beat Samuel Langley to powered flight. Samuel Langley had a better education, a huge budget and a hand-picked team of experts, along with access to a wide range of resources, but it wasn’t enough. Simon explores the underlying reasons of motivation, the ‘Why’, but it also demonstrates that constraints are not always a defining factor. The raw passion and determination of the Wright Brothers meant they simply wanted it more and weren’t going to give up because they didn’t have this or that. They did not let constraints define their limits.
Focus on what you do have and use that to your advantage, and above all give it a go, you may surprise yourself at just how far you get can.
Another reference, in The Pragmatic Programmer tells the story of Stone Soup, I won’t go into details on the story, but the upshot is once you can demonstrate something and ignite people imagination with something tangible and visual, you might find one or two constraints such as time and money are suddenly not as much of an issue as before.
Asking for the Moon is never going to happen, show them the beginnings of a rocket, a plan and with phrases like, ‘now if I just had <this> then I could get to the next stage’ and then maybe others will buy into your vision too.
I consider these types of constraints ones that are not enforced on us specifically by the project, but we kind of just implicitly add to our thinking. Maybe you have a ‘goto’ (yes, pun intended) language or framework, so next project comes along, and you impose these as implied constraint, possibly rightly so if this is yours or the team’s area of expertise, but it’s worth keeping an open mind on language and frameworks and not always choosing the default option without thinking. At design or ‘thinking’ stage effort is cheap allowing you to explore the possibilities. It’s worth at least considering other viable options that could over the course of a project bring potential savings, but making the right choices early on is key, as the opposite can also be true.
For long-lived software projects, the current Dev teams can still be living with poor or uninformed choices many years later. This is known as technical debt, easy to create, much harder to remove.
With the benefits of cloud native and the advance of many frameworks, there is an obvious advantage to be had by keeping up to date on the latest technology to see if the benefits can provide tangible long term gains. Be sure you are using technologies for the right reasons and not just because it’s new – there must be a discernible benefit and the teams ability to use and maintain them are valid considerations.
Maybe more relevant to other type of constraints – when stuck on a difficult algorithm or problem, one technique worth considering is to start by loosening or removing a few constraints, known simply as Constraint Relaxation. This can help to just to get you going and make some progress to get it working, then gradually try to add them back in afterwards.
TDD can help with this, as you can implement a test, get it passing, then forget it and move onto the next one. You have confidence that what you do next will not break that constraint without first signalling it in a failing test.
Another option is Lagrangian Relaxation – This aims to approximate a difficult problem by making it into a simpler one. When removing a rule, a cost is then added to the algorithm, so now it’s an easier problem, but more expensive to solve. By relaxing the conditions, new possibilities can present themselves and understanding can improve. There may also be times when although the solution isn’t 100% optimal, but is close enough and the added cost can be accepted.
Three great books, all worth reading in my view…