business
More Joel on Software
October 18, 2009 - 22:21 — bhugaMeh.
I was kind of disappointed here. A ton of people read Joel on Software, so I bought this before a plane ride, figuring it'd be a good intro. I also figured it'd be nice and recent, being the more recent edition. I was wrong--most of the content is from 2001, 2003, 2005. This means that most of the content is the stuff that did not make it into the first book (2005) and waited until this one (2007). I was not impressed with that.
At any rate, some of the stuff in this book makes good points, but they are overpowered by the sheer badness of the bad points. He takes the time to defend hungarian notation, when used right, because you need something like that for programming languages without proper type checking. Then he suggests using similar functionality to defend against XSS attacks. Too bad Perl came up with the concept of taint to solve that problem right only 6 years before you wrote that, Joel.
Some of his points on business are good. Things like how to price software, segmenting your market for effective price discrimination, automatically weighting the time estimates of developers based on past estimation performance, and a few other ones.
The writing style is very lightweight--it's blog posts, after all--and the book is quite an easy read. I really found most of the actual programming advice to be quite bad, so were it not for the good business advice and lightweight style I'd have probably been quite disappointed. But the amount of time spent was worth the insight gained, so while I can't recommend it, I've spent my time getting only halfway through far worse books.
The Mythical Man-Month
September 28, 2009 - 09:17 — bhugaThe classic. I am not so sure it held up well.
I first read this about 8 years ago. I was not ready, and even worse, I somehow managed not to get the 1995 anniversary edition.
The truth is that most of this book does not hold up to the test of time as useful advice. While interesting and quirky, stories about static layering utilities as examples of programming management gone wrong are just not really useful. Advice from the era of computing in which it was done by companies like IBM seems almost surreal. Make sure your best programmers get offices equivalent to the best managers. What? Where do programmers have offices?
The real gems are in there, though. You need to know what you are looking for to get them, so I'm not sure this is the book to get them. But they are there. Software collaboration is harder than solo coding. A good programmer is 10 times more productive than a mediocre one. Bad or inexperienced additions to a project do not help it marginally, they actively hurt it. Making programming to faster only ensures the poor quality of the end product. Men and months are not interchangeable. All very important.
Brooks' breaks it down to the problem of 'essence vs incidental (he uses accidental, which I find a poor use of the term)'. He said that in 1975, most of a programmer's time was already spent on essential work--programming is creative and difficult, and no amount of tooling can make that go away. It's difficult to think of it that way now, when we're slapping together databases and countless libraries on top of OS and library and driver stacks 10 layers of abstraction deep. So the problem has been solved by dodging it, making the programmer responsible for less and less with each new application framework. But we have still not found a way to make the creation of code easier, really. There are just fewer distractions.
I'm not sure I'd recommend the book today. As crucial as it would have been even just 15 years ago--already 20 years old at that point--it feels dated today; not really saying anything you'd notice unless you were looking for it, so why are you reading the book? A lot of the breakthroughs in here are simply common sense today. But it's an easy read, and it was a classic with a lot of staying power. Physicists still read Newton on occasion for the history of it, and this one should go down in computer science for the same reasons.
