Answering the 100 Interview Questions for Software Developers Configuration Management

home | about | contact | privacy statement

Answering the 100 Interview Questions for Software Developers: Configuration Management

Posted by Sam on Apr 25, 2009 at 12:00 AM UTC - 6 hrs

This is the ninth in a series of answers to 100 Interview Questions for Software Developers.

The list is not intended to be a "one-size-fits-all" list. Instead, "the key is to ask challenging questions that enable you to distinguish the smart software developers from the moronic mandrills." Even still, "for most of the questions in this list there are no right and wrong answers!"

Keeping that in mind, I thought it would be fun for me to provide my off-the-top-of-my-head answers, as if I had not prepared for the interview at all. Here's that attempt.

Though I hope otherwise, I may fall flat on my face. Be nice, and enjoy (and help out where you can!).

Browsing through the questions, I'm not confident here of my ability to answer without asking some preliminary questions (which I have no one to answer), so please chime in if you have something to add.

Do you know what a baseline is in configuration management? How do you freeze an important moment in a project?
A baseline in configuration management is the same as a baseline anywhere else - some place which serves as a starting point or point we can return to to compare one point in time to another.

Freezing an important moment in a project to me sounds like creating a new major or minor version - so I may make a new tag in the version control system.
Which items do you normally place under version control?
I can't think of anything I'd not put under version control aside from user-specific project settings and files created while executing the software (like logs, for instance) that are always likely to cause change conflicts between different developers.
How can you make sure that team members know who changed what in a software project?
Give everyone separate accounts to access the VCS. Some people like to keep a change log at the top of each file, but I think that gets ignored and becomes useless.
Do you know the differences between tags and branches? When do you use which?
A tag is for a static snapshot, a branch is intended for development outside the trunk.
How would you manage changes to technical documentation, like the architecture of a product?
I'd put them in VCS along with the rest of the project. I have to say though - I'm not sure I understand what this question is really asking.
Which tools do you need to manage the state of all digital information in a project? Which tools do you like best?
This is another question which I'd need prodding to give a more useful answer. My favorite would be a VCS, but what else exists? Are we talking about using Wikis and bug/issue trackers? Are we talking about using Excel to create spreadsheets to manage burndown charts and make predictions as to project completion dates? Are we talking about using Word to manage user documentation?

I'm unsure.
How do you deal with changes that a customer wants in a released product?
I mainly deal in web development, so in that case we just make the change and re-deploy the web application. In desktop applications, I've only ever released projects to customers who will be using it on so few machines that coming up with an automatic update strategy would have been a waste of resources.

If it was the right project, I'd have it do a call to a central server that looks for updates, and perform the updates automatically. In that case, we just make the updates and set a flag when a customer wants a change to a released product.
Are there differences in managing versions and releases?
As with so many things in software development, the answer depends on how you view versions and releases. If you view a release as the deliverable to customers and a version as a concept to get you there, then the answer is undeniably yes.

If you view versions and releases as the same things, then perhaps not so much.

Do you have multiple versions between releases? There are many questions to ask here, and I certainly don't have all the answers. Personally, I see them as a combination of the two views I mentioned above: the version is the version of the code that we tag at certain points in time. The release happens in tandem, but it is the deliverable we give to clients - so they differ in the way we manage them, because it's not simply an issue of "commit->version->release." I'd love to get there, but I'm not close yet.
What is the difference between managing changes in text files vs. managing changes in binary files?
diff is much less useful in highlighting differences in binary files than it is in text files (at least as far as the person running the diff is concerned). It is much harder to manage conflicting changes in binary files as a result.
How would you treat simultaneous development of multiple RfC's or increments and maintenance issues?
I fear I don't understand what this question is asking. RfC == Request for Comments? What does that have to do with increments and maintenance issues? Any advice as to what you think this question means is truly appreciated.

Reading through and answering these questions has made one thing very clear to me: I'm stuck in the middle of the forest and I'm only seeing the trees. I don't have a strategy when it comes to configuration management and version control. I use it, because I know I should, and it has some benefits. However, focusing only on the tactical side means I'm not getting as much out of it as I could.

How would you answer these questions about configuration management?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Comments