Recently I tweeted the sentence “In Software Engineering there are no problems, only opportunities, opportunities to learn” over on my twitter account. Of course this may have already been said by numerous people in the past, but perhaps not in the context of software engineering, not to my knowledge anyway, so for now I will lay claim to it, whether that is a good thing or a bad thing, we’ll see.
The reason I decided to tweet this, was simple; so much pain, means so much gain (in knowledge and experience) in software engineering. From the beginning of my professional career there have been many a learning curve and stumbling blocks, whether it was a new technology adaptation, development/process framework, culture etc., I could go on. The point I’m trying to make is that, it will take some time before we as developers, designers, engineers or however you title yourself begin to realise that there are no real problems in or around software engineering, only to take a step back and realise that, the problem, is actually an opportunity to make things better. This is the real truth, when we experience a problem in our working lives, there is nothing more satisfying than figuring out the problem, discovering the root cause and solving it.
Now I’m not simply applying this to writing software, where we may be inefficiently using threads for example, with maxing out memory consumption and thinking, oh let’s just throw hardware at the problem (obviously that can be a fix for such a problem, but yet a temporary one at that, as it doesn’t solve the root cause). This is applied to everyone in or around software engineering. Let’s say a developer realises that test coverage needs to be improved and using something like NCrunch to analyse the test coverage in the applications solution will aid this. But the problem with acquiring the license for NCrunch may be that, it costs money. But, the business may only want new features that add value to the product, what’s test coverage going to do to add value? This then turns into an opportunity to improve your skills at communicating the benefits of increasing test coverage to the wider business through decreased support costs when the application is released and greater confidence in the functionality of the new features prior to each release. As a result, the decision to give the developer the licenses required to get NCrunch onto their application and see the lowering of support costs and overall functionality release confidence will help establish a greater trust relationship between the business and the development team. This means that the next time there may be a request for the addition of a product to improve development efficiency, then the business may be very welcoming to the idea. This is just one example, normally when money is put as a stumbling block to acquiring something that may improve product confidence and costs; we hide away in a corner and get on with our duties.
Another obvious example is the development of features by someone in the team who goes away on holiday after a sprint, meaning if there are any questions about the feature after a release, or a hotfix needs to be scheduled, then what can you do? Well, this is when paired or mob programming comes into play, sharing that knowledge amongst your fellow peers in your team during the development of the feature will aid this and someone else can pick up the questions or work on the hot-fix.
I could go on with the list of examples; however I will leave that up to the reader to take a step back and look at the so called “problems” in their working environment and think, how can I make it better or make a difference and learn from it as a result.
Thanks for reading and keep building awesome.
Until next time!
Ian B
P.S. You can also find me on Twitter: @ianaldo21
Ian Barry 