«    »

Our Mission as Software Developers

What is your mission as a software developer? What motivates you? I recently reflected on my values and goals as a software developer and ended up creating my own personal mission statement. I feel that one of the clauses in my mission is broadly applicable – certainly to my team and department at work, and probably to most software developers in the industry. Here it is:

Working Software

Being Used

Meeting Users' Needs

This statement is deliberately formatted into three lines. Each line holds a specific meaning for me.

Working Software

This is fundamentally what software development is about. The software we produce needs to work. You may think this is too obvious a point. Over the last few years, however, I have witnessed (but fortunately never been part of) several software development projects that ended in failure because the software simply did not work – typically due to too many defects or performance issues.

It is no coincidence that one of the values of the Agile Manifesto is "Working Software over Comprehensive Documentation". I purposely chose the phrase "Working Software" in reference to this value. Some of the failed projects I witnessed had hundreds of pages of carefully written, reviewed, and signed-off documentation. But these documents become essentially worthless because the software did not work.

The mission to produce working software should motivate us both to produce quality code and to continually develop our abilities as software developers to improve in our ability to deliver working software. If this does not resonate with you, then I think you should carefully examine whether software development is the right career for you.

I find it very rewarding to finish a section of code, see the green JUnit bar or the user interface, and know that the software works. While this is a necessary first step – the foundation of what we do – there is much more to my mission. Once software works, the next step for it is...

Being Used

I mentioned above that application documentation for software that does not work is essentially worthless. Similarly, working software that is not being used has basically no value. You may disagree with this statement so I will offer another viewpoint: software that is being used is producing value. Unused software is not providing value, although it may have the potential to do so.

Why do I care about producing value? When I use the term "value" I do not mean financial benefit or revenue. In this context I define value to mean providing or being of benefit to people – contributing to their well-being.

Some developers may be satisfied with just producing working software even if it is not used. If given the choice, however, I think most developers would prefer to see their software being used – not just by themselves but by others. I personally derive an immense amount of satisfaction from seeing software I produced being used by actual users. My mission, therefore, is not just to produce working software but to ensure it ends up being used.

Having software be used is no guarantee that it is providing the maximum value possible to others, especially for enterprise software that users often have no choice about using. In order to maximize value, software must not only be used but must be...

Meeting Users' Needs

How often have you used software that has repeatedly annoyed or upset you? Perhaps it has an illogical user interface or performs poorly. Perhaps it does not quite do what you need it to. You might use the software and get your task done, but it was not a pleasant or easy experience. How rewarding is it as a software developer to have your software being used but it causing the users to suffer?

To prevent this we must ensure that the software meets the needs of the users. What are the users really trying to accomplish with the software? I explicitly used the word "need" instead of "want". Users are typically quick to list "wants" that are not true needs. Delivering "wants" typically results in either unused software or unsatisfied users. Needs go deeper, ideally tapping into the mission that the users are seeking to accomplish with the software.

The Process of Creation

I went through many revisions of my mission statement before settling on the version presented in this article. I want to discuss some of the process and reasoning behind my mission to help you create your own.

Early in the process I arrived at the three phrase format with the progression between phases. This appealed to me on several levels. I liked the poetic style based loosely on Haiku. I am not into poetry normally, but expressing my mission in such a style represents the expression of my creative side, and not just my logical side, in the development of software. The progression between phases reminded me of Maslow's hierarchy of needs, with working software representing a survival need and the other phases loosely corresponding to esteem and self-actualization needs.

My first version using the three phase format was biased strongly towards enterprise software development, which I specialize in. This first version was: "Working Software, In Production, Meeting Business Needs". The two phrases "Working Software, In Production" are especially appropriate for enterprise maintenance teams since it also speaks to the necessity of keeping the software operational and incident-free in the production environment.

As I evolved this statement into a more general form, I struggled with the phrases "Being Used" and "Meeting Users' Needs". I worried initially that the "Being Used" phrase was redundant and could be eliminated. Further reflection, though, made me realize that the phrase "Meeting Users' Needs" is a little ambiguous on its own: is it referring only to writing software that meets users' needs, or is it referring to users using the software and having it meet their needs? I mean the latter, but it is all too easy as software developers to focus on just writing the software. Thus the importance of the phrase "Being Used" in explicitly stating that the software must be released and make its way into the hands of users. This is especially relevant in an enterprise environment with many hurdles to getting software into active use.

There are two points I tried to fit into my statement but ended up leaving out. The first was the notion of quality. I wanted to express the idea of taking pride as professionals in producing quality software. I did not want to use the word "quality" directly, however, due to its potential association with quality assurance and related aspects such as certifications and formal processes that I did not want reflected in my statement. Perhaps the simplest definition of quality is "fitness for use", and I feel that all three phrases of my mission link nicely into this definition.

The second point I wanted to bring into my statement was the ideal that software should delight users. "Meeting Users' Needs" taken to the highest level should delight users, but this seems like a bit of a stretch. One option I considered but rejected was to change the third phrase to be "Delighting Users".

Conclusion

My ultimate goal as a software developer is to make a positive contribution in the lives of others by helping them achieve their goals through the software I create. My mission represents the steps involved in achieving this goal:

Working Software

Being Used

Meeting Users' Needs

If you find this article helpful, please make a donation.

«    »