The Software Development Dilemma
17th March 2020
Having been in the software development industry for over 35 years. I’ve observed plenty of change, but still, the main challenges remain. Ultimately, to write software, you must know what you’re trying to achieve – and there lies the dilemma… Most people can’t express what they want or need!
The average analysts can’t accurately recap what they’ve understood, and without reverting to pages of diagrams, half-defined code, or technical narrative. Designers can’t properly articulate how they’re going to implement the solution.
From Flowcharts to Agile… What’s next in the evolution journey?
Software development methodologies have evolved from pages of flowcharts, to pseudo-code, to bloated design documents, to mark-up languages and ever-increasing pressure on the paper industry. So, although not new, we have now arrived at Agile.
Agile is the antidote to all of this; it’s the panacea. Documentation light, no certain outcome, disposable code, and an emphasis on mock-ups over diagrams. Frighteningly, this seems to be an approach that suits the development community. A community that don’t like committing anything to paper and who love terms like “technical debt”, (what they didn’t manage to complete) and “refactoring” (because they did it wrong).
So, for all this cynicism. Agile has made a seismic difference. It has to be better to discover as you progress, but at the same time, keeping everyone under control to meet the overall goal as closely as feasible. Test-Driven Development is nothing new. In fact, my first software development job back in the early 80’s was all ‘TDD’ driven. By focusing on visuals first, hopefully, the intent is better understood. Allowing the customer, analyst and designer to all get their points across clearly.
So, I believe Agile development methodologies are here to stay, but probably need to evolve further because customers are still concerned about defining budgets to deliver known goals and development communities are probably over-empowered.
It’s not the language that matters, it’s the application.
As a final comment, it annoys me to hear the term “legacy” used to refer to every line of code written before 2016! It was hard to deliver software systems whether they were written in Cobol, RPG, Java or C# using whatever database, framework or software technology. It’s not the language, technology or approach that matters, it’s the application.
Simply ask yourself, does your software meet the requirement in a way that results in the users having an improved experience and ultimately, loving the app? Does the business derive benefit, whether that’s growth, cost-saving, improved security or providing platforms that secure the future?
As providers of technology and infrastructure, it’s important that we recognise the small part we play in this game. As well as how important it is that we provide technologies that enable the software with as little fuss and complication as possible.
Blog by Geoff Skinner, Software Services Leader