What topics should be in a software dev book?

[Kathy Sierra]

We're having a debate about the kinds of topics that should be covered in a book on "software development" (whatever that label actually means to you), AND about whether people would be *interested* in those topics (which may be two different things).

For example, I'm suggesting that the so-called "soft-skills" of personality, interpersonal interaction with boss and teammates, etc. is in the Really Important category, but that it's unlikely most new programmers would think they need help there and buy the book. Others disagree with me... I'm leaning more toward thinking that the *hard* skills are of more interest (how to do requirements gathering, testing, etc.) and then the question becomes, WHICH methodology? Is there still a way to talk about these topics in a generic way, or do you NEED to specifically say, "This is how you do requirements in an XP/Agile world and this is how you do it in RUP, etc.?"

Anyway, a bunch of us are fighting over this, so I'd love to hear what anyone else thinks about this... and especially, of course, about which topics YOU would want to learn about! I'm also keenly interested in how others view the gap (and how big a gap they see) between what some people THINK (and want) other people to know, and what those *other* people actually want to learn... or am I oversimplifying?

cheers,
Kathy

[fred rosenberger]

this is not an easy question you pose. I'm not an author, but I think the "hard skills" would be easier to write about. It's hard to tell someone that they need to get along... well, it's easy to tell them that, but the nice people already do, and the jerks won't realize you're talking to them.

If you can do it, more power to you!!!

I'm still amazed that i've survied the transition from 'school' to 'the professional world'. learning how to write code is one thing. but learning how to write code in a team is completly different than anything i was ever taught. Dealing with ever-changing (or non-existant) specs is a challenge.

probably most of us began as maintenance programmers. "Here's a problem, and here's the 1,000,000 lines of code. fix it" is about all i got on my first day. Is there a way to learn how to learn what somebody else was thinking when they wrote code? i'm talking bad, poorly written, poorly documented code...

Dealing with management who says "The sales team promised this product would be released on such-and-such a date." Why the frell does the sales department get to decide when something will be done? How do you estimate what is a reasonable time for a given project?

these are some random thoughts that popped into my head when i read your question and just started typing. maybe this will help jump start the thread...

good luck!!!

[Sania Marsh]

I'm a junior, I've read 2 of your books and I would buy any book with your name on it, but I would skip the soft-skills chapter, just don't feel it would be important for me.

What I want to learn..

I have worked with many small projects, mostly alone. And every time I start a project I get myself all stressed out, because I'm afraid to make wrong decisions.
Some of the questions I need to answer all the time:
How to brake project into classes?
If I start making them too general, and then extend to more specific, it may take too much time, and there is no guarantee I will ever need the base classes. Making the classes very specific may make them hard to maintain and make them too complicated..
So where is the golden middle?

Small tricks that make your life easier. Need to keep them in mind all the time, like getters and setters. And not only "Do it", but "Do it, because...", well you are actually good at that, that's why I like your books.

When a junior programmer becomes senior?
One may spend years of developing bad software. So I don't think years or experience make programmer better, there must be something else, what is it? How can it be measured?

There are many projects that are dead - years of work and no result, why?
What did they do wrong, so I don't do it in future.


Hope I didn't write something stupid. And if I will come up with more questions, I'll come back.

[Sania Marsh]

One more very important for me question.
What are different ways to back up your code?

[Kishore Dandu]

I would also add a section on how to reuse code(in a efficient way).

This can be done using google or other search tools. It will add good development productivity to cut and paste some code, rathen than reinventing the wheel(for algorithms etc).

[Max Habibi]

I agree with Kathy: the soft skills are critical, and someone, somewhere, should write a good book on them. I double dog dare you

M

[Kathy Sierra]

Originally posted by Max Habibi:
I agree with Kathy: the soft skills are critical, and someone, somewhere, should write a good book on them. I double dog dare you

M

Hah! There is *zero* chance that I'd be writing something on soft skills--I tend to stir up trouble wherever I go, so I'm definitely not the one for that job But my question is, should *somebody* do it? But just as importantly, would anybody *buy* it? I'm with Fred on this one for sure. But then again, maybe the people who *need* it won't buy it, but somebody else will buy it *for* them and sneak it onto their desk in the middle of the night I know that I've worked with people who I would probably pay out of my own pocket to send them to a class on communication skills!


OK, I'm glad folks are posting to this thread... this is a very interesting discussion, I think, if people really talk about what they DO feel is important for the job of a software developer. Because it does seem that a lot of the skills and qualities have changed, although plenty of things have stayed the same. But even the soft skills are different... attitudes and behaviors and language are different for generation Y than for baby boomers, for example. Things my mother would have slapped me for are regularly part of some of the meetings I go to. Heck, some of the things I would have been slapped for I've used in our books

cheers,
Kathy

[Don Stadler]

Put in the soft-skills chapter fershure. I'll buy the book just on that basis just on the chance there will be something new to me!

Another thing which I'd like you to consider is a chapter about long-term survival. More of a career thing, but it's really important. Too many of us make poor choices and wind up cornered when the gales are already rising. Some creative ideas on strategy (how to avoid being in a leaky ship at galetime) and tactics (how to avoid the chopper when the Grim Reaper is loose) would be useful.

[Sania Marsh]

Just curious, what would they write about in 'soft-skills' part? How is it related to software development? There are tons of books on communication skills, how is this one going to be different?

[Warren Dew]

Actually, I think there are plenty of books out that do cover soft skills. "Peopleware" is the obvious one, but the XP books do too, as do "Death March" and parts of "The Mythical Man Month".

Personally, I'd like to see a book that focuses on teaching people not to write the kind of code Fred Rosenberger had to deal with.

[Max Habibi]

As someone who's run teams for a long time, let me chime in here: Bad code doesn't suck-the-life-out-of-an-organization, bad social skills do. I can always, always, always fix the technical problems, or get someone who can: Poor attitude and poor communication problems are the real dangers.

This probably has to do the maturating nature of software development as a whole. Today's projects are larger, more social, and much longer lived then they were just five years ago. This has changed the entire landscape of software development, but it's not really being acknowledged. I no longer need people who can make a miraculous architectural breakthroughs: we have Good Enough software. What I really need are people who I can stand to work with for a long time in maintaining those systems. I really wish someone would write to this.

M

[Mapraputa Is]

Originally posted by Warren Dew:
Actually, I think there are plenty of books out that do cover soft skills. "Peopleware" is the obvious one, but the XP books do too, as do "Death March" and parts of "The Mythical Man Month".

Did you have a chance to look at "Agile Software Development" by Alistair Cockburn? He seems incorporated a lot of recent ideas regarding communication, teams, etc. It's a bit theoretical, but I think you would enjoy it (if not yet).

[Warren Dew]

Max Habibi:

As someone who's run teams for a long time, let me chime in here: Bad code doesn't suck-the-life-out-of-an-organization, bad social skills do. I can always, always, always fix the technical problems, or get someone who can: Poor attitude and poor communication problems are the real dangers.

Interesting. When I've been a manager, I've found the opposite: finding really top notch technical people is difficult; getting them to work together is at least straightforward. It often took up 80% of my time as the manager, but that's what I was there for: it was my job to facilitate communication and remove the causes for bad attitudes. This allowed the technical people to be free to get the work done, without having to worry about the touchy feely stuff.

One of the things that's interesting about XP is that it actually does do some of the manager's job for him.

What I really need are people who I can stand to work with for a long time in [i]maintaining[i] those systems. I really wish someone would write to this.

I could go for a book on how to fix the kind of code Fred had to deal with, instead of how to avoid writing it....

Mapraputa Is:

Did you have a chance to look at "Agile Software Development" by Alistair Cockburn?

Thanks for the recommendation - I put it on my wish list. It isn't often that new books come out on people issues - probably because humans are evolving much more slowly than technology.
[ August 26, 2004: Message edited by: Warren Dew ]

[Max Habibi]

WD:finding really top notch technical people is difficult; getting them to work together is at least straightforward. It often took up 80% of my time as the manager, but that's what I was there for: it was my job to facilitate communication and remove the causes for bad attitudes. This allowed the technical people to be free to get the work done, without having to worry about the touchy feely stuff.


MH: It might be matter of where the manager's comfort zone is. It's rare that I can't get a solution to a technical problem when I need it. The hard part, in my experience, has been getting people to manage themselves. The software world, especially given the sorry state of the economy, is teeming with talented and experienced people. It's not, however, teeming with talented and experienced people who have the softer skills of personal integration.

This is typical of almost any business. Technical talent is almost never enough: the world is full of amazingly technical people who can't work in a team environment. The soft skills, professional attitudes, etc., are what set the exceptional people apart.


WD ne of the things that's interesting about XP is that it actually does do some of the manager's job for him.


MH: I'm an XP fan, but there are no silver bullets out there. XP, like any other methodology, is only as good as the team using it: a good team can make anything look good, and a bad team can make anything suck.


WD:I could go for a book on how to fix the kind of code Fred had to deal with, instead of how to avoid writing it....


MH: There are millions of books, exactly on that topic out there, and some are excellent.

I'm not sure what you meant to say by 'avoid writing it', but I assume you meant writing bad code? If so, I agree: we do need that book. but it's not the only one.

We also need books that teach people how to avoid the common sorts of social mistakes that can make professional software development difficult for themselves, and the people who have to work with them.

We need books that teach the values of curiosity, generosity, concentration, and the down-to-earth practicality of everyday niceness. We need these things to be taught in a practical manner, with specific examples, as they relate to software. Now that, I could go for.

M
[ August 26, 2004: Message edited by: Max Habibi ]

[Sania Marsh]

I thought of one more thing, not sure if it will be interesting for others, though.

The rules for writing programs, like how many lines a method can have at most, and how to name variables.
In my school some teachers would suggest short names,
others would force you to write the whole meaning in variable name like number_of_years_spent_in_prison
I think I decided what is right for myself, but working as TA I've seen many students very confused, since teachers don't agree on many topics like that.

Also rules for GUI would help

[fred rosenberger]

I like Don's suggestion, (or at least my spin on what he said)... career survival. Something i've always struggled with (and granted, i'm relativly new in the biz at 5 years) is how to keep my skills current?

everything changes so fast, it seems like as soon as i learn something, it's not being used anymore. Or, i start to learn something that ends up dying. I started as a C programmer, then took a couple of C++ classes just before my company made the switch to Java.

I've considered learning Python, which somebody here said would be huge, but he's the only person i've ever heard talk about it (maybe it IS huge - not the point).

What's the best way to learn what i should be learning? Maybe i'm asking for a crystal ball here, but if i don't ask, how will i know if it exists?

[Dave Wood]

I think Fred's point about career survival is a very interesting topic. And it hits at many different levels. For example, I co-authored a book on Java Swing. This was great for my career, but on the other hand, I was late to the J2EE party as a result...and have had to try to catch up. But when I start to feel sorry for myself, I think about people who have been working with C++ for years and are trying to break into the Java world without any Java-specific experience, much less J2EE.

It can be very tricky. If you stay at one company for a long time, it's easy to get stuck in a world that doesn't let you grow as much as you'd like. That's just the reality of working somewhere that actually has code in production. If it's a C++ shop, you're not likely to break into the Java world. If it's a standalone Java/Swing app, you're not likely to get into J2EE. etc...

There are so many mini-worlds within this industry, too. You mention Python. Personally, I don't know a thing about it (ok maybe a thing...but not much more), but there are dozens of books and I'm sure tons of applications that use it. I imagine many people living in the Python world feel they are on just the right track (and they probably are).

I suppose one thing I'd recommend in an attempt to cover this sort of material would be finding outside projects to work on to keep up with new technology (assuming your job doesn't take care of this for you). Consulting work, technical reviews of books, studying for certification exams, open source projects, etc. The trick is finding the time!

[Warren Dew]

Max Habibi:

The hard part, in my experience, has been getting people to manage themselves.

Ah. Difference in philosophy here. The model I work by is that the developers are hired to write code, not to manage. It's the manager's job to do the managing - that's what she's paid for.

You're asking for everyone to be, not only a competent coder, but also a competent manager. I think that's too large a set of skills to expect in the first couple of years. Heck, I think it's lucky if someone gets there in ten years, even with the best books in the world.


WD:I could go for a book on how to fix the kind of code Fred had to deal with, instead of how to avoid writing it....


MH: There are millions of books, exactly on that topic out there, and some are excellent.

On the topic of fixing other peoples' bad code? Can you mention a few? I've not seen any books that describe techniques for this - for example, identifying what things it's likely to be safe to change, while preserving as much of the existing code as possible because it at least kind of works and you don't have time to clean it all up.

We need books that teach the values of curiosity, generosity, concentration, and the down-to-earth practicality of everyday niceness.

As long as it's balanced by firmness. I've seen teams that were crippled because they had too nice a culture, because it resulted in their tolerating terrible code and terrible coders who prevented anyone else from making forward progress.

Fred Rosenberger:

What's the best way to learn what i should be learning?

To tell the truth, the best way is to look at the more experienced and better respected programmers - hopefully there are some - and figure out what they are doing. That generally involves a lot of questions and a lot of study of other peoples' good code. Unfortunately, it can't easily be encapsulated into a book.

[Max Habibi]

WD:
the developers are hired to write code, not to manage. It's the manager's job to do the managing - that's what she's paid for.


MH:This might very well be a difference in philosophy. I expect my developers to be able to manage their own time, and not need micro management.

WD:
You're asking for everyone to be, not only a competent coder, but also a competent manager.


MH:I believe you're mistaken, or possibly thinking about a different post by someone else. I would like to have everyone be a competent employee, in addison to being a competent developer. Books that help people do that are very valuable.

WD:
I think that's too large a set of skills to expect in the first couple of years. Heck, I think it's lucky if someone gets there in ten years, even with the best books in the world.


MH:I think a good manager can help mentor these sorts of skills fairly quickly. However, we're not talking about quick-fixes here. A career is a lifelong endeavor, and should be invested in accordingly.

WD:

On the topic of fixing other peoples' bad code? Can you mention a few?


MH:That's actually not what I was talking about. However, the following brief list might be useful if you're looking for recommendations.

Refactoring: Improving the Design of Existing Code, by Martin Fowler

Refactoring Workbook by William C. Wake

Code Complete, Second Edition by Steve McConnell(classic)

Test Driven Development: By Example

Refactoring to Patterns (Addison-Wesley Signature Series) by Joshua Kerievsky

AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J. Brown

Coder to Developer: Tools and Strategies for Delivering Your Software by Mike Gunderloy

Object Oriented Reengineering Patterns by Serge Demeyer,

Software Engineering: A Practitioner's Approach by Roger S Pressman

Expert One-on-One J2EE Design and Development (Programmer to Programmer) by Rod Johnson

WD:
We need books that teach the values of curiosity, generosity, concentration, and the down-to-earth practicality of everyday niceness.

As long as it's balanced by firmness.



MH:This may, again, be a philosophical difference. I've found that firmness is best when people apply it to themselves, as opposed to having it imposed on them. I try to manage accordingly.

[Warren Dew]

Max Habibi:
WD:
the developers are hired to write code, not to manage. It's the manager's job to do the managing - that's what she's paid for.

MH:This might very well be a difference in philosophy. I expect my developers to be able to manage their own time, and not need micro management.

There's a difference between management and micromanagement. Managing the developers' own time, I agree, is micromanagement. Setting things up so the developers can cooperate without stepping on each others' toes - that I consider to be management rather than micromanagement, and primarily the responsibility of the manager rather than the developers.

I think a good manager can help mentor these sorts of skills fairly quickly. However, we're not talking about quick-fixes here. A career is a lifelong endeavor, and should be invested in accordingly.

Kathy talks about the book being bought by new programmers. If the book were targeted at experienced programmers rather than new programmers, I'd have different opinions on what it should include.

WD:
On the topic of fixing other peoples' bad code? Can you mention a few?

MH:That's actually not what I was talking about.

Sorry I misinterpreted, then. You were responding to my comment about Fred's situation, which was about fixing other peoples' bad code, so I thought you were saying there were millions of books about that situation - fixing other peoples' bad code.

However, the following brief list might be useful if you're looking for recommendations.

I've read a couple of the books on that list, and they're not actually what I'm talking about. They are about rewriting/refactoring code that's bad, or about writing better code in the first place. I've found that usually one only has that luxury with one's own code. When dealing with a, usually very large, legacy code base, one normally doesn't have the time to clean up the whole thing, and the most important skill is identifying what bad code can be allowed to live for a while without being changed, which those books don't address.

The Demeyer book has a hopeful title, though; I haven't read that one.

WD:
We need books that teach the values of curiosity, generosity, concentration, and the down-to-earth practicality of everyday niceness.

As long as it's balanced by firmness.

MH:This may, again, be a philosophical difference. I've found that firmness is best when people apply it to themselves, as opposed to having it imposed on them. I try to manage accordingly.

Are you talking about the developers, or the managers? I'm talking about the developers (again, if the thread were a book for managers, I'd have different comments). Developers who are nice to other developers but not firm end up giving in and doing things the other developers' way even when it's a bad idea, resulting in code that doesn't work. Thus, developers need firmness as well as nicenes when dealing with other developers.

If it gets to the point of developers "imposing" stuff on each other, I'd agree thats a bad situation and the manager should probably step in to help the developers work things out peacefully.
[ August 27, 2004: Message edited by: Warren Dew ]

[Max Habibi]

WD:
the developers are hired to write code, not to manage. It's the manager's job to do the managing - that's what she's paid for.

MH:This might very well be a difference in philosophy. I expect my developers to be able to manage their own time, and not need micro management.

There's a difference between management and micromanagement. Managing the developers' own time, I agree, is micromanagement. Setting things up so the developers can cooperate without stepping on each others' toes - that I consider to be management rather than micromanagement, and primarily the responsibility of the manager rather than the developers.



MH:We seem to be losing focus of the sub-thread here. I was replying to your point about coders only writing code: personally, that not all they're responsible for( at least, when they work for me). I expect them to pull together, manage their time, get along with the team, and be productive. It's actually not much to ask.


I think a good manager can help mentor these sorts of skills fairly quickly. However, we're not talking about quick-fixes here. A career is a lifelong endeavor, and should be invested in accordingly.

Kathy talks about the book being bought by new programmers. If the book were targeted at experienced programmers rather than new programmers, I'd have different opinions on what it should include.



MH:I think there's some confusion here: Kathy was talking about soft skills in the software biz. Then, she talked about newer programmers maybe not being attracted to books that teach those skills. That does not mean that the book would be solely targeted to newer programmers. Either way, this process( of professionalism), is one of the major milestones in gaining the sort experience you're talking about.

WD:
On the topic of fixing other peoples' bad code? Can you mention a few?

MH:That's actually not what I was talking about.

Sorry I misinterpreted, then. You were responding to my comment about Fred's situation, which was about fixing other peoples' bad code, so I thought you were saying there were millions of books about that situation - fixing other peoples' bad code.

[/QB]

MH:Ah. I actually couldn't quite follow what you meant, which is why I stated the assumption I was working under: I assume you meant writing bad code. There are many, many books that teach you how to do that.



I've read a couple of the books on that list, and they're not actually what I'm talking about.



MH:I believe you were talking about the topic of fixing other peoples' bad code?

They are about rewriting/refactoring code that's bad, or about writing better code in the first place. I've found that usually one only has that luxury with one's own code. When dealing with a, usually very large, legacy code base, one normally doesn't have the time to clean up the whole thing, and the most important skill is identifying what bad code can be allowed to live for a while without being changed, which those books don't address.



MH:Actually, that sort of refactoring advice is exactly what you'll in a lot of those books.

The Demeyer book has a hopeful title, though; I haven't read that one.

WD:
We need books that teach the values of curiosity, generosity, concentration, and the down-to-earth practicality of everyday niceness.

As long as it's balanced by firmness.

MH:This may, again, be a philosophical difference. I've found that firmness is best when people apply it to themselves, as opposed to having it imposed on them. I try to manage accordingly.

Are you talking about the developers, or the managers?


MH:I'm following your thread of discussion, which was dealing with the manager's responsibilities. I'm an advocate of the teach-the-man-to-fish approach of management.

WD:
I'm talking about the developers (again, if the thread were a book for managers, I'd have different comments). Developers who are nice to other developers but not firm end up giving in and doing things the other developers' way even when it's a bad idea, resulting in code that doesn't work. Thus, developers need firmness as well as niceness when dealing with other developers.



MH:I've found that a Developer can't really go wrong by being helpful: worry about it like worry about working out, because you don't want to get 'too big': it's a problem most people should aspire to .

IMO, helping your fellow programmers is good for your professional image, it's good for your knowledge-base( you'll learn more about what your peers are dealing with), it gets noticed by management, and it's good for your Karma. Of course, most anything done to excess is a bad idea, by definition.

best regards,
M

[Warren Dew]

Max Habibi:

I've found that a Developer can't really go wrong by being helpful

It suddenly dawns on me why we've been talking past each other. Correct me if I'm wrong, but it looks like you've been using "nice" as a synonym for "helpful". I, on the other hand, see "nice" and "helpful" as nearly orthogonal concepts.

I agree that it's hard for a developer to go wrong by being more helpful.

[Max Habibi]

Originally posted by Warren Dew:
Max Habibi:

I've found that a Developer can't really go wrong by being helpful

It suddenly dawns on me why we've been talking past each other. Correct me if I'm wrong, but it looks like you've been using "nice" as a synonym for "helpful". I, on the other hand, see "nice" and "helpful" as nearly orthogonal concepts.

I agree that it's hard for a developer to go wrong by being more helpful.

Yes, you're right. I see 'Nice' and 'helpful' as synonyms. It was nice of you to clear that up

[Mapraputa Is]

Warren: It suddenly dawns on me why we've been talking past each other. Correct me if I'm wrong, but it looks like you've been using "nice" as a synonym for "helpful". I, on the other hand, see "nice" and "helpful" as nearly orthogonal concepts.

I love when these things happen. Amazing.

I am with Warren here, I am yet to find a book that would help to deal with somebody else's code, not my own. Maybe the topic is too frustrating to give a birth to anything good... The first thing to teach would be how to respect your colleague. Too many times I was thinking "what idiot wrote this???" and re-wrote the whole thing, only to discover that I have no clue about all the complexities that made the previous guy's program so ugly, and finally my own code ended up much uglier.

[Ray Muirhead]

It seems to me that most people don't really need a book on people skills in software development specifically, but just a book simply on how to be a better person and how to deal with people in a happy way when it would be so easy to say any number of things that you know are not really helping anyone, most especially yourself (of course I have no people skills so what do I know ). In a world like this, everyone just doesn't get taught that and if you don't make an intense effort to learn you usually find yourself caught up in whatever is going on around you.

Dale Carnegie's classic "How to Win Friends and Influence People" is a great book and I'd recommend it to anyone for people skills (it's inspired me many times to be nicer to people, not just to get by, but jsut to see the light on their face when they smile). I've been having a bad day and not felt too great myself, which usually makes me not that fun to be around, and people talking to me on the phone (might be a little different face to face ) have commented that I was a pleasure to speak to, not becuase there is anything special about me, but becuase I *listened* to them. Simplest principle known to womankind and it's worked for me time after time. And I have no people skills .

I know I went a little off topic there, sorry about that. Most of this still applies to the software development world.

[ August 31, 2004: Message edited by: Ray Muirhead ]
[ August 31, 2004: Message edited by: Ray Muirhead ]

[Kishore Dandu]

one very important aspect that needs to be addressed:
"the attitude of a developer/programmer/senior programmer".

They need to perform well in the present job to get promoted or get a better job in a different place. There should not be "I will do it better if I get payed more or promoted or get a new job", same attitude will resurface after couple of months in the new setup(if at all a new setup takes place).

One fine example is some colleagues I have seen in my recent jobs. They will say things like "I will learn new stuff after I move to new job after getting green card", that is one sure way to oblivion.

[fred rosenberger]

OHH!!! I just thought of another possible topic... how about something on working with NON-PROGRAMMERS???

Sometimes it's very hard talking to the testers or the documentation people. Even though (in my office) we all speak english, we often have difficulties communicating. It seems we all assume the others know what we're talking about, but there's always some missing piece.

And the help desk - i don't know how often i've gotten logs saying "it's broke". no details on what the problem is, how to duplicate it, what OS/version the site is on... I'm sure that i've sent logs back to them without enough info for them to test it.

My final current new thought deals with the programmers place in the design of a product. My company writes software for libraries. We employ many Librarians (as in people with Masters in Library Science) who are our product co-ordinators. Personally, i get upset when i hear a programmer telling the librarian that "thats not how the software does/should/will work".

Isn't my job, as a programmer, to make the software do what they tell me it should do? Sure, i get to decide HOW it does it behind the scenes, but for a programmer to say "no - it doesn't need to do that" seems wrong to me.

[white aura]

Hi Kathy,

just to toss in my 2 cents...

I'm a release engineer and I often find configuration management an area which teammembers scratch there heads. I'm amazed how fast QA testers, developers and even project managers run away from me when I mention this at the water cooler.

I look into there eyes and see "fear&curiosity" and "uh-oh, I better run! I don't know anything about this topic. If I'll just pretend that I do.

I'm not sure why version control, branching, build/release processes are such an unknown or repellent when it comes to software engineering. My guess is that there aren't enough (good) books that involve this aspect!!

I've read sommerville's software engineer book. I do find it strange that he briefly mentions its importance and then proceeds not to mention it.

Configuration management, the world of scm tools, and the release management process... what is that? why do I need to lock my files during check-out, why do we need to conform to the RE's build system, can't we all have our own build environment... sigh...