Dr. Dobb's Journal - September 2008 - (Page 31)

d09ryla_p2as 7/14/08 8:40 AM Page 31 isolation advantage in the wild. It also provides a baseline of the code before the upgrade, allowing an easily identifiable rollback path. Making similar platform accommodations garners support and respect for the build process. Human Factors: Managing Fear Underemphasizing the social challenges of software engineering can sound appealing but can produce additional work, or failure, in the future. The changes described here are always possible—there are simply consequences to deal with. The most prominent one that I have experienced is fear. The business stakeholder fears a development slow down if the source-code repository is changed and a build process is installed. These folks have goals they are trying to achieve via the development teams’ output. Software configuration management, build engineering especially, puts these goals at risk—or at least appears to. Your job is to point out the great advantages of the new processes, so education is key. Explaining exactly what the branching strategy is and how concurrent development will make more releases of a higher quality possible helps change the attitude towards the work. Development management may seem like an easy win, but that’s not always the case. If your team hasn’t had a structured build and release process in the past (and your systems are functional), the need for the large investment of time and resources may not make sense to them. The education here is different than for business stakeholders. Present these advantages to your team: • Maintenance of code is easier because of project isolation. • Bug fixes are quick to deploy because the source repository is clean and consistent. • Continuous integration keeps the product in a deployable state. • Release branches provide the ability to do hot fixes on released code without effecting current development. These are all big wins and make management look good. September 2008 l www.ddj.com l Dr. Dobb’s Journal Figure 4: Reverse merge. The last, and toughest, audience that needs education are software developers themselves. If development management seemed like one that should be easy, the development team can be even more averse to change. This is because your everyday developer is not simply talking about projects and ship dates. They are hacking the software out line-by-line, feature-by-feature. Causing big waves here can sink your efforts before their next release. Fortunately, this is overcome by helping individual developers change their habits. If you have a mid-size to large team, choose one or two developers to represent the new process. Teach them how to work within the new branches, environments, and the continuous integration dashboard before you educate the rest of the team. This way, you have some advocates on the inside. DDJ 31 http://www.scitools.com http://www.scitools.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - September 2008

Dr. Dobb's Journal - September 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook A Conversation With Erik Demaine Application Lifecycle Management Meets Model-Driven Development Building a Robust Development Environment Real Users Really Matter Matching Wildcards: An Algorithm The Android Mobile Phone Platform Managing Application Thread Use Signalling Integer Overflows in Java .NET Development & the IBM WebSphere Portal Server The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.