Software development simplified– a series

In a previous article “Software Development & the art of making it look easy”, I touched on the importance of simplifying the development process for stakeholders.

In the next series of articles I will be focusing on visualization of the software development processes:

• Differences between Agile and Waterfall – what does it mean
• Requirements, the different types and why are they important
• Database - simply explained
• Testing – what is the value
• Versioning and making changes

Let’s begin with “What is software development?”

As found on Wikipedia:

“Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software components.”

Doing further searches on Google, you get results on agile-waterfall-rapid development, requirements gathering, wireframes, low fidelity design, high fidelity design, programming languages – which ones are best, framework, database structure, user experience, testing, defects, deployment etc.

All this make it sound complex, and in reality it is. 

However, as a client all you want is a functional application that meets your needs, this is why you hired a team of expert. 

You don’t fully understand the importance of these conversations and maybe you don’t see the point for you to immerse yourself.

Then there are changes to be made, and you it is communicated that it will take a bit of time to implement and again you question the process…it’s just a small change after all…OK WAIT!!

Forget the technical mumbo jumbo and take another approach. Because at its core, software development is nothing more than tool sets pulled together to create something new with specific functions.

Simplify, simplify, simplify!

Albert Einstein said:

“If you can’t explain it simply, you don’t understand it well enough.”

I find the best way to explain any complex process is to develop flow charts, or images, or info graphics. This helps our mind grasping onto something more tangible.

My goal is that by creating a visual set of articles, simplifying the terms and methodologies, that all will benefit, from the developers to the stakeholders. We can all relate and have meaningful exchanges. This way we can put focus on the value produced and not debate which methodology is better.

Next I will cover Agile vs Waterfall – what does it mean.