March 25, 2013
In the last few posts (Part 1 and Part 2) I’ve been talking about the juggling act of creating the kind of culture necessary for a successful programming or development organization.
So far we’ve covered innovation and interpersonal factors — today I thought I’d throw another couple of balls into the air by introducing the elements of standards and delivery.
Standards
Sometimes standards within an organization can seem kind of bureaucratic and unnecessary, but in fact they’re absolutely essential for an efficient work environment. They can be used in virtually any aspect of a business, of course, but within the software and development industry you’ll most often see them applied to the following:
- Coding. By applying rules for how code is formatted and written, a common ground for programmers is created that improves readability, eases software maintenance, and enhances a collaborative atmosphere.
- Requirements. These specify particulars related to program design, program behavior, documentation, user storage, etc. to ensure there’s enough information — and the right kind — to be meaningful.
- Development processes. Standards here will vary according to the model being implemented and can relate to everything from how you check in files to how you conduct unit tests.
- QA testing. QA processes and methodology are defined for different types of testing, such as performance, functional and data.
- Intellectual property. In an outsourcing environment, it's clear that you can't just take code home with you or leave it exposed. Standards in this area ensure protection of IP both for clients and for partner companies.
Delivery
The delivery element is all about having clearly defined goals and dates, coupled with a commitment by teams to meet those dates and deliver software on time. These goals not only apply to teams but often to management as well.
Obviously, communicating goals clearly and frequently is crucial if everyone’s to be on board and pulling together as a team. Regular feedback — something that’s optimized by establishing quantifiable measures of your goals — is also a must in order for the team to be able to adjust its priorities or pace as necessary.
Culture Jamming
Unfortunately, it’s all too easy for us to not notice or appreciate things until we realize they’re missing. And trust me: When standards and a defined delivery system are missing, the results are plainly obvious — and definitely not good for company culture.
For instance, when I joined a company in the 1980s as a programmer, initially I was really impressed with the firm’s product and how it looked on the screen. Once I got into the engineering department as a programmer, though, I realized how disorganized the business was. The company went for multiple months without releasing the software we were working on, and it just seemed incredible to me that people couldn't get their acts together in order to decide what they should release and what they needed to do to actually test and release it. Clearly, here was a culture where they weren’t committed to delivery or standards, and, quite frankly, the company seemed to work at cross-purposes with itself.
Then again, there was at least one silver lining: By seeing things being done wrong, I learned to appreciate the importance of doing them right, and now I recognize and try to work with companies that share this outlook. It’s no accident that our partner companies are very good at planning and organizing — in an Agile development environment, for example, they’re adept at defining the sprints well so that there's a minimum of delay and a commitment to delivering software on time.
Because these elements I’ve been discussing are so critical for success in software development, choosing partners that appreciate and promote them — not to mention the many other factors necessary for a productive company culture — just makes sense.
That’s all for now, but I’m far from done. Next post, I’ll discuss three more crucial elements of a successful programming culture: communication, empowerment and selectivity. Come on back.