So, I’m reading through Peter Seibel‘s “Coders at Work“, which both Joel Spolsky and Jeff Atwood blogged about. At some point I want to write more about the actual interviews; which are fantastic. But today, I’m just sharing a link of something that I came across in the book. In Seibel’s interview with Brad Fitzpatrick, Brad mentions something about style guides that Google published. Well I found the link to them and passed them around my office and it started some pretty interesting conversations. Anyways, thought it was worth highlighting this link since it’s definitely worth a read through.
http://google-styleguide.googlecode.com/svn/trunk/pyguide.html
The reason I even thought about looking up the link is because there was a discrepancy in the way people were naming Python modules in the project I’m working on, which was making me a bit uncomfortable. I was wondering what the Google folks had to say about it. With Guido, of course, their opinion has some clout in the Python world…
I’m only on the fourth interview and I’ve already been exposed to lots of great material. One thing that I finally did — after years of wanting to take the plunge — is I ordered The Art of Computer Programming books (“volumes”) by Knuth. I *almost* buy these books every single year since 1999, but it just seemed time…if you read the “Coders at Work” book, you’ll see why… One great thing is that they put out a new version of the books in paperback, and they’re MUCH cheaper than previous versions. So that made the decision to finally buy them very easy.
I’m putting the finishing touches on a project I’ve been working on for the last 2 months. As with any semi-serious non-government contract projects I’ve worked on, the end is always painful. Did your original design meet the original demands? Is the demand still there? What have you forgot to test for? And of course the problem I’m running into now: I really want to add features to make this the most robust piece of software ever (emacs, anyone?)…
As with anything, the desire to make something really great is a hard feeling to suppress. It’s almost feels like punishment to hold off from putting in a feature that would fit in more nicely with the Web 2.0 crowd.
How do you know when to hold back and when to introduce a new feature, you may ask? TIME
Time, is the only factor that really impinges us from doing everything. If it weren’t for time any great programmer would write an OS, but of course that’s not the case, and time is the huge crutch that you have to work around. When working for a company it’s easy to know when your “time is up.” The funds for your project will just stop showing up one day, or a requirements review will come your way.
Yet a more significant challenge is how to know how much time you have in a self-guided effort. And the rule I’m sticking with now is, get 1.0 out and then work on adding the newly thought-up features after you have the clients to gear it towards. Then, you’ll get feedback on the features while you add them and the features will be all the more useful.
Of course, the next problem with holding back from adding features is it could limit your ability to acquire a client, but in reality all you have to do is make sure to not promise a version 2.0 with X features at Y date, when 1.0 is ready to go and solves specific business problems. Because then you risk having the client wait for the more improved 2.0 version, thinking 1.0 won’t suit their needs.
1.0 feels limiting, but make sure its limited scope solves a real business problem and sell on that promise. And don’t sell more than you’ve got.
I was looking for a good way to count the number of lines in my project. I came across SLOCCount and couldn’t be happier. It recognizes lots of different languages and even gives great little estimations as to the cost of the development of your code.
http://www.dwheeler.com/sloccount