"So what about by-when commitments to clients, or other external deadlines? Sometimes you do have to make a by-when commitment and manage to it, though there’s much to be gained by making that the exception, not the rule. And even when it feels normal and needed, there are often other options. As I’d say to my clients when I ran a software development contracting company: Do you want me to promise you a date that we both know is a lie, and surprise you shortly before that date with an unexpected change which you’re then at the mercy of? Or do you want me to give you so much day-to-day transparency and control that you don’t have to trust me, because you’ll see exactly where we are and where we’re headed at every moment, and be able to influence the project’s direction throughout? Most clients chose the latter, and we had the organizational processes in place to support it."

"Often, taxonomy and nomenclature is given a back seat to visual design. Although visual design is very important, it’s not as important as creating the proper taxonomy and nomenclature."

"Process is being created not as means of control; it’s being built as documentation of culture and values…Imagine all process as a means of capturing and documenting culture and values. Unfortunately, in a larger company, it doesn’t work that way. Even if qualified cultural bellwethers took the time to document their pain and to write a process, these folks eventually leave. When they leave so does their cultural context, and the root pain that defined the process leaves with them. The company forgets the stories of how we ended up with all these bulleted lists, and when someone asks why, no one knows the story."

"What I mean is that delivery dates are hard to estimate because there are a lot of unpredictable factors that affect it. You might say something is due in two days then hit a snag that takes a week to fix. The state, or progress, is often easier to determine and perhaps more useful. It’s easier to say something is being tested (i.e. in the “Testing” list) than it is to say exactly when it will be released."

"

thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.

I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.

"

"Pushback: Everyone should know why they’re doing something. I’ll never forget when I asked a colleague at Showtime for some quick data analysis. When I asked him the next day where it was and he told me he needed another day I realized *I* screwed up by not telling him I only wanted the info if he could do it in 10 minutes. Everyone should be encouraged to say, why, how long should I spend, what should I not do instead and are you sure it’s worth the effort? While this was about saving some time, this simple concept now makes our company more transparent and productive at every turn – whether for little tasks or big strategic issues."

"In terms of knowledge workers, a programmer produces more good code and fewer bugs when well-rested. We take the first hour or so of the day getting into the groove. The next few hours tend to be our best ones. Later in the day, as we get tired, we get less done per hour — it takes a long time to fix a simple bug or add a simple feature that we would have handled in minutes earlier in the day. Pushed just a little farther — and it seems that much of the computer entertainment industry is working at this extreme most of the time — an overtired IT worker may trash valuable files requiring extra work to restore backups or have an accident on the way home that takes her offline for months."

"People also want all the features they can handle. If you’re competing with a product that is overwhelmingly complex, then simplicity sells. Otherwise simplicity is perceived as weakness. The more features the better. People may enjoy using simpler products, but they buy complex ones."