January 11, 2017 | Colin Pear @colinpear
Throughout my software development career I have worked at startups and well established companies of various size and industry. The one thing I can say is that all of them had fundamental issues with their software development processes; ones that could be easily remedied or improved on if they would have only been willing to change the way they viewed building software.
The three biggest blockers that prevents most companies from changing their development processes are:
- A weak understanding of development processes.
- Fear of doing something different.
- Obstinate attitudes.
If you think about it these three things kind of make sense. Most dev processes are set up at the beginning of a new project. Once something (or sometimes nothing) is in place it tends to stay that way. The focus is usually getting a project/product out the door rather than setting up long term processes for building great software.
Engineering Maturity Model
Did you know there is an actual scale for measuring how good your team is at developing software? How well you are doing directly ties into your development process. Andrew Siemer has a great article on the Engineering Maturity Model. Its an easy read and will help add more clarification as to why we need to care more about delivering better software.
So what is a development process?
A development process is essentially everything involved with creating and maintaining software applications. This includes things like gathering requirements, generating tasks, writing code, testing, version control, and deployment. What’s interesting and often missed is how theses things all tie together. When properly integrated these tasks will form a smoothly operating development process. Once you have mastered your process you can begin to start expanding and thinking about things like, What can we do after the software has been deployed? Are there other types of preventative measures we can take eliminate bugs? Can we improve performance? How can we improve our process even more? Now let’s take a look at a couple of reasons that help to justify the effort for making your dev process better.
Reduction of defects
The worst thing that can happen when build software is delivering a buggy application to a client or customer. Especially when the software is mission critical. When there is very little between the act writing of code and deploying it to production the chances of bugs showing up increases dramatically. Even if “it compiles on your machine.” A good development process will go a long way to reducing and eliminating the number of bugs that make it into your code base.
Increase efficiency
Contrary to what many believe; the addition of processes and best practices when building software will actually improve overall efficiency. The biggest gripe I often hear is that by adding “X” its going to take me way more time to complete a task than if I just skipped over it. Most developers judge efficiency by how many tasks they complete. I would like to say that this view is completely asinine; but so many developers believe this to be true so to avoid offending the masses I will settle with saying that this view is very limited. A better balance needs to be struck between the speed at which we deliver tasks and spending time making sure defects are not added to the code.
While it is true that adding steps to your development process will slow things down, but they won’t slow it down that much, and the benefits are worth the cost. And if done right many of those steps can be automated so it really just becomes a no brainer.
Having a good process will make everything you do to build software better. Its makes your job better because you will have a clearer definition of what your job responsibilities are. It makes your deployments less risky. Newly written code and existing code that’s been modified are less likely to break current features. Teams become closer and build better chemistry. And all of these things amount to happier clients.
Change our focus
Its very common for most software teams to have some kind of process where coding tasks in some shape or form are assigned to individual team members to complete. This often means the developers are left out of the discussions that revolve around why the task needs to be done in the first place; so developers are left with a narrow view of what is to be done. For this reason I find that most developers tend to focus on the “how” of a task.
For example most developers might think:
How can I prevent users from typing letters into this field?
Instead of:
Why do we need to prevent users from entering letters in a field?
You might be asking what’s the difference? When you ask why you need to do something it opens you up to a broader perspective which can open the door for better solutions. For example it may not be that you need to prevent letters from being entered into the field but rather you should not be attempting to collect that specific type of information at that point in your application. Or maybe you just need to limit the field to prevent special characters.
We should always ask ourselves why when working on tasks but the better question to ask is “what.”
What can I do to prevent users from entering letters in a field?
Let that sink in for a second….. “What” always makes you think more along the lines of the value you are adding to your software. What inevitably makes you lean towards asking yourself “What’s the real problem. What are we really trying to solve.” When thinking along the terms of “what” and “why” it helps us to change our focus on how to build software and how we build software is tightly coupled to the development processes we have in place.
If the types of tasks produced from your development process are mostly “how” tasks instead of “why” or “what” tasks it probably means they are fire driven or problem driven instead of value driven. This is usually an indicator of a place where we can improve the current process.
Our development process is important to us as developers because it is the means of how we create and deliver software to our clients and customers. A good process is a reflection of mature development team who is focused on delivering value to a project. When done properly we can reduce defects in our code, increase our efficiency as individuals and as a team, and change our overall view of the world we code in.
The post Why you should care more about your Software Development Process appeared first on Clear Measure.