How much good a Software Development Process must be to not impacts on your future maintenance costs and budget?

Yeah it is really true when you think "why didn't I test it with huge functional automated test suites" or "why I didn't pushed my engineering team to implement good unit coverage test rate" or even "what a hell is software testing". 

These questions are pushed when your software is making you loose money because it is being unavailable for your customers, sales team or simply making mistakes that makes you loose time and makes you loose money (again!).

Start wide and later get minor details

Those questions cited above are usually common asked by IT Manager in 99.9% of situations probably because they forgot to define a good Software Development Process.

Make stuffs more easy to understand, communicate and propagate on your team will make your performance growth and the value delivered for your customer bigger and valuable. 

Let's split it in 3 wide sub-processess: Requirements Definition Process, Software Engineering Process and Requirements Acceptance Process.

Don't ask me how organize Users to request and prioritize your demands, because it, in fact, must be done by Business Area or Product Management but we can help you in future articles (I like it too ;-) ).

Requirements Definition Process

It means you do not simply ask features and wait seated for them, you must work hard to define it well in a good Backlog Definition, with a good stake holders and product owners prioritization and the most important thing if define a good and well defined Definition of Done (DoD).

Software Engineering Process 

With all these stuffs alined between Engineering and Product/Marketing you must think in how your Engineering team will build, test and validate your deliverables to match and satisfy all Requirements and defined DoD.

Requirements Acceptance Process

Here is the most important part that will avoid you to deploy a defect software in production and make you start loose money immediately because you pay for bugs that was not defined on requirements or not predicted in DoDs AND you pay for detected bugs after your contractual time of free support and production monitoring.

Why get it working is important?

Make things more clear, how each Feature/Requirement must be defined, how each one must be implemented, tested, validated and deployed force your company to not loose time and money BUT pay attention to this key competitive advantages:

Flexibility to Build

You can develop features and new releases separately, merging and testing all together, keeping testing working between all integrations and rollouts. This miracle is feasible just if we have to talk more about Unit Test, Functional Test, Continuous Integration and Continuous Delivery.

Hight Maintainability

Hight Maintainability IS NOT High Maintenance - Master Yoda \o/

Well defined processes can guarantee good requirements, documentation, code, tests and good checklists/playbooks could get you reliable resources to keep your software evolving and growing safe.

It means huge refactoring sessions could be avoided and you will save time and money to get your software nice and not impacting on your company results.

Small deployments to growth faster

Releases with small set of features get your testing process more easy and simple and will make you not break a lot of tests. Here we must talk about Continuous Integration and Continuous Delivery.

What's next?

I am imagining if you are still here reading my article, but trust me: it is feasible and can be done with a hight automation rate. To continue we need talk about each area suggesting some tools and a simply process to follow giving some special attention to deliverables and checklists between each area and/or process.

I hope you liked my first Pulse article and you can check more about Software Engineering in my personal blog here.