There are lots of people who strongly suggest that you should do your development in public. It is part of the “release early and often” concept. But I also believe that this concept is not effective in developing great ideas because it is limiting. The minute that you get real customers involved, their needs become much more pedestrian. They will yell loudly about things that may be important to their use of the product, but they will rarely yell about some new game-changing concept. In fact they will resist radical change and rethinking because it messes with their now committed workflow. And now you are comitted to supporting them. So as I see it you should strongly consider whether you have enough meat on your conceptual bone before you decide to release publicly. Because when you get users involved, it is the equivalent of putting the saw and the screwdriver down and grabbing the sand paper. There will likely be few additional big ideas after that point.
October 3, 2008
Release When Ready
September 30, 2008
September 29, 2008
Lovable Software
Money can’t buy you love, but love can bring you money. In software the only sustainable way to earn money is by first creating love, and then hoping that some folks want to demonstrate that love with their dollars.
…. Everything should be shareware to be tried and tested until its value is proven and the love-meter swings open the wallet. If I were to pass on some music or a piece of code I become a vector of word of mouth viral marketing, the best kind, the kind that money can’t buy.
September 21, 2008
The Graphing Calculator Story
Just read this. It’s easily the most amazing software development story I have ever heard. And yes, I used that software in school.
September 18, 2008
I Would Rather Have a Runtime Error Than a Compile Error
And the weird thing is, I realized early in my career that I would actually rather have a runtime error than a compile error. [(some laughs)] Because at that time… now this is way contrary to popular opinion. Everybody wants early error detection. Oh God, not a runtime error, right? But the debugger gives you this ability to start poking and prodding, especially in a more dynamic language, where you can start simulating things, you can back it up… You’ve got your time-machine debuggers like the OCaml one, that can actually save the states and back up.
You’ve got amazing tools at your disposal (in the debugger)… Whereas if the compiler gives you an error that says “expected expression angle-bracket”, you don’t have a “compiler-debugger” that you can shell into…
So, you know, in some sense, your runtime errors are actually kind of nicer.
— An excerpt from one of Steve Yegge’s (long!) talks.
I think there is a real nugget of truth in this. At runtime, you can examine your program’s state, but there is absolutely no way to do that at compile time. Without a debugger, you can’t just look at some nontrivial code and know what the value of x is when there’s an error reading y. (Adding "print x", recompiling, and trying again, would work of course, but that’s just using your compiler as an inefficient debugger!)
Similarly, Strong Typing vs. Strong Testing , essentially argues that some tests can only be made at runtime. (If you read any links on this page, read it, it’s much shorter and to the point).
September 14, 2008
Fast Enumeration Really Is Faster
Your code will also run faster because the internal implementation reduces message send overhead and increases pipelining potential.
I’ve written before about the advantages of a better enumeration paradigm, clearer code that’s faster to write, shorter, and with fewer bugs.
If you program in Cocoa, you should adopt fast enumeration post-haste.
September 6, 2008
The Term “Sprint” is Very Wrong for Software Projects
My employer is big on Scrum-flavored Agile Software Development. This is not a critique of “Agile” practices (if you want one Steve Yegge won’t let you down). I just don’t have enough experience organizing software projects to judge if this whole “Agile” thing is working well or not. But I do think the choice of the word “Sprint” to denote a unit of work is harmful.
A sprint is unsustainable. Fully recovering from a true-sprint takes a long time. To be ready to sprint again, you must rest for far longer then the sprint lasted. And you’re pretty useless (at least running-wise) while you rest. These are simple things that we learned as kids on the playground. This is what “sprint” means to people.
Calling repeated multi-week units of sustainable and quality work a “sprint” makes no sense whatsoever. Worse, it subtly encourages over-exertion and behaviors that are detrimental to a project.
It might be argued that in the context of Scrummy-Agileness, “Sprint” is a technical term, divorced from the common parlance. Whatever. Words don’t change meaning overnight, and they are almost never their own antonyms. Word-choice is known to influence people.
Sure, word-choice alone isn’t enough to derail a project, or sink a methodology. That’s why this isn’t a criticism of “Scrum”, which will ultimately stand or fall for other reasons. But there are plenty of much better terms to describe a chunk of work, that will help long-term productivity. Wouldn’t you rather work for a company that evaluated how effective a “Play” was?
July 7, 2008
The Cost of Computing
But if you look at the history of the computer business, where we are at now in terms of costs is probably similar to where we were in the 80’s and early to mid 90s. Most of the cost was in manpower. That was the case then and it is the case now.
See also, Jeff Atwood: Hardware is Cheap, Programmers are Expensive