So we have come nearly full circle here. Our focus is going back to where we started, the customer. We have learned most of what is needed for good software development, what now?

We need to show the customer we are good for them. That we understand their needs and most importantly, we will deliver.

To deliver, there are several ways to achieve that. We can use two main development methodologies. Each has its pros and cons.

The first one is feature driven developments.

It’s not a bug, it’s a feature!

via GIPHY

So, while we are not going to build a bee hive, it’s important to have defined what will be built and in which priority. This goes back again to reducing risk, which we talked about earlier.

We iterate over the list of features, one at the time, until the system is complete. Here the functionality of the system is defined on its intended objective.

The second one is use case driven development.

Here the functionality is defined from a user’s perspective and how are they going to use the system for their work or objectives.

Neither has technical details.

The use of each one depends on the customer context and the specific needs of them. This also involves the correct planning to determine which one is the best one for any given project.

An excellent practice is to have unit tests. Which are small tests, although several, that verify the correct functionality of every part of the system that we are making. To ensure that any new code change doesn’t break it or that it delivers the expected output. They are a central part of Test Driven Development where testing is included at every step instead of at the end as part of the QA process. This ensures a superior quality and lower bug fixing costs.

Again, you can find my alternate post on this here:
https://davidtc2004.wordpress.com/2018/11/22/if-it-works-break-it/

Smash yo code kids