My comments/opinions (not coming from the book) are marked JS. Corrections, additions and comments (to my comments) are welcome. ----------------------------------------------------------------------- Good coders don't usually make good managers. Don't promote a coder to be a program manager. Don't let marketing people be program managers. Don't have coders report to program managers. Building consensus (instead of ordering) results in better products. Choose language for the task, not for its syntax. C strings are bad, Pascal strings are better (JS: String objects even better). Joel Test: 1. Do you use source control? 2. Can you make a build in one step? (all versions including installers) 3. Do you make daily builds? (automatic, at lunchtime, breaker becomes builder) 4. Do you have bug database? 5. Do you fix bugs before writing new code? - It's easier and cheaper to fix early - Bugs are difficult (impossible) to time-estimate (more than new features) - With no bugs, schedule is more reliable - Always ready to ship 6. Do you have an up-to-date schedule? 7. Do you have a spec? 8. Do programmers have quiet working conditions? (15 min to get into flow) 9. Do you use the best tools money can buy? 10. Do you have (enough) testers? (1 tester for 2 programmers) 11. Do new candidates write code during interview? (no trivia or Aha questions) - trivia = what's the difference between CreateDialog and DialogBox - Aha (brain teaser) = questions that seem easy when you know the answer, but impossible if you don't 12. Do you do hallway usability testing? (5 persons will provide 95% of needed feedback) JS: Equilibrium: 4 points = 1, 4, 8, maybe 5 SPECS: - disclaimer - author - scenarios - non-goals - overview - details - open issues - side notes - written by program manager (writing, diplomacy, market awareness, user empathy, UI design) JS: - Some very successful software products (Photoshop) were written without spec - just playing with new technology. - Specs make (only/more) sense if they are reviewed by other groups (QA, Marketing, TechPubs, etc, especially end users). - Specs are easy when you work on known products using known technology (e.g. new version of Excel with VisualStudio), difficult when working on new product, using new technology. - I don't agree with the single author premise - but there should be one maintainer - person responsible for starting it and keeping it current. SCHEDULES: Keep it simple Fine-grained tasks (2-16 hours each) Each task scheduled by the programmer who will code it Keep track of original and current estimate (to learn) Update every day (current estimate and elapsed) Add as tasks: vacation, holidays, debugging, integration, buffer (padding) Don't let managers reduce programmer's estimates Cut features instead of slipping DAILY BUILDS: Use fastest machine money can buy One script checks out and builds all, including installers, uploading to the web, email and html page with results It is on the desktop of the build machine, so anybody can start it by double-clicking Run it automatically at lunchtime or one hour before leaving If daily build is broken, stop everything and fix it Set compiler to maximum warning level Whoever breaks the build, becomes builder (until someone else breaks it) BUGS: Fixing a bug is only important when the value of having the bug fixed exceeds the cost of fixing it (include in cost intangibles like reputation of the company and product and what could you do instead of fixing the bug) Automatic collection of crash dumps Tech Support should provide list of Top Ten Bugs regularly Tech Support should not charge for bug reports Open Source Software sucks on usability (because it's not "fun") and is usually better at cloning existing designs Five software worlds: - shrink-wrap (including open source, web-based and consulting-ware (CRM, CMS)) - internal - embedded - games (more like movies, hits, only one version, imperative to get it right first time) - throwaway Software methodologies (e.g. Agile, XP) are often invented by consultants that only understand "internal" software - many of their postulates don't apply to other types of software (like shrink-wrap) e.g. you cannot do test-driven development when working on GUI app. Software prototypes are a waste - prototype with paper and pencil. Design is a nebulous area where you can add value faster than you add cost. In searching it is more important to sort results than to find more. Unix is for programmers, Windows is for end-users. Red Hat recommends Windows for consumers (Munir Kotadia - Red Hat CEO) In shrink-wrapped and consumer software quality is a competitive advantage - it may be worth fixing the last 10% even if it takes 90% of the time/cost - automated crash reporting helps Ignore bugs that happened only once. Hiring: - throw away resumes with errors - select people who went to good schools, worked for good companies - phone interview: how would you write an XML parser - in-person interview: - min 6 people should talk to each candidate (including 5 peers) - 1 hour per person (interviewee) - maximum 1 "Don't hire" (of 6), maybe 0 if the 1 is from a senior person - end interview after 2 failures - don't tell them in advance how many people they will be talking to - hire only superstars (who write lisp compilers for fun in a weekend, in assembler for Palm Pilot) (???) - hire people who are: - smart - get things done - hire people with aptitude, not a skill set (any skill set will be obsolete in a couple of years) - don't blab - don't ask trivia questions - let them talk (and show how smart they are), give open-ended questions and problems - how they go about solving the problem, not the actual answer - look for passion - can they explain things in terms that normal person would understand? (???) 1. Introduction 2. Recent Project Question 3. Impossible Question (how they react?) 4. Programming Question (no more than 10 lines of code) - reverse string in place - reverse linked list - count set bits in a byte - binary search - find longest run in a string - atoi - itoa 5. What would you improve (in the above)? 6. Do you have any questions? Incentives are harmful: - people who work for rewards do not perform as well those who expect no reward at all - incentive bonuses are bad - treating smart employees like kids (with plaques and employee of the month programs) is insulting and demeaning - performance reviews are evil (most people are disappointed and depressed) = teamicide - if you have to give performance reviews, just give everyone a gushing review (to prevent teamicide, depression, low morale and resignations) Human task switching is harmful - in programming, task switching takes a long time - never let people work on more than one thing at once - make sure they know what it is - good managers see their responsibility as removing obstacles so people can focus on one thing and get it done Rewriting code from scratch is the single worst strategic mistake that a software company can make. It is harder to read code than to write it - old code always looks bad - programmers want to throw it away and start from scratch Customers don't know what they want. Stop expecting that. _You_ have to do the research and solve their problem in a pleasing way. UI is 10% of work (or less), but it is 90% for the customer. Good screen shots are VERY important. Show customers (and non-technical managers) several versions of the UI - let them make unimportant choices that will not affect the schedule. When making presentations to non-technical managers, make the UI in screenshots proportionally as unfinished as the product. Add UI elements, as features are completed. Every week send them a self-congratulatory email about how you moved from 32 to 35% complete and are on track. Law of Leaking Abstractions Abstractions save time working, but don't save time learning (actually the opposite - now you have to know/understand the basic staff _and_ the abstraction) They save time when everything works as designed by the abstraction creator, but when you have to something that they did not think of - abstraction leaks - you have to understand both the abstraction and the layer below and spend a lot of time to solve it. Don't start a new project without at least one architect with several years of solid experience in the language, classes, APIs and platforms you're building on. Measurement of performance of knowledge workers does not work (they work to the measurement) (JS: actually it is just very hard) Microsoft got to where it is because it never made a fatal, stupid mistake (like other companies), maybe by luck. Software company can only succeed when it is run by people who understand both programming and business. Programmers who insist on rewriting everything should be admired by their love of clean code, but not allowed to make business decisions. Netscape did a rewrite from scratch (programmers idea), while their market share dropped from 90% to 4%. Eat you own dog food - use your own software Well-managed software companies trust employees and let them get things done. Disaster companies treat employees like burger-flippers who need to be controlled and monitored every minute. Some things need talent to do well It's hard to scale talent People try to scale talent by creating rules for untalented to follow The quality of the result is low (McDonald's) Don't hire new people until the people already hired have learned enough to become teachers and mentors of the new crowd. Not-Invented-Here is not always bad - if it is a core business function - do it yourself, don't outsource it. If you have customers, never outsource customer service. You can make a nice place to work or you can promise people they'll get rich quick. You have to do one of those, or you won't be able to hire. When starting new company, you have to choose between "Ben & Jerry" and "Amazon" model and stick to it. - Ben & Jerry = grow slowly, organically, and profitably - Amazon = Get Big Fast = raise a lot of capital and get big fast without concern for profitability To solve Chicken and Egg Problem - provide backward compatibility To get people to switch to your product, you have to eliminate barriers to switching (all of them). - including "let them go back" Bloatware is OK (disks are cheap), if you can ship sooner. If your strategy is 80/20 you will have trouble selling software. Principle of complements (microeconomics): Demand for a product increases when the price of its complements decreases - Smart companies commoditize their products complements: - IBM commoditized IBM-PC add-ons to sell more PCs - Microsoft commoditized PC to sell more OSs - IBM develops open-source software - trying to commoditize enterprise software (IBM is becoming an IT consulting company) - Netscape tried to commoditize browser (so they could sell more servers) - Microsoft tries to commoditize browser (so they can sell more OSs) - Transmeta tries to commoditize OSs (hiring Linus) - Sun and HP try to commoditize Windowing Systems (paying Ximian) to sell more hardware - Sun buys and open-sources StarOffice to commoditize Office and sell more hardware - Sun develops Java to commoditize OSs and hardware (???) All non-laptops should have RAID _and_ daily backups Automatic Memory Management is superior and results in greater programmer productivity (3-4 times). No developer with a day job has time to keep up with all the new development tools coming out of Redmond.