Home 
CM Journal Articles Four Lessons about Company Standards and Procedures from Build Management
CM Journal Articles Four Lessons about Company Standards and Procedures from Build Management
|
 This article is about two questions. The first question is: what's
the value of company standards and procedures in software development?
One way of thinking about the importance of something is to imagine
what life would be like without it. The second question is: how do you
create and maintain company standards and procedures? In a similar
vein, I'll look at this question by thinking about how standards can
fall into disuse. As a running example for both questions, I'll
discuss a situation about standards and procedures for Build
Management. Let's see what lessons we can learn.
Build Management is a part of Software Configuration Management. Building your software is the process of transforming your source code Configuration Items into executable product Configuration Items. Build scripts define a procedure for how your product is put together. They say what source code is part of the product, and how all the source code components are assembled. Often build scripts are Makefiles, but various companies use Ant, Maven, shell scripts, IDE project files, manual written procedures, or a combination of all of the above. What do you imagine happens if you don't have company standards and procedures for Build Management? Sadly, this isn't a hypothetical thought experiment - I once saw a company where the challenge for newly hired developers was to get the product built and running in their first week on the job. If they couldn't do that, they were asked to leave! That's sort of funny, but only from a distance. Building your software product shouldn't be a challenge. With no standard build scripts, everyone had to struggle to re-invent their own approach to building the software. On the other hand, when there was a standard build script that was used by everyone, it could be used by anyone. Lesson One: company standards and procedures can make some hard jobs easy (or at least make laborious jobs routine). In this situation, it wasn't just new developers who suffered, but also the system test and release teams who had to work out how to do their own builds. Everyone had their own private build scripts, and as a result, everyone had a slightly different product. This could hurt customers, too - when it came time to try to investigate customers' bug reports, developers had to second-guess what source code might have been compiled and delivered to the customer, which reduced the speed and effectiveness of bug fixing. With no standard build scripts, there was no agreement on what the "real" product was! However, with a standard and agreed upon set of build scripts, it became possible for everyone to build the same product, and to know that people in other teams were also building the same product. The development, test, and release teams could all sing from the same song-sheet. Lesson Two: company standards and procedures can reduce unexpected variation and define a stable interface between different teams. The tragi-comic situation this company found itself in didn't arise out of nowhere. The software did originally have some working build scripts, but when I initially saw the company, the build scripts had fallen into disuse. Let's look at how this happened, and see what lessons we can learn about creating and maintaining company standards and procedures. No one used the old build scripts, because of the simple reason that they didn't work. The test and release teams couldn't use the scripts to build the whole product, and the development teams couldn't use the build scripts to build individual components and debug or production versions of the whole product. The different teams had slightly different needs from the build scripts. In this company, a newly designated build engineer spent time eliciting build requirements from each of the various teams, to understand who needed what. Lesson Three: when defining standards, make explicit who relies on the interface defined by the standard, and what the key requirements for the interface are. No one fixed or maintained the broken build scripts, because no one seemed to be responsible for them. An important role for a standard is to define a stable interface between many different teams (Lesson Two), and so it's perhaps not surprising if no single team sees themselves as owning the standard. Build scripts can also suffer from this problem if developers think that building the software is obvious ("it works on my machine"), or if they think that writing build scripts is a boring, low-status activity. On the other hand, it might not be entirely reasonable to expect non-developers to understand the intricacies of the detailed and evolving dependencies between software components that must be accommodated by the build scripts. The solution at this company was for a senior manager to take moral authority for the build scripts, to designate a build engineer to define example build scripts for the products, and to get buy-in from the developers to create and maintain the build scripts. Lesson Four: define an owner for the standard, define who's responsible for meeting the requirements of the standard, and make sure everyone knows and agrees that the standard is a standard! Sometimes you can learn more from failure than from success. In this article I've tried to extract some general lessons about the value and maintenance of company standards and procedures by looking at some of the consequences arising in one company that had lost the use of standardized working build scripts. I'm sure there's plenty to debate about Build Management - look out for the September issue of the CM Journal! But, do the four lessons in this article really apply to other software development standards and procedures? I'd be interested to hear your thoughts!
Mark Staples is a Senior Researcher with NICTA, an Australian research institute in information and communication technology. Mark’s research is in software engineering, especially configuration management, software product line development, and software process improvement. He has more than five years’ experience in commercial software engineering roles, and a PhD in computer science from the University of Cambridge. He maintains an irregular blog about software engineering and homebrewing.
Set as favorite
Bookmark
Email this
Hits: 5159 Trackback(0)Comments (2)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... Liming - thanks. I know what you mean, but projects will always end up tailoring generic company standards when they use them. Anyway, I think if a project/product-specific interface is defined, stable, well-known, and used within a company then it is a company standard! |
Liming Zhu
said:
|
... nice article, Mark! I understand what you mean. But the word "company standard" can be a bit confusing at times in relation to project/product specific "interfaces" and procedures. |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
