Posts Tagged ‘process’

Continuous Integration: Methods of getting change

May 14th, 2008 by jsherwood

 Continuous Integration: Methods of getting changeDo you remember the last time you were excited to go somewhere? Were you like a kid saying, “Are we there yet? Are we there yet?”

More likely you were the one getting ‘them’ there. I’m sure it got pretty annoying to keep hearing everyone in the car moaning, wanting some sort of distraction until they got there. Maybe you even had DVD players or some other distraction so you didn’t have to hear the questions.

Now think about how you use Continuous Integration (CI) . Do you have polling of your software configuration management (SCM) tool setup? What about your other process tools, do they poll your SCM as well? Guess what, it’s the same difficult trip. You have tools burdening your working SCM (who slaves away everyday to provide for these other tools!). Every hour/minute/seconds some tool is asking your SCM tool “Are we there yet?”. Doesn’t make a lot of sense does it? Think about how many tools you have running daily. You might have multiple CI machines setup, multiple reporting machines, deployment machines all asking the same question over and over.

Quite a burden.

Now think about what your users are doing during this time. They are looking for the same distractions you might have given the kids. They are off emailing their buddies about the latest game, or watching AccuRev on Youtube (OK, maybe something even more enjoyable on YouTube). Doesn’t sound very productive, yet these automation tools were meant to do just that, increase productivity.

So what do you do? Well, a lot of tools allow you to flip the model. Push your information, don’t pull it.

If you have a large enough development group this won’t be enough. Maybe there really are code changes going into the system every minute. If you also increase the granularity of the information going to your CI and reporting tools, these tools can then decide the correct time to be a burden.

You can also reduce the frequency that you give out the same information. If you have several tools (or stages in a tool) depending on the same answer, they can get the answer from a secondary source that gets populated once.

You also want to be diligent about your monitoring. If you see a periodic load on your tools, justify the load. If it looks strange that Kevin is checking the history of a stream every minute, it probably is. If instead you saw CIMonitor as the user it would be more explicit. And it would be obvious that this should change.

And really, changes like these apply to any tool you are using. Do you really need updated reports everytime a bug is fixed? What about every day instead? If you reduce the burden on your tools to a ‘necessary’ level, then they can be further used to answer other questions.

Are we there yet?

How Much Process is Enough? Just Enough

April 2nd, 2008 by brad hart

by Brad Hart

Hi, my name is Brad Hart and I am the Director of Technology at AccuRev, Inc. I’ve been working in the software delevelopment / process space for 10+ years. I’ve designed and supported numerous ClearCase / ClearQuest implementations both while working at IBM/Rational and as a customer at various companies. At AccuRev, I’ve been involved with countless implementations of AccuRev with our customers, everything from small to large, ISVs, Internal IT, and Embedded systems companies.

Over the years, I have seen so many different approaches for software development in all kinds of companies. One area that every company seems to struggle with is defining their process. There are many stakeholders in the development process (Developers, QA, Release Engineers, Admins, Management, etc…), and it is a difficult task to get everyone on the same page to ensure that the defined process meets the needs of everyone. One area of particular contention is the amount of process to use. I’ve worked with small companies with a handful of “cowboy” developers which had absolutely no process, and I’ve also seen the opposite end of the spectrum with so much process at large companies that it gets the nickname “pebble moving.” Neither approach works.

In the no/little process environment, developers just do what they want, where they want, and how they want. This freedom certainly seems nice for the developers. I’ve never met one yet who was yearning for more process… However, this hurts the company (including the developers) in the long run. Release Engineers have a difficult time reliably building and reproducing software, parallel development is held to a minimum, Admins lose control of the assets, Managers cannot track progress and at the end, less software is produced and what is produced is lower quality. The positive side is developers spend 100% of the time coding and 0% on process overhead. The negatives are poor software, slow delivery and regressions.

The opposite end of the spectrum is equally inefficient. Have you ever seen an issue tracking schema with 10+ tabs, 100+ fields, and a state transition workflow that can only be described using 5+ visio diagrams? I have…many times. In an effort to control each step that everyone takes, these companies suffocate their developers with way too much process. So much so that they cannot work at even close to their full efficiency. They may spend as much as 30% – 40 % of their time working within the many steps of the process and not enough time coding. From my experience, developers react to this in 2 ways. (1) They just succumb to it. They simply accept the are not working at full capacity and move on. This of course means the organization is only 60% effective and can only produce 60% as much software as the next company… (2) They rebel. A motivated developer will find a way around the process so they can be more “efficient” and get more code written. Their intentions are good, but the results are bad. This approach almost always results in disaster: broken builds, regressions, lost work, etc…

So what is the answer? Just enough process. Just enough is going to be different for each company and even each group within a company. It also is a moving target based on changes in business requirements, company growth, etc… The right thing to do is to get representatives from each stakeholder group and work together to define what all the end goals and requirements are:

  • How many releases do we need to ship per year?
  • How many releases at a time will we support?
  • What is our patching strategy?
  • Do we need to support distributed development?
  • Are we working with partners or 3rd party vendors?
  • Will we support customer one-offs?
  • What are our testing requirements and ship criteria?

Once you have the answers to these questions, you can start working on the process. The goal behind any process design is not to have a beautiful and elegant process. The goal for the process is to facilitate all actors in the process in doing the right thing and putting up just enough guardrails to keep from accidentally doing the wrong thing. Keep each business goal in mind and think about what it will take to make sure every actor has just enough information to accurately complete their task and just enough protection in place to handle common mistakes. That’s it. Don’t go overboard. That is just as bad as not having enough process. Don’t overwhelm people with information or steps to complete a simple goal. Should someone really have to fill in 40 fields to submit a defect? I don’t think so, but I’ve seen it. Keep it simple and straightforward. Just enough process is the key.

Also, make sure the tools you are using support the processes you’ve outlined. They should be able to implement your desired process and be able to adapt to changes in your process requirements.