What is a Software Developer?

June 26, 2009

In his book Professional Software Development, Steve McConnell quotes someone he interviewed for a development position who answered the question “What is a software developer?” as follows: “During software design, I’m an architect. When I’m designing the user interface, I’m an artist. During construction, I’m a craftsman. And during unit testing, I’m one mean son of a bitch!” Truer words could not be spoken!

What does it take to be a developer in today’s world? Is this person that Steve McConnell quoted correct?

I think so. So let's take a look at a developer as an artist, architect, and craftsman, ignoring anyone being mean and ornery.

Developer as Artist
An essential aspect of software design is the user interface – the mechanism for user to interact with the software. Crafting a good user interface takes time and considerable thought and effort. Many software companies do in fact employ “artsy-types” to help create an attractive user interface.

For those that don’t, there is usually someone geared towards keeping abreast of research dedicated to the “user experience,” focusing on crafting a consistent, intuitive user interface that supports the business goals that the users want to achieve with the software.

One way of designing an interface is through a technique called “paper prototyping.” This is a process of laying out screens, determining what controls are on the screen, how the user will flow through the individual screens on paper. This is far faster and much less expensive than developing the actual screen and seeing if users like it.

Whatever means is used to define the user interface, it is definitely NOT a paint-by-numbers exercise! It takes considerable thought and effort to create an aesthetically pleasing, efficient and effective, ultimately delightful experience. Any many times, you ball up your paper and try again!

Developer as Architect
In the software world, there is a job title referred to as “software architect.” What is a software architect, and what does a software architect do?

A software architect focuses on developing a sound technical framework that other developers can work from. They focus on the layers of the system, the components required and the interfaces needed in order for a system to function; they don’t get into the nitty-gritty details of each and every component, but instead focus on the larger picture.

A good software architect is typically someone who can function as both a technologist and consultant. This dual role is necessary because a software architect will be involved in a variety of people: customers, management, developers, and project managers, to name a few. This means that a software architect must have solid technical and communication skills.

Developer as Craftsman
Developers must take all the inputs – business and technical requirements, the architectural design– and write code to pull all of this together in a meaningful way. In doing so, they must satisfy multiple audiences: other developers and the business users.

The code that they write must be reliable and maintainable; meaning that they or someone else should be able to look at the code at some point in the future, understand it, and update it. And of course, the business users must be satisfied that they can run their business on the software.

While the software architect tends to design in the large, what design work do developers perform? They focus on the design of component internals: the algorithms, data structures, and the organization of the code. Good software design organizes the internals of the components so that they will all work in harmony and in accordance with the high-level architecture, without duplication of code to perform similar functions.

Is there a prescribed method for writing software that can guarantee success? Writing reliable, usable, maintainable code requires that a developer to draw upon prior experience, guidance from others, tools and libraries, ultimately combining these into a concise, logical expression. In reality, there are no guarantees, but there are ways to reduce and manage risk.

Developers write software in specific programming languages. It is relatively simple to determine that a developer who focuses on one language versus many languages will have more depth and expertise in that language. As developers become proficient in the constructs and idiosyncrasies of a particular language, their code becomes clearer and more organized, leveraging the capabilities and recognizing any limitations of the language.

Not all that long ago, a developer writing a Windows® application had to know much more about the underlying operating system than he or she does today. Today, a lot of this “plumbing” code is handled through libraries; and while there is an investment in time required to understand what is available to leverage in these libraries, the benefit is that a developer is leveraged already written and tested code – increasing the reliability of the application.

Another mechanism used to reduce risk is through the use of something known as “patterns.” As those in the software industry encounters the same type of problem over and over again, the prescribed means for handling that problem is captured in a general way, providing guidance in terms of accepted rules and approaches for handling that problem.

This makes patterns generic, and it remains up to the developer to take a best practice and turn it into working code. Of course, this means that developers must be continually updating their knowledge about available patterns.

Over the years, I’ve personally seen significant differences in how developers approach and implement logic to solve business problems. Despite the guidance and libraries available, at the end of the day, it is up to the developer to weave everything together into a concise expression of logic that reliably supports the business need and is maintainable over time.

This is where developers are truly like craftsman. I’ve had ample opportunity to step through code that other developers have written and I’ve come away either very impressed at times, while at other times I’ve been left scratching my head.

Some developers clearly throw code at the problem until things work and make a mess as a result, while others simply are unable to express their logic are clearly as others. It’s like writing; some people can put words down on paper in ways that are more readable and understandable than others. And on occasion – not often enough – you come across solid code that is expressed so clearly and elegantly it is like looking at a masterpiece.

Which brings us back to a developer being an artist.