Slashdot Mirror
Joel On Software
The essays in this book are even-handed. While he focuses on Windows, Spolsky is not a fanatic believer in one approach over another; if C# works better than Visual Basic for a specific task, so be it. His approach is refreshing when so much is written by opinionated members of the "Microsoft is the source of all evil" camp.
Spolsky starts with down-to-earth topics, such as how to estimate the length of time programming tasks will require, and the ratio of QA people to developers needed for a healthy product. He then moves on to share his thoughts on managing developers and higher-level software-related issues.
One of the book's opening salvos, "the Joel Test for Better Code," is a simple "irresponsible" test that Spolsky created to provide insight into how well a development organization is functioning. The test looks for things like using source-code control, and having testers create daily builds with a single click of a button. As someone who has worked companies that would have failed the "Joel Test" miserably, I can attest to the importance of these criteria.
The chapter on Unicode is a short and to-the-point overview on the topic and should be required reading for any software developer and product manager who wants an introduction to Unicode.
Clean and bug-free code is a common thread in several essays in the first part of the book. Spolsky explains the inappropriateness of developers performing QA and stresses the need to "eat your own dog food." Having developers conduct testing is a waste of resources and upsets them just the same; forcing developers to use their own product will motivate them to create a better one.
In "Fire and Motion," Spolsky takes issue with the "architect astronauts" who generate vague technology announcements that are often counterproductive by creating fear, uncertainty and doubt. While these announcements may drive competitors to waste cycles in converting their code base to the latest technology, they offer no real substance. Misguided companies, mesmerized by the promise of new technologies or by demands from numskull customers, can sap years of developer time when product improvement should have taken precedence.
In "Biculturalism," Spolsky dispassionately discusses the differences in world view between Windows and UNIX programmers. Spolsky probably rankled some UNIX fans, but I share his perspective. Spolsky points out that UNIX developers are just as smart as Windows developers, but when it comes to understanding their end users and having empathy for customers, they tend to fall short.
The "Gorilla Guide to Interviewing" is relevant to all hiring managers. Spolsky describes some of the traits of his ideal hires. Those who, in one sentence, are both smart and "get things done." Spolsky believes in hiring people that can perform multiple roles. Spolsky believes in making a "sharp" decision about the candidate, and finds insulting that a hiring manager would not find the interviewee good enough for his own team but would refer him to another team. Spolsky shares one of his hiring secrets: never hire a "maybe." This might seem obvious, but he details why it's better to reject a good candidate than to hire a bad one. Firing can cost a lot of money, time and effort. Additionally, Spolsky suggests questions to ask during an interview and the necessary "what not to ask."
The "Iceberg Secret Revealed" discusses the manner in which customers express their pain, and points out that customers often don't really know what they want. It is the product manager's job to find a solution that will solve their customer's pain while keeping an eye on the market she is addressing. Just listening to customers without proper filters, is as Spolsky points out, a recipe for disaster. And the Iceberg Secret? Spolsky illustrates in five different ways how customers and stakeholders only look at the tip of the iceberg, and not at the substance beneath it.
In one of the shorter chapters, a missive on measurement, Spolsky addresses the prickly issue of measuring performance in companies. In addition to his own insights on measuring performance, he recommends Measuring and Managing Performance in Organizations by Robert Austin. I will add that to my reading list.
Spolsky wrote an introduction to In Search of Stupidity . He offers there the "geek's" perspective on what it takes to make a successful software company, taking as a starting point the ten largest software companies in 1984 and the equivalent list of 2001. His conclusion is that "no software company can succeed unless a programmer is at the helm." With his usual even handedness, he is quick to point out some of the debacles programmers are responsible for. In the example he gives, Netscape's disastrous rewriting of their code base and almost complete loss of market share while they were doing it. His bottom line? To succeed, a company needs a management team that love and thoroughly understand programming and understand and love business. Not as easy as it sounds.
In his five "Strategy Letters," Spolsky writes about issues that are relevant to anyone making strategic business decisions in the software industry. He starts with company growth modes by comparing Ben & Jerry's to Amazon. He then discusses the classic "Chicken and the Egg" problem when building new platforms. His example is still relevant -- few will develop .NET-based clients until a large number of end users have the .NET engine installed on their PCs and end users will not install it until there are enough applications that require it. Spolsky moves on to discuss backward compatibility, open source economics and the myth of bloatware.
Spolsky points out that despite the growing size of applications, the cost of disk space has plummeted even faster. This may be true, but Spolsky does not address the programs' resulting sluggishness despite more and more processing power. Spolsky wraps up the essay by dismissing the notion of coming out with a "lite" version for a given software product. I agree that lite versions do not always satisfy everyone, but they can be a great way to keep out low-end competitors from entering the market in addition to a way to introduce customers to the high-end product.
The chapter about Microsoft losing the API war is a classic. Spolsky starts with the seemingly outlandish assertion that Microsoft lost the API war. After apologizing for his "grandiloquence and pomposity," he goes on to build a convincing case that if Microsoft has in fact not lost the war, they are definitely in danger of doing so. He starts with the diminishing interest in the Windows API as a development platform. He then describes how two camps inside Microsoft (the "Raymond Chen" and the "MSDN Magazine" groups) are influencing Microsoft's approach to their developers' tools. The former group emphasizes creating a backward-compatible operating system, free of bugs and impervious to third-party applications' errors that can harm it. On the other hand is the MSDN group, promoting the latest and greatest Microsoft has to offer. As Spolsky sees it, the latter group has the upper hand, and because of this, Microsoft is losing their developer base to simpler, more easily deployed platforms.
In part 4 of the book, Spolsky takes on Microsoft's .NET strategy. He describes Microsoft's tendency to create FUD in the marketplace with vague, hollow statements, and details his own company's reasons for not adopting .NET anytime soon. Spolsky wraps up with a very straightforward feature request: a linker for .NET. This would seem to be an obvious feature, but Microsoft so far doesn't agree. Microsoft is acting as though they want to win the development platform war in a single sweep. At the same time, independent software vendors (ISVs) are resisting, because they have to guarantee backward compatibility and support for everything their customers run.
My only complaint about the book is that it's too short. On my bookshelf, it resides next to the Mythical Man Month, another favorite.
Spolsky is knowledgeable, funny and free of unnecessary religious fervor. Joel on Software is a must-read for developers, product managers and those who want more insight into the world of developing software.
Daniel Shefer is a Software Product Management professional and has written numerous articles on this topic. You can purchase Joel on Software from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It's pretty pathetic that you refer to Microsoft as M$ and then try to pimp your Amazon affiliate link in the same post.
+5 informative? Please. This is just another post by cloudkj to spam his Amazon affiliate links.
He has a history of this.
Quit modding this dickhead up.
That is bull. "Talented developers" in a big organization? Well established processes are the only factor that counts, so every developer can be replaced, like lego pieces. Otherwise organizations would be relying on individual talent, that is Ok in a 5 people team, but not for big software. Maybe this is the reason why MS software didn't shine for a long time. Now it is a lot better. I use it myself.
*p in this case _is_ the dereferencing of the NULL pointer, and it certainly will produce a segmentation fault. The use of reference merely obfuscates the nature of dereferencing in this example, and a debugger or runtime has to find out, what exactly should be said about the reference when the segfault/exception/... happens inside the function because dereferencing happened not at the earlier moment (outside the function) when it looked like it was supposed to be done. Even if some particular behavior was defined for this situation, optimization would likely break it.
So the most Joel could accomplish by using a reference is that the dereference of NULL would kinda supposed to happen outside of his precious function, and in the code of the poor guy who dared to call it. "Kinda supposed" because it isn't even guaranteed to work that way in the first place.
Contrary to the popular belief, there indeed is no God.
What SuperKenall said is correct. However, some languages have more differences than others.
.NET languages MS ships are all about the same; the only difference is syntax. .NET requires all compatible languages to adhere to the same capabilities so they can be 100% compatible with each other. Unfortunately, it also requires all the languages it supports to be dumbed down to the lowest common denominator. There is a very long list of things that had to be removed from ISO C++ to create Managed C++, because including them would make it incompatible with VB and C# (and .NET), such as multiple inheritance, templates (non-type params too), pointers, member pointers, etc.
.NET (it normally compiles to C), but you can forget about a runtime system like Prolog being compatible with .NET. .NET doesn't understand functions that don't have an implementation until you've decided the direction the argumets are flowing (a very big part of declaritive languages), .NET doesn't understand state tracking and backtracking or multiple modes based on detirminism, .NET doesn't understand multiple possible results for a single variable (a list is the closest you can get; it isn't the same because you have to do all the handling yourself which defeats the purpose). .NET, though.
.NET if there were bytecode compilers for other languages. .NET and Java are so alike in function anyways.
All the
Functionally, VB.NET, C#, J#, and Managed C++ all have exactly the same capibilities. They are all sequential, procedural, imperative, object-oriented languages that support single inheritance, interfaces, events, exceptions, type generics(they will in v2.0), reflection and share a common runtime library and work in a sandboxed VM. The ONLY differences between them are in syntax. So, it doesn't really matter which of these languages are used unless someone in the group doesn't know the syntax for a language in a source file they need to work on. The interfaces between them will be equivalent regardless of language.
Compare this to a functional language such as Common LISP or Scheme, or a declaritive rule-baed language like Prolog or Mercury. Mercury can compile to
Haskell has to jump through hoops to get the needed multiple inheritance to work.
OTOH, there are some interesting projects like F#, an OCaml like functional language. It has some serious issues to be compatible with
It's like Microsoft offers you several languages, but they are all the same. The illusion of choices without really having any. They should just be like Java and admit that there might as well be one language-- seriously, Java could have all the multi-language support of
As for what languages should be used when, where and by whom: I don't know. I'm still trying to figure that out. I know that some are good and bad for certain things, but I also know that personal preference is important, too.
</rant>
I'm not versed in his history at MS but I do recall him being noted as a very talented developer by top MS executives.
Just playing devil's advocate here, how would top executives know how to spot a talented developer? There's a developer at my work that people think is "very talented" because he's always boasting about how good and fast he is, inflating his own accomplishments and stroking people's egos. Realistically, he's an average developer, but he fools the "top executives" because they all come from a sales and marketing background and wouldn't know how to spot a talented developer if one landed right in front of their noses.
In this world nothing is certain but death, taxes and flawed car analogies.
Well, there's more than laws. There's trade policy, diplomacy, and fiscal policy. Why are these important: they affect exchange rates. Exchange rates are what drive programming jobs overseas; American programmers are as good as any in the world, and in many cases there are inefficiencies in moving tech jobs overseas. But if the cost is low enough, then the jobs will go. Marginal changes have a big effect.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.