How often do you visit fortunetellers? Not too many of us make a habit of visiting the local palm reader before making major software decisions. But how much different is a visit to the friendly neighborhood soothsayer compared to many of the "shoot from the hip" decisions we make? If you're about to implement a very large ClearCase solution, you might find yourself cutting corners in the name of time. How different is corner-cutting from fortune telling? Let's hear the rationalizations: You manage a team of smart, competent people who should know exactly what they're doing, right? The software comes with full documentation, and the default install process is fairly simple, right? The new software should plug right into your team's existing infrastructure and development processes, right?
Since we're leaving so much of your future to fate, let's look at your options from a fortuneteller's perspective: Down one path we see pain, misfortune, and possibly failure. This might equate to poorly defined requirements, improperly defined handoffs and procedures, and a non-scaleable architecture. Down another path, we see hard work, but smart management of your intellectual property assets, and, ultimately, success.
Designing and building a software configuration management solution is much like following the counsel of a palm or tarot card reader if you don't plan for it: without proper planning, you're letting fate decide your success. Remember the old adage, "If you fail to plan, you plan to fail."
Gosh, that always sounded so hokey when our parents or a teacher threw it into a lecture or reprimand -- and yet we've seen firsthand the results of poor planning affect far too many teams and projects, usually with the intent of shaving a few man-hours from the schedule.
Here's another way to think about it: You're getting ready to take a long trip overseas. Do you just grab a backpack, throw in some odds and ends, and head for the airport? For most of us, of course not. You think about what you'll need, maybe you'll jot down a list if items to bring along. You do some planning, think about how many days you'll be gone, which clients you'll see and in what social settings, the weather of your destination, and the extracurricular activities you might partake in. Yes, you could throw into your bag an extra pair of shoes, some socks, and a few pair of underwear and probably make it for a few days. But is skipping some planning steps up front really worth all of the trouble? Four days down the road, you don't want to be stuck in a meeting with clients in Singapore wearing the same outfit you wore on the plane, without fresh socks and underwear ... metaphorically speaking, of course.
It's quite simple -- you need to plan. Here's a start: think about all of the actors. Understand their relationships. Build your use cases. Apply them to your business rules for validation. And then build your plan. It all begins with a few targeted questions. But do you even know which questions to ask?
The questions posed here are nothing but a starting point to building a system and toolset that meets your organization's long-term development needs. We all suffer from "writers block" from time to time -- so think of this list as a tool to help grease the wheels in your brain. Here's where we would recommend you start:
How big do you think the project will be?
This is an interesting question and often times difficult to answer. How do you determine the size of the project? Do you use lines of codes, number of classes, Function Points, or what? In most cases, the LOC (Lines of Code) is a good start for determining the size of the project. You can use several different methods to project the LOC for a project. Check out "A Discipline for Software Engineering" by Watts Humphrey (1995) for some ideas.How many people will be involved in the product development?
Size of the project is not only determined by the amount of code you will produce, but also by the number of people on your development team. Many times you can 'guesstimate' the number of people that you will need on the team. When doing this, don't forget about the supporting roles of software development: QA, Project Managers, Technical Writers, and even managers. These people need to get access to the Code and can benefit from using ClearCase just as much as -- if not more than -- the software engineers.Some might say, "We don't need to worry about the size of our VOBs because the new ClearCase Architecture allows us to have really large VOBs." Just because you can have HUGE VOBs does not mean you should have them. Let's not forget that segmentation and the use of multiple VOBs have their benefits.
At how many locations will the product be developed, tested, and deployed?
If your first inclination is to answer "Well, we're only here at the one location" or that your team can just telnet into the central office to do their work, then your project is either really small or you are not thinking big enough. With the expansion of broadband communications throughout the world, more companies are looking for cheaper ways to get teams to work together. It is expensive to move your whole team to the Silicon Valley, when you can just as easily put a VOB server in each employee group's geographical location. Or maybe the product is being tested and/or developed overseas. The number of locations and the work that each location is performing will play an important role in your VOB architecture, triggers, and integration with third-party tools.Is the product internal of external?
If the product is external, what is the delivery mechanism that you are going to use? Are you burning a CD, will it be and Internet download, or are you supplying a service? Can you use a VOB to control your releases? How often do you need to release the product to the customer? Is the product mission critical for your customers?When a product is internal, you typically have to deal with internal integration problems in addition to the normal external customer problems. Are other teams going to use your project to develop their product? Are they using ClearCase? (In a perfect world, everyone is using ClearCase) How often can they get releases from your team? And what kind of coordination do you need to provide?
What are the third party tools that you will be using?
How many third-party tools do you plan to use? Make a list of all of the third-party tools that your development team (your expanded team, as mentioned above) is using. Don't forget about project management, testing and technical writers. It makes sense to have some kind of VOB strategy for these tools. This includes things such as OS patches, compilers, Quantify, Purify, FrameMaker, MSWord, and so forth. There is nothing worse than having to spend weeks patching a mission critical product that is over five years old, and you don't have access to all the tools you need to build, test, and document the thing.What is the development cycle of the product?
Are you using a traditional waterfall method to develop your product? Is your cycle time Internet fast (3 months), or telecom slow (7 years)? This can play an important part in the way you layout your VOBs. You want to make sure your VOBs and ClearCase are not getting in your way, and actually help you get your job done faster. If you have a plan, you can use triggers to help enforce policy and automate things that are typically done by hand.If you cannot answer this question about development cycle, let us point you to the Rational Unified Process. It is a good place to start for those in need of some direction.
How do your current development methodologies fit into your tool plans?
We have seen far too many groups change their process to fit their tool set. This can be a dangerous exercise in bureaucracy. You might find processes that nobody can remember instituting, or that have to defined purpose. We have even seen processes created in an effort to circumvent the process that no one could remember creating or instituting. Most of the time, we view these as shortcomings of the tools your team uses. It's important to find the right tools to fit your methodologies. Most today are very flexible and customizable, and can handle whatever processes you might come up with.Are any key roles missing from your team?
Make sure that you have included everyone in the development team that you need. Think through several scenarios. Were you asked recently for information about the project from someone that you don't have on your list as a key player in the development of the product? What was their role, and should your team be expanded to include this individual? If you are working with more than one location, who is the person responsible for coordinating meetings with all locations? Who is your multi-site administrator? Does your customer need access to ClearCase Release VOBs? Make sure you have everyone written down.Do you have the hardware you need?
It is really hard to deploy a development environment and ClearCase without hardware. While it can be done, there is nothing worse than putting your VOB server on someone's desktop machine. You never know when you will have a janitor turning machines off in the middle of the night to save energy, or, more commonly, have the A/C in your office turned off on the weekends to save money. That one is always fun. Make sure you have the hardware that you'll need up front. It is much easier to do it right the first time then to try and fix things later.Do you have the infrastructure ready to support your plans?
Another item that people often forget is the infrastructure to support your development plans. A/C, power, floor space, and networking are important to ensure you have a successful development environment. If you are in a situation where you have to boot your machines in a specific order so you don't throw circuit breakers, you definitely need to get more power. If the $12.99 "Blue Light" special fan from Kmart keeps your computer from overheating, you need more A/C. Another thing to consider -- if you are developing in multiple locations, you will need to make sure that you have connectivity to all locations (it's the little things -- like connectivity -- that always come back to haunt you). The hardest part, of course, is convincing someone that has the money to make the investment. If you do the work up front and have your project properly planned, it will be much easier to convince the senior executives of these kinds of expenditures.
Preparation is the key to successful deployment of ClearCase, pure and simple. Ask the right questions, gather the right requirements, connect to all of the necessary tools and processes -- and you've got it made.
Now You Know ... and Knowing is Half the Battle
Knowing how to set up your VOBs and ClearCase environment can seem like you're trying to peer into the future, because you need to predict the future of the product. But unlike the telephone fortunetellers who make baseless recommendations on how to live your life, you need to start asking questions -- and making some key decisions based on the answers you get.
How many people will be involved in the product development?
There are many efforts that start out as if you're relying on fortunetellers, but as you slowly start answering these questions, your project becomes a self-fulfilling prophecy. By properly planning things, you use less of the "predictions" and greatly reduce the risk.
Smart deployment is all about risk management -- planning reduces risk. And properly planning for a strong source code management system will roll over into other practices. With a strong set of tools and processes driving your development machine, you'll find your team planning their development efforts with more rigor and logic. The resulting products will be well, better.
Think of it this way -- when you were growing up, did you ever notice the difference between doing homework in a messy room versus one that was clean, from top to bottom? Clinical research shows that students in a clean and orderly environment excel over those in a messy environment. So how different is this from your work environment?
How clean is your room?
Christian Buckley is a Principal of Red Hill Partners, a technology consortium and content provider. He is also co-founder of the East Bay I.T. Group, the San Francisco East Bay's premier technology forum. Christian writes on numerous business and technology topics, and has been writing for Rational since 1998. With writing partner Darren Pulsipher, Christian recently published his first book, Secrets of the Change Agent. He can be reached at buckley@redhillpartners.com.
Darren Pulsipher is a Configuration Management Architect with Cadence Design Systems (http://www.cadence.com) in San Jose, California. With writing partner Christian Buckley, Darren recently published his first book, Secrets of the Change Agent. He can be reached at darrenp@cadence.com.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
