Jun 22

Written by: David Moran
6/22/2008 5:07 PM

 

Keeping with the theme of my prior blogs, we're now to the actual brass tacks of development: coding. When I said that I would cover coding at the close of my last blog, I must confess that it was a poor choice of words on my part. I'm keeping at a higher level for now, painting a picture of software development over a series of blogs, so the real questions are:

What does a software developer do? And more to the point, just what is a software developer, anyway?

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 architect, artist, craftsman, and one mean SOB!

Architect and Artist

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 components required and the connection points (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.

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

The other essential aspect of design is the user interface, which is more artist-like than architect. Why? 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.

In my previous blog I mentioned something called “paper prototyping.” The process of laying out screens, determining what controls are on the screen, how the user will “flow” through each individual screen (as well as a series of screens) is not a paint-by-numbers exercise. It is like being an artist where you are striving to create an aesthetically pleasing, efficient and effective, ultimately delightful experience. It takes time, effort, and thought. Any many times, you ball up your paper and try again!

In my opinion, during design a software developer is an architect and an artist.

Craftsman

Now that we are at the actual phase where coding takes place, is a developer a craftsman?

Developers must take all the inputs – business and technical requirements, the design work – 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.

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 had to know much more about the underlying operating system (Windows®), and had to write a lot more “framework” code in the construction of a Windows® application. 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.

These days, languages include extensive libraries that are part of the product. At AMS Services in Portland, Maine, we use Microsoft .NET, which has a rich set of class libraries to leverage. The .NET framework itself is a platform, with multiple languages supported. We make use of both VB.NET and C# in the Portland office.

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. Patterns are a generic, “best practices” recommendation, but not implemented in specific code. It is up to the developer to take that 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 (hopefully!) 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.

For my money, during software construction, developers are in fact craftsman.

Next time, as part two of this blog, I’ll discuss testing as it relates to a developer. (And being a mean SOB!)

Copyright © 2008 by David Moran

Tags: