What's It All About?

Since starting this blog at the end of July, I've received many kind wishes expressing appreciation for the information that the blog provides. However, I've also had a small number who have (politely) enquired whether the eclectic mix of topics is appropriate.They ask whether the SAS-related posts sit comfortably alongside the "other stuff".

This blog is headed "SAS and software development best practice". With the possible exception of our coverage of the Clipper Round the World Race, all of this blog's posts are written in the belief that they offer constructive advice or information for SAS developers. But what is a SAS developer?

I like to draw a distinction between what I call SAS Coders and SAS Developers. Coders measure themselves on their ability to cut code; developers measure themselves on their ability to understand their customers' needs and to deliver the most cost-effective solutions for their customers. What is a customer? It's anybody who stands to benefit from your work. Your list of customers includes the project sponsor and the users of your software. So your customers might be internal to your company, or they might be external.

Whether your customers are internal or external, you will still need a large bag of skills to understand them, to satisfy them, and to deliver what they need. And, that bag of skills does not simply contain SAS coding (syntax) skills. When I'm recruiting SAS developers, either for RTSL.eu or on behalf of clients, I'll look for skills in the following areas:

• Coding (SAS syntax, knowledge of SAS tools, and optimisation techniques)
• Requirements capture
• Design decomposition
• Modelling
• Construction techniques and development processes
• Refactoring
• Configuration management
• Peer review
• Dynamic testing
• Effort estimation
• Written and verbal communication
• Interpersonal skills

The specific role on offer will determine how much importance I place on each area, but I will expect the candidate to understand what each term means even if they don't have any skill or experience in all areas. For example, in many cases we use dedicated analysts, so the developer doesn't need to perform business analysis; but the developer will need to work closely with the analyst, so they sure need a good appreciation of the analyst's role and they'll be asked to review and use the analyst's requirements document.

Interpersonal skills and good verbal and written communications skills are crucial. Software development is not a task to be undertaken in isolation. The developer has to work hand-in-hand with their analyst and/or customer. In addition, the developer will need to work closely with the testers. And last-but-not-least, the developer needs to share his/her work with their fellow developers.

It's often the case that developers don't feel comfortable with the written word, but a picture paints a thousand words; I expect developers to be very comfortable with drawing tools. This doesn't have to mean high-end modelling tools - Microsoft Draw (and its equivalents) is often a perfectly adequate communication tool and can be used within both Word and Powerpoint.

For senior developers, I'd look for more of the same, as highlighted in Kevin Stevens' post on the 5whys blog. In summary:

• Remember what it was like to be a junior programmer
• Teach others to avoid the mistakes you made so they don’t stay junior for long
• Know about the next generation of technology coming down the pike
• Have enough sense to adopt new things because they’re the right tools for the job and not because they’re new
• Ship applications that reflect the hard work and integrity of your team
• Care for your team’s code like it is the piece of craftsman ship it truly is

I hope this post has gone some way to explaining the relevance of all of the "stuff" that I post here on NOTE:. It's something that I feel passionate about, and it's something that my clients tell me is very important to them. In summary, a good SAS developer embraces good IT practice alongside good SAS skills.

There is a paucity of material combining experience and advice for adopting good IT practice in the SAS world. I hope this blog offers a humble contribution. I'm (slowly!) writing a book that aims to provide a primer for all of the above - ideal for junior SAS developers to understand the breadth of their responsibilities, and useful for experienced SAS developers who may want to brush-up on their knowledge of practices outside of the SAS world.

What are your thoughts? Do SAS developers have anything to learn from the wider IT world? What practices and processes do you follow, and where do you learn about them? Have you read any SAS-focused books that talk about these subjects? Please comment and discuss...