BOOK: Making Things Happen

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_making_things_happen.htm]

I got to finish reading another good book: Making Things Happen: Mastering Project Management, by Scott Berkun. Scott worked for 10 years at Microsoft, which included projects on IE, MSN, and Windows. The book is practical and engaging - definitely not one of these ivory-tower things that bore you to death. All the book drawings also look like sketches on the back of a napkin - no MS Visio here.

Perhaps what I find interesting about it is that so many developers think that the only thing they really need is super technical knowledge - "If I'm just brilliant, then everyone will recognize my brilliance, and life will be good." This is simply not true - there are non-technical factors that can kill projects and careers: people skills, politics, bad management, etc... My entire software career, I've seen people significantly smarter than myself who crash and burn because, although they got the tech skills, they are clueless about how to convert those tech skills to "make things happen".

Scott divides his book into three main parts:

1. Plans
2. Skills
3. Management

Amongst those three main categories, he covers a broad spectrum of vital, yet non-technical skills, such as figuring out what to do, making good decisions, how not to annoy people, what to do when things go wrong, and actually getting things to happen.

Some quotes I liked:

• "failures force us to pay attention." (pg. 5)
• [about schedules] "attempting to predict the future - something our species rarely does well." (pg. 31)
• "The more change that is expected, the shorter the milestones should be." (pg. 39)
• "Volume should never be confused with quality. Unfortunately, because volume is easier to produce than quality..." (pg. 79)
• "innovative work often occurs when one person has both requirements and design authority" (pg. 94)
• "programmers tend not to be interested in writing things that don't compile." (pg. 140)
• "If I can't come up with more than one choice, I clearly don't understand the problem well enough: there are always alternatives." (pg. 161)
• "For most tough decisions, the problem isn't a lack of data. Tough decisions exist no matter how much information you have." (pg. 167)
• "You have to  be willing to get burned if you want to develop the skill of putting out fires." (pg. 222)
• "if you can't say no, you can't manage." (pg. 265)
• "As a rule, the further a team gets from reality, the harder it is to make good things happen." (pg. 267)

Tips to be a good code-reviewer

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/tips_to_be_a_good_codereviewer.htm]

Code reviews are essential to high-quality code. Imagine back in high school when you're taking a difficult math test, and then in the last few minutes, the teacher lets you pair up with another student to compare your answers. You almost always will catch extra errors that way, and it's the exact same result with a code review. So, given that we all know that we should do some sort of code review, here are ideas on how to be a good code reviewer:

• Always keep in mind that the other person worked hard on it, and they probably have an emotional attachment. Someone once said something like "Their code is like their baby - don't say 'he looks so ugly', rather make a nice comment like 'Oh, he looks just like his father.' "
• Start with major things first. Don't start nit-picking ("your naming convention isn't good"), if they have major other issues. Focus on their biggest need. If they want your opinion on the data access strategy, that's what they'll be most receptive too.
• Don't just be a rubber stamp - it wastes their time by giving them a false sense of security and tells them nothing new.
• Look to affirm good ideas as well as discourage bad ones.
• Unless they are really missing the basic concepts, don't just tell them to go read some 500 page book - they'll see it as you dismissing them. Give them a tangible example and perhaps provide a web link to a short article or reference guide. If they read that (or they ask for more material), then suggest the books.
• Keep the session relatively short, short enough to fit within their attention span.
• Keep in mind the goal is to make better code for the good of the team, not show off how smart you are.

Why code generate something after it is already written?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_code_generate_something_after_it_is_already_written.htm]

If you've already written something, why go back and code-gen it? There could be a couple reasons:

• You're going to write a lot more of it, so you might as well leverage code-gen for all that existing code.
• You need to extend it with more functionality. Sure, the current stuff is already written, but you need to add new (tedious) features, like recording which properties of a class have had their setters called.
• You want to make it easier to maintain. Manually-maintained code counts as technical debt. Such code grows, get copied into off-by-one, and gradually gets customized. By code-generating it now, you'll make maintenance easier in the future.
• You want to document the rules. As codeGen essentially acts as documentation, this will give you a place to clearly define all those boundary cases.
• The code is already easy to generate. If the code is already prepared to be generated, might as well go ahead and migrate it.

Preparing your code to be code-generated

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/preparing_your_code_to_be_codegenerated.htm]

Sometimes you're not sure if something should be code-generated. If you do end up code-generating it in the future, there are several guidelines you can follow to make your life easier:

• Physically place the code in separate files. One of the hardest things to do with code-gen is to merge generated and custom code. By isolated the potential code in its own file, you'll spare yourself this pain.
• Standardize and simplify your code. For example, if you prefix all variables with Hungarian notation, your code-generator would need to do extra work to determine what that prefix is.
• Refactor as much as possible first. The less unique code you have, the easier it will be. there's also a good balance between code-generation and refactoring.
• Document the rules. If you're writing code based off a set of rules, document those rules - they'll come in handy as you try to generate the edge cases.

 

R6034 - An application has made an attempt to load the C runtime library incorrectly

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/r6034__an_application_has_made_an_attempt_to_load_the_c_run.htm]

A coworker recently got this error when trying to open a web application project within Visual Studio 2008:

Runtime Error!

Program: C:\Prog...

R6034

An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information.

Note that in this case, (1) Visual Studio opened just fine, (2) the problem was in merely loading a web project, and (3) nothing was even being compiled yet.

It turned out the problem was likely from a corrupt uninstall of the .Net 3.5 SP1. By re-installing the SP, things began to work again.

NOTE: .Net 3.5 SP1 has a potential error with the web dlls, so you may need to make some tweaks to the GAC.

Silverlight Tour in Chicago

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/silverlight_tour_in_chicago.htm]

For those interested in Silverlight, there is a Silverlight tour that will be offering classes in Chicago. You can find more details at: http://silverlight-tour.com/. I'm told that this is the first training that is teaching Silverlight 3. While this is not a free event, it may be well worth the cost if you're a Silverlight fan.

Hat tip from Shawn Wildermuth.

Is unit testing a second class citizen?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/is_unit_testing_a_second_class_citizen.htm]

Especially with the successful track record of unit tests, no project wants to be caught rejecting the notion of "unit testing your software". However, for many projects, unit testing seems like a second-class citizen. Sure, people speak the buzzwords, but they don't actually believe it, hence they diminish unit tests as some secondary thing unworthy of time or resources, as opposed to "real code".

1. Will developers actually spend time writing unit tests while they develop a feature (not just as an afterthought)?
2. Will developers (including architects) design their code such that it's conducive to unit testing?
3. Will a broken test get a manager's attention, or is it just some nuance to be worked around?
4. When a business logic bug is found, is there enough of an infrastructure such that you could write a unit test to catch it (the test initially fails because the code is broken, then passes once you fix the bug)?
5. Will developers invest mental energy in learning to write better tests, such as reading blogs or books on testing, or experimenting with better testing techniques?
6. Will developers write unit tests even when no-one's looking, or is it just some "tax" to appease an architect or manager?
7. Will management support the hardware for it, like having an external build server with the right software (while NUnit is free, MSTest still requires a VS license)?
8. Will a broken unit test cause the build to fail?
9. During code reviews, will other devs review your unit tests, similar to how a QA person reviews functionality?
10. Do your amount of unit tests increase as the rest of the project grows?
11. Is the team concerned with code coverage?