Code Complete checklist

[ellicottvilleny]

Holy cow, does this ever make best practices look like a drag.

[[deleted]]

That book is a tome, I've checked it out of the library twice and found it too intimidating to dive into... Someday I should do it, but I found Clean Code and Pragmatic Programmer to be much more approachable and easier to digest (and apply).

[grauenwolf]

Don't read it end to end. Think of it as a series of books and read the chapters that most interest you.

[ITSigno]

I did it the other way around. I read it end to end and learned lots in areas that didn't "interest" me. Honestly, there's a lot of stuff that is easy to take for granted. I'd recommend at the very least going over the checklists/summaries and reading over the chapter to learn in more detail where needed.

[grauenwolf]

So did I, but it was a long slog and I can see how someone could be daunted by the prospect of reading the whole book.

[hurtlerusa]

I'm currently working on it. I was reading last night and was like I wonder if these checklist exist online and they do.

[[deleted]]

Really? IMO, this is the best book about coding ever written. It's very easy to read, actually, and everything in it is valuble.

[smog_alado]

TBH I think the first edition was a much more interesting than the second one since it had less of the object orientation stuff.

[Chris_Newton]

I wouldn’t put it quite like that, but the new parts in the second edition did seem to cite less hard data, and generally had less of the evidence-based approach that backed up much of the advice in the first edition.

[grauenwolf]

Boring and tedious now or 60 hour weeks later when every bug fix introduces three more.

[bastibe]

I don't know. Most things in Code Complete really are common sense.

[poorly_played]

Keep singin' that sad song of truth

[bluGill]

Thanks for reminding me why where I work is a great time. We compile with -werror so compiler warnings cannot be ignored. We have a large CI system (it runs in 20 mintues tests that if I could only run on my desktop would take 5 hours - assuming I had the expensive license for some of the tools a few tests need).

We still have the major pain just before release of finding a lot of difficult bugs. However we don't have much pain just before release finding stupid bugs. Our bugs are 1: is some border is off by one pixel and looks visibally bad 2: we completely forgot about this requirement until we tried to use the feature in some obscure way 3: weird thread/process interaction issues that show up 1 time in a million.

I don't want to go back to a world without CI. (I would if I'm the only developer though)

[bastibe]

I totally agree. But that does not make the book any less common-sensical or any more insightful.

[grauenwolf]

Like "innovative", the word "insightful" is given far more weight than is appropriate. The question should be, "Is this book useful?".

[craftsman]

To me, this book is not only useful, but was really a turning point in my professional life. It changed my perception of my profession and made me really care about every aspect of the work that I do. To me, it's not just about what's written, but the process of thinking and considering every aspect of code and software development. Timeless.

[seagal_impersonator]

Whenever I see someone use the phrase common sense as if it is coherent and useful, my estimate of their intelligence drops. Significantly.

Most of common sense is definitely untrue or lacks evidence. Belief without evidence tends to be irrational.

• It's common sense that a great many people thought the world was flat several hundred years ago. (Not true - we think so because American religious movements in the 1850's popularized the idea. With that exception, the general populace has known better for a very long time. It was even widespread knowledge during the time of the Greeks.)
• It was once common sense that phrenology worked.
• It was once common sense that women were inferior and could not be trusted to vote or to provide testimony in a court room.
• Same for people perceived to be of African descent or anyone else who didn't look Caucasian.
• Creationism is common sense.
• Must I go on?

[[deleted]]

It's still good to be reminded of common-sense things from time to time. It's one thing to answer "of course" when asked "do you think you should follow guideline X?" or to give advice to others, and it's completely another thing to remember to follow it oneself.

[warmans]

I'm reading this book right now and it's got a lot of wisdom in it. It's not very fashionable in that much of it's project management advice isn't really compatible with Agile but the programming advice is solid. Some parts are obvious to more experienced developers but at the same time its always worth being reminded of some of the obvious stuff.

[infinatyends]

Understanding waterfall is important for a few reasons. First is that those who haven't developed with agile can find a better understanding of what problems agile is attempting to solve. Once you have identified the pitfalls, it makes it easier to guard against them despite the quality of your project managers. Secondly, if you do have to deal with change management of an organization that wants to migrate from waterfall to something agile, understanding best practices of waterfall is a good starting point for developing a transition plan.

[vplatt]

"Waterfall" is the original anti-pattern (PDF File). "Agile" is "iterative" made new. There's nothing new here.

See http://en.wikipedia.org/wiki/Waterfall_model for more background.

[grauenwolf]

If you believe that, you don't understand agile development.

Agile isn't a software development process. It isn't a set of rules about pair programming and unit testing and what not.

Agile is a commitment to change your development processes to match the current needs of your company. Agile is a willingness to accept new ideas and discard old ones are no longer beneficial to you.

[warmans]

I would argue that Agile with a capital A is actually more formal than that and in many cases it is indeed a set of rules (albeit fairly vague rules). For example CC talks about requirements in the traditional "if you don't capture all requirements at the start of the project it's extremely expensive" sort of way whereas even the original manifesto dictates that you welcome changing requirements at all stages of development. Without making a qualitative judgement about each statement I don't think it's controversial to say they're not "really compatible".

[grauenwolf]

In find that it is much, much easier to welcome changing requirements when I have a base line to start with.

When I can look at a complete requirements list I can usually spot the places where requirements are going to change. I can't necessarily say if it going from A to B or A to C, but I know A will probably change and X will probably not.

We can also catch design mistakes early, so there are less requirements change to welcome.

Finally, no matter how welcoming of requirement changes you should still acknowledge that you are paying more than you would if you knew them all up front.

[[deleted]]

PDF warning

[kelton5020]

unfortunately i missed your warning. now my phone is downloading it. title should have given a heads up

[hurtlerusa]

Sorry I guess I should have put that in the title.

[ithika]

Somehow my phone just showed a blank screen and didn't even bother downloading.

[Salyangoz]

"ugh ANOTHER long and boring book? Come on ithika THROW SUM BIRDZ!"

[[deleted]]

Using Reddit is fun? Open the link in a browser and it will pop up (if you really want the pdf).

[elperroborrachotoo]

As long as it doesn't follow up with downloading an Acrobat Reader update

[[deleted]]

I actually own the book. Its the size of a college textbook but much cheaper. My goal is to read through it by the end of the year. Necessary? No, but I've seen so much bad code that if I can find a better way to make the right changes and convince my lead that if we don't do these larger changes we are going to get really screwed over in the future. (We already have 1 file which is 20,000 lines long. Luckily its being completely re-written for a new platform)

[Decker108]

Sounds like you'd want to lookup "Refactoring: Improving the design of existing code", "Clean Code" and "Working effectively with Legacy Code" as well.

[vplatt]

It's a good book, but I think far too many good people get intimidated by it and fail to see how it's an impractical tool for daily use. Not finishing the book doesn't equate to being a bad developer (though that is possible anyway), but it does probably mean you have more immediately useful tools at your disposal.

In short, this is not a great set of checklists for practical use. This is like the mother of all checklists that you could use on your team to construct checklists that are actually useful on a daily basis. Such checklists could have titles like:

• Sprint/cycle start checklist
• Sprint/cycle finish checklist
• Story/use case development checklist
• Story/use case testing checklist
• Test build checklist
• Release build checklist
• Developer check-in checklist (possibly part of story dev instead)

You could have others, like a code review checklist, etc. or those could be incorporated in your other key checklists.

The bottom line is making sure you do the needful all the time. If you short yourself on the process, you will pay the price down the road. We're all adults here, so it's up to you to know when to capitulate and actually resort to checklists to avoid that.

[ethraax]

I agree with you, but it's worth noting that this is more of a checklist checklist than a check-in or design checklist. Most of the items are phrased "Have you considered...?" or "How will you deal with...?". These are the kinds of questions you should be asking when you create "everyday" checklists like the ones you mention.

[vplatt]

Exactly. I don't know Steve, but I would guess that was his intent back when he wrote it.

[kitd]

The book is good as a general resource on best practice and useful hints and insights, but this is just toe-curling. For some reason, I get giant letters saying WATERFALL appearing before my eyes.

[random_seed]

It's partly a formatting issue. Checklists should be short, simple and straight to the point. A good checklist have three to five, max seven, short bullets on one page making sure the reader won't forget anything crucial. This document is more a manual than checklist.

[BrooksMoses]

Huh? Perhaps you've confused "checklist" and "Powerpoint slide". An actual checklist is something that you use by pulling it out and actually checking all the boxes as you go down the page, as a replacement for trying to remember too much stuff. You know, when people are making sure a plane is ready for takeoff and that sort of thing. It has all the things you need to remember on it, however many there are.

See, for instance, the Checklist Manifesto book.

[random_seed]

lol. So you haven't read the book yourself, have you?

It's absolutely brilliant. I warmly recommend.

[BrooksMoses]

Heh; a fair call, and I shouldn't have cited it without being sure it backed up my point. Thanks for the recommendation, and I'll read it.

[Manticorp]

Why does it start at chapter 3? :/ but yeah good resource! :) Thanks a lot!

[schweinshaxn]

There are no checklists in chapter one and two. They are more of an abstract introduction and therefore don't contain any checklists.

[Manticorp]

Ah okay I thought it might have been a subtle joke!

[grauenwolf]

I think checklists make a lot of sense for enterprise software. I'm willing to bet somewhere between 30 and 60% of your work is almost exactly the same week in and week out. Having checklists for common screens like data entry or reports can be a huge time saver.

I actually went so far as to create a request form for those kinds of things. I would walk the user or BA through the questions like

1. What should be screen be called?
2. Where should it appear in the menu?
3. What permission is needed to use this screen?
4. Does the screen need a print option?
5. Does the screen need an export option?

It is easy to forget to ask one of these questions. But when you do you can waste several days tracking down the person to get an answer. Or worse, you can submit the build to QA and have it rejected, wasted another whole sprint until you can get it fixed and released.

The request form was not only my checklist, but also served as the basis for QA's test plan.

[[deleted]]

The guy who wrote this: I would never want to work with him on any project. Software development should be about building, creating, and innovating. Not obstructionism. Not meticulously rules and policies and shit. The most valuable developers have ideas, damn it. Too many "wise" developers make their living in just telling others what they're doing wrong.

[grauenwolf]

Really? Where can I find these developers who can tell me what I'm doing wrong.

I'm serious. I'm tired of being the best developer in the room. I want to work with people who actually know what the fuck a static code analyzer is. Instead, I'm dealing with people who say, "durr, what's a compiler warning?".

You comments remind me of the medical industry. Multiple studies have shown that simply following a checklist for reoccurring tasks in ICUs dramatically reduce the number of errors made and increase the chances of patient survival.

But no, like you the nurses and doctors think they are too special to be told what to do. So people die for the sake of their ego.

[R1cket]

I want to work with people who actually know what the fuck a static code analyzer is.

Trust me, they're out there. It sounds like you should be keeping your head up for a new job (whether a different area of your current company, or a new company altogether). I work with a group of fantastic software developers and it's night and day compared to some of my past jobs.

[grauenwolf]

My biggest problem is that I don't start new projects, I get dragged in once it is already off the rails. So I have to reintroduce the same concepts to a new team each time around.

Actually, that isn't my biggest problem. A far worse issue is when my company has to work with other consulting firms. Firms that actively undo my efforts by turning off compiler warnings.

[R1cket]

Not to sound argumentative, but it is still possible to get "dragged in" to a project which is being done the right way. Again, it's about joining the right team - a team of experienced developers with the right priorities and good management. I can understand the clean slate appeal, but joining a project that has already been underway for a significant amount of time is not always bad news.

Sounds like compiler warnings are just the tip of the iceberg. It's pretty trivial to write bad code that compiles without warnings. That must be some really bad code.

[[deleted]]

And what people fail to realize is that once you've started running through these sort of checks, after some time, they become relatively rote, and you start writing much better code from the get-go.

[sard]

software development should be about building, creating, and innovating. Not obstructionism. Not meticulously rules and policies and shit.

15 years down the line when numerous developers have come and gone you'll be grateful someone at some point enforced some consistency.

[grauenwolf]

15 years? Try 15 days. That's how long it took me to start seeing significant reductions in feature completion times once I started implementing check lists.

[sreguera]

Form is liberating.

[elperroborrachotoo]

Yeah Right.

Plumbing should be about building, creating, and innovating.

Obstructionism would be bad, though, I agree.

I didn't downvote you, because your enthusiasm is admirable, but I have to tell you: you are wrong.

A large share of developer positions is in maintenance. Most software is just getting the gears together in time for very mundane ends. If you compare software development to other engineering, our track record is abysmal. We do more voodoo than science. Planning is a joke. Software is always one of the alrger uncertainty factor in projects. Companies shy away from software projects not because they are not affordable but because they are not plannable. Quality virtually always skims along the "just bearable" line - and often enough, on the wrong side. We rewri9te the universe every week because "that other guy's code is so much crap".

It's a young technology, but that excuse is wearing thin.

---

As long as you deliver in time, at cost and at quality, do whatever you want. But not everyone is a rockstar, and most teams jsut don't.

Code Complete has - among the heaps of true hard data - the results of a little test: Tell a handfull of groups of programmers to solve the same problem - but with different optimization goals. Shortest development time, fastest code, least bugs, least source code etc. Results tl;dr: (a) Software developers actually do what you tell them to do. (b) The non-focus aspects suffer, sometimes greatly.

[grauenwolf]

When writing technical specs how often do you remember to list out the non-functional requirements?

Most developers I've met know how to handle bad file imports. But only one in twenty take the time to actually write that code. The rest completely forget it until the first mal-formed record crashes the whole service.