Fog Creek Software
Discussion Board




Code Complete and Industry

I am a CS student and I am reading CC right now.  Everything so far seems every educational, except annoying Pascal Code ( I like C++ better).

I like to know how relevant is the book in real life situation?  As I am doing my internship for a company which none of CC suggestions applies, I am begginning to think it is now more academic.  Should I apply CC stuffs when I am coding for the school assignments, although most of the assignments are garbage once the course is over.

How many software companies really follow CC guidelines anyway?

Ray
Monday, March 25, 2002

Ray,

Welcome to the Joel on Software Forum... Mwa ha ha!.

Seriously though, a lot of the folks here have excellent real-life experience and are good at seperating wheat from chaff. You should listen to them.

I have nothing else helpful to add to this thread. =)

Mark W
Monday, March 25, 2002

It is useful for all sorts of coding jobs.  But maybe it is better to read after you've been coding a while.  After all, what matters now are tactical things like algorithms and translating the problem-space into sane structures.

Despite all the texts on the subject, many companies simply don't follow the simplest precepts of software eng.  Some vaguely realize that a CVS-type system is useful, but consider it "short term overhead."  Stone-age people.

BTW, I thought of Code Complete as anything but academic.  Purely pragmatic.

Greg Neumann
Monday, March 25, 2002

Code Complete is an AWESOME book. You should definitely read and apply it to your own work. Even if it feels like "overengineering" for your school projects, it is still a great way to build good habits before its too late.  ;-)

When you say that none of the Code Complete suggestions apply to your current internship, do you mean that the company has crappy code? Or that the type of project is not mentioned in the book?

Most often, people do not like to be told how to do things (especially by the new guy or the intern), so you will likely not be able to change the world on this project. However, you can still quietly preach "The Word" and apply Code Complete's lessons to your work. With luck, your good code techniques will "infect" other parts of the project.  <:-)

Another "real world" book that I like is Steve Maguire's Writing Solid Code. This book is a more C oriented and not as important as Code Complete. However, many people find this book controversial because they think it overemphasizes the ASSERT() macro and leads to lazy programmers who don't write proper error-handling code. So take the book's advice with a grain of salt, but I think ASSERTs (when used correctly) are wonderful.

Banana Fred
Monday, March 25, 2002

I have only gotten part way through Code Complete.  Most of what I have seen is sensible practical stuff that I have already learned through experience.

But you could take applying CC to extremes.  The book has long lists of things to check for, say, what goes in a function.  If you applied it in detail, you might not ever get anything done.  You need to learn basic principles from it and not just write code until it compiles and gives results that look right.

Are you sure your company doesn't apply any of the concepts in CC, at least implicitly?

mackinac
Monday, March 25, 2002

Ray, I recommend reading it.

I think some may recommend against it, claiming it to be too dated. However, as Greg mentions in his posting above, it is absolutely beyond belief the number of companies that seem to make it their mission in life to do as many things wrong in their operations--not just with software development--as possible. From a developer's standpoint, it may be that some specific techniques in CC may be out of date, but at a macro level at least, the basic ideas of the prerequisites (ch3) cost of finding a defect (table 3-1), acknowledging that change will occur and making sure you provide for that eventuality, etc. are all still valuable principles to keep in mind.

Oh yeah - and the figure about communication and size in sec 21-2 showing the interconnections among programmers. McConnell only refers to programmers there, but if one of those nodes in the diagrams is not your QA guy, then you're dooming the project to trouble from the start.

As a QA manager of a number of years, I've a lengthy list of horror stories. Probably nothing others posting here haven't seen one place or another. My observations might only be interesting because I'm looking at the results of mistakes from a different point of view than many of the developers who contribute here are. A great many of those horror stories could have been avoided had the practices of CC been more widely practiced, IMO.

I recall a company so messed up I struggled to find a phrase to communicate to the senior management (I was a Director and owned the QA dept as well as about 4-5 other depts, so I was talking to VP, SVPs, COO, etc.) just how bad operations were. I ended up telling them something like we were "doomed to continue to fail" to deliver anything like a quality product in anything like an efficient manner. Didn't have any effect. Well, I don't work for them anymore, so maybe it did, afterall!

So, welcome to software development -- gonna be a fun ride! As you go from one shop to another in your career, you'll experience varying degrees of pain/pleasure from your profession. Watching the organizations you'll be in, though, should always be fairly entertaining - note the endlessly rich amount of "fuel" Scott Adams found along the way!

Just because a huge number of organizations do not pay attention to CC, other excellent books, and most importantly, the professional judgement of their staff who actually know what will/won't fail, does not make those sources wrong. Just frustrated. Remember, almost 400 years ago Galileo Galilei was correct. He was persecuted for it, so he lost the battle, but ultimately won the war because reality showed he was correct. The majority(or most powerful) voice is often the loudest--doesn't mean it's correct.

Finally, last $0.02 worth - studying hard-core analysis, as in systems analysis (e.g. Operations Research/Systems Analysis) is a good supplemental area for software engineering. I have an engineering degree in another field, did graduate work in OR/SA, then a stint as a professional analyst for the US Army (when I was still in green). The senior architect/developer in my current shop got his CS undergrad and then his graduate work in OR/SA as well. He and I are nearly completely in synch regarding the importance of many of these "good practices" with respect to software development because we both are used to thinking holistically about systems, whether it's our own development process or a system we're developing. Might want to keep OR in mind when picking electives.

Good Luck, once again.

F.J. Weiland
Monday, March 25, 2002

> I like to know how relevant is the book in real life situation?

It's relevent in the sense that I've work with real live code, where I wish that it better followed many of the excellent prescriptions found in CC.

And it's irrelevent only in the sense that much of that code has now dropped by the wayside.

Maybe the real-life people that you work with can teach you excellent coding standards, in which case perhaps you can do without the book. Otherwise, it's nice (I'm thankful) that someone "wrote the book" about it. It's the best, pretty well the only language-neutral code construction book I've seen (by language-neutral, I mean that you'll find other books to teach you about OOP etc.). Perhaps it's the only book because everyone has read it and no-one can write a better.

> How many software companies really follow CC guidelines anyway?

Who can say?

I've read it, and I keep it in mind when I do code reviews. In the past, I've stopped reviewing everything that a person writes when they stop writing bugs. So far as I know, about half of the people who are still working here have read it (read one of the copies of it); maybe others have too. Not because the CEO or director tells us to, you understand, but because it's part of what we need to do *our* job correctly. It's one of those books that I wish I had never read, so that I could enjoy reading it again for the first time.

Seeking a more objective (less enthusiastically whole-hearted) opinion on this subject, I've just all read the reviews of this book on amazon.com which DON'T give it 'five stars' (a small minority ... the rest say "awesome, excellent, best, useful, 10 stars, bible, must-have, if you only get one get this one, etc). The negative comments summarize as:

- Dated (PASCAL) ... needs an overhaul

- Not OOP

- Size (too large), verbose, repetitious

- Dry style <well, I didn't think so>

- Only read it if you have no industry experience; only for freshmen, CS seniors will know it all (except about 100 pages of it) already

- Fluff, it's all theory and abstract suggestions

- Too many statistics, not enough VB, not enough C

HTH

Christopher Wells
Monday, March 25, 2002

I find the book of little use, pedantic at times and a dull read these days. But thats because I know the book well, respect what it says and have adopted many of its viewpoints. I occasionaly refer to it, maybe once or twice a year. Theres better stuff around.

All developers should read it once I think. Good developers do much of what it preaches anyway.

Jack
Monday, March 25, 2002

Sometimes, in the real world, management tells you some code is due in a day, and you sometimes can rush , & hardcode stuff, and end up with code that is not ideal.  Maybe it's just me, but I'm just saying this can hapen sometimes.  It's hard to be elegant, when they want somethg slapped in immeidately.  this is a combination of poor mgmt and poor coder or the nature of the business you are coding for.

Bella
Monday, March 25, 2002

I really appreciate all comments.  There are some clarification to my original post.

1.  The firm, I am currently working for, completely disregard 99% of software engineering concepts.
ie
a. little or no docs,
b. testing = run a handful of cases = testing bugs
c. comments in code is considered a waste of time and making source files bigger
d. today fix = tomorrow bug
e. Most functions has 200-3 thousands lines of code.  BUT EVERYTHING SEEMS TO WORK.  UNBELIEVEABLE.

One wonderful thing I can say is Indentence is strictly inforced.

ray
Tuesday, March 26, 2002

For me, reading Code Complete was what got me started in professional programming. This may sound funny, but programming had been "playing around" for me most of the time and I always feared that doing it professionally would take the fun part out of it. I cannot say why Code Complete convinced me that this does not have to be the case, maybe because in Code Complete it sounds rather simple to produce good code. And Code Complete was fun to read (jm2c).

I always have my copy on my desk when I work, even though I do not use it to look things up or the like. It has become more of a good luck charme to me, or the proof that there is common sense out there somewhere. It kind of keeps me sane when my job tries to drive me crazy.

Sorry, this was all a very emotional and personal statement, but I _really_ liked that book when I read it.

Have fun,

Jutta Jordans
Tuesday, March 26, 2002

Ray, may I make some guesses about the
organisation you are working for?
It's small, only five or so developers. All
the developers are really bright and know their domain really well. The people who wrote the code are still with the company.

If so, then the most likely explanation is
that all the knowledge that should be in documentation, comments and testing is actually inside the developers heads.
They can all design and fix really easily
because they know so much about the code it comes as second nature.

If so, this can actually be very efficient
while the situation lasts. Of course it will start to come apart when the development team starts to grow, or the original writers move on. Then the code becomes much harder to maintain, and the original coders won't understand why, because it still seems obvious to them.

Or, of course, I may be completely wrong.

David Clayworth
Tuesday, March 26, 2002

David, I'd say you are right.

We call them cowboys.

Jack
Wednesday, March 27, 2002

Oh, and they are useless.

Jack
Wednesday, March 27, 2002

*  Recent Topics

*  Fog Creek Home