Software Professionalism: Why? What? How? [Infographic]
Software professionalism is arguably one of the most important aspects of software engineering yet it is rarely discussed. Software touches every aspect of our lives on a daily basis, from personal interactions all the way up through enterprise transactions. Our data is stored in these systems and most of us put our livelihood in their hands. The truth is, our end users trust the software engineers to protect them and protect their information. It is our responsibility to do everything in our power to ensure the software we write exemplifies who we are as professionals.
A professional is typically: an expert in their field, extremely hard working, motivated and dedicated to producing quality results with no mistakes. Doctors are a great example of a profession that I associate with true professionalism. They work very hard, require a high level of training and skill, and they do everything in their power to make sure they make no mistakes. Doctors work in a very high stakes environment where the health of another person is in their hands. I would argue that the same could be said about developers.
While not every application we build is going to be critical to the health of another person, the enterprise applications we build as Force.com developers are critical to the business. These businesses depend on our applications to support their everyday work functions. At the heart of it, the employees and shareholders of these businesses trust us to run their business on our software. That is a huge responsibility and one we absolutely cannot take lightly. If we make a mistake, we could lose major revenue for one of our customers. All of a sudden, that company could suffer and other people's jobs could be at risk. That is why it is so crucial. This is why we must be professional.
Professional Force.com developers share a key set of qualities. Each professional will:
Unparalleled quality is something that should be expected of any professional. We should do everything in our power to ensure that every piece of code we write is thoroughly scrutinized and tested. It is our duty to make sure that any piece of code we work on meets our own personal quality standards. The business needs us to be ethical and enforce our own rules. We cannot waiver and we cannot allow poorly written code into a production environment. That is our responsibility.
As we develop, it is important to understand that business needs change. One of the key aspects to a business’ success is the ability to pivot. The ability to change focus and move in a new direction is even more important for younger businesses. As software engineers, we should be writing all of our code in an agile manner that provides the business with choices while still providing a high level of value.
Imagine a scenario where a business has a two-year roadmap ready for development. The software engineering team begins work, but doesn’t prepare to go to production at all until the two-year mark passes. Outside of not providing value to the business for two solid years, this can be a massive burden on the business if priorities shift. For instance, what if at the nine-month mark the business decides they would be better served using that software engineering team on a different initiative? At that point, if we aren’t using an agile methodology, we could be months away from something that is production ready. That is unacceptable. By utilizing an agile methodology, we can provide the business value quickly and iteratively. This gives the business flexibility that is crucial to that business’ long-term success and health.
As development progresses on a project, our productivity should never decline. It is easy to think that as we add more complexity, tasks will take longer to complete. However, that is incorrect and should not be considered as a truth. If we utilize good practices and write clean code, modifying that code to add new functionality should not be a problem. Our ability to continually refactor and leave code in a better state than when we originally touched it should provide us with a better environment for change as time progresses.
One of the ways we can ensure we maintain a high level of productivity is by being fearless. Every developer should have the luxury of being fearless when it comes to modifying code and that is only possible with a thorough, strong unit test suite. By utilizing proper test driven development (TDD) practices, every unit test should be written in a way to verify a piece of functionality. This provides tremendous value when it comes to actually modifying existing code because it allows the developer to click a button to verify the functionality still works. It also has the added benefit of giving the developer the means to automate part of their quality check.
One of the most difficult aspects of any development project is the estimation. Typically, businesses want exact information too early in the process. That problem is compounded by the fact that, traditionally, estimation is a difficult task for a software engineer. We work in a world with a defined set of rules. A computer will only do exactly what you tell it to do. Estimation is too much guesswork for most software engineers, and it just doesn’t fit very well with the rest of our skill set. With that said, the business still needs that information and there are ways we can approach this problem that can be effective and accurate.
The Cone of Uncertainty is a tool that can be used by developers to give a range to the business at any point during the development process. It is important to note that every estimate using this tool is a range, not an exact number. The reasoning behind this is that it is impossible to know exactly how long a task may take until it is complete. There will always be some level of unknown that could affect the time frame. The key to the Cone of Uncertainty is to have as much information as possible available to the software engineer when estimation is taking place. Either way though, if there isn’t much known, an estimate is still possible, however the range for that estimate will reflect the level of uncertainty involved with it.
Our industry is constantly evolving. This is very evident as Force.com developers with Salesforce provide massive releases three times each year. It is our responsibility to continually advance our knowledge not only on the languages we work on in our daily professional lives, but also broaden our knowledge by exploring other languages on our spare time. The fact is if you aren’t learning, you are actually falling behind. No one is expected to know everything, but the more you learn, the more you hone your skill of learning. This will allow you to adapt to situations and learn crucial topics quickly if the need ever arises.
If this is a topic that interests you, please check out my previous blog post on the topic and my inspiration behind this topic, Robert Martin’s “The Clean Coder: A Code of Conduct for Professional Programmers”. Remember, be a professional. People are counting on you. Visit the FinancialForce.com developer page to keep up to date with the latest features, tips and tricks.