Oy, I just can't figure out how I'm ever going to beat MattyG.
Here's the story... of a lovely LAdy...
Aw, heck, I can't sing.
I've rearranged and rewritten a lot of the PaxDigita website. Now it's a bit of a more accurate portrayal of the company I'm building.
I'm interested in hearing how people are tracking bugs in their code.
There are a few commercial bug tracking database products, like Rational ClearQuest, and some public domain ones, like Bugzilla, but most people seem to be rolling their own.
I'm working on an article about bug tracking. Do you do formal bug tracking? What's the sociology of bug tracking? What tools do you use? What do you like about them and dislike about them? Write me!
Human aptitude tends towards the bell curve. Maybe 98% of your friends are smart enough to use a television set. About 70% of them can use Windows. 15% can use Linux. 1% can program. But only 0.1% of them can program in a language like C++. And only 0.01% of them can figure out Microsoft ATL programming.
The effect of this sharp drop-off is that whenever you "lower the bar" by even a small amount, making your program, say, 10% easier to use, you dramatically increase the number of people who can use it, say, by 50%.
News of the vile: Cubicles are getting smaller. The good news? If you're willing to spend more to provide humane office space, you should have no problem recruiting people.
A response to a reader's question on using Excel for schedules: Juggling Tasks in Excel.
We've talked about the principles of good design, but principles only give you a way to evaluate and improve an existing design. But... how do you figure out what the dang design should be in the first place? Many people write big, functional outlines of all the features they thought up. Then they design each one, and hang it off of a menu item (or web page). When they're done, the program (or web site) has all the functionality they wanted, but it doesn't flow right. People sit down and they don't know what it does, and they don't know how to accomplish what they want.
Microsoft's solution to this is something called Activity Based Planning. (As far as I can tell, this concept was invented by Mike Conte on the Excel team, who got bored with that and went on to a second career as a race car driver). The key insight is to figure out the activity that the user is doing, and focus on making it easy to accomplish that activity.
Read all about it in Chapter 9, the final installment of my book on UI design.
Despite the fact that raging search, an AltaVista spinoff, is a blatant ripoff of Google in every way, it still produces pathetic search results. (Compare the result of searching for President Clinton on raging and google and you'll see what I mean.)
In addition to the data you may provide through the Member Profile and other surveys, we may collect information relating to how you use the Service (including, for example, information relating to your frequency of use, navigational information such as the uniform resource locator (URL) of the Web pages you visit, configuration information such as the type of Web browser you are using, your Internet Protocol (IP) address, processor type and operating system, and information relating to the display of any advertisements transmitted to you).This steady erosion of privacy dismays me. The Juno database will have your name and address and the web pages you visited, for 3 million Americans who use the service every month.
If I had still been working at Juno, I would have probably been assigned to implement this feature. I would like to think that I would have refused on principle, even if it cost me my job. Maybe my taking a stand would have inspired other people to refuse to go along (not that that would have changed anything -- management would just gather us all in a room and scream at us.)
Then again, it's hard to say "I would have taken a stand," since I wasn't really there, and I didn't really take a stand. Lucky for me, I quit way back in November, and so my integrity never stood the test.
Are you a Ben and Jerry's company or an Amazon company?
In Strategy Letter I, I talk about two different kinds of startups. If you don't know which one you are, you're going to make lots of mistakes and you won't even know why.
Sometimes, my kind readers resort to tricks to find out if I'm awake! Like this suggestion from Hanan. It sounds good at first, but after a minute you realize it might be a minefield.
My strategy letter seems to have hit a nerve. For an insider perspective on this from one of the many ex-Netscape employees known as "Netscapees", read this.
A new strategy letter talks about the Chicken and the Egg problem, and one way of solving it.
Seth Gordon emailed me some great tips for reading other people's source code. Reading Code is Like Reading the Talmud
Ramon Garcia Fernandez writes:
In your essay 'Things you should never do, Part I' you are against rewriting source code. But, what if the author of some source code is not available? What methods would you recommend to understand code written by another programmer? This situation is often encountered in the free software world, where you would rather reuse an existing program than write one from scratch, but it is difficult to read code written by another programmer.
I think the best way to read somebody else's code is just to SLOW DOWN... it's like deciphering a code, not like reading. Most people have trouble reading code because their eyes are used to reading at a certain speed from reading text written in human languages. But code is much more dense than English, and contains 'secrets' that need to be deciphered by looking elsewhere: for example, when you see that function call that says UpdateData(FALSE), unless you remember how UpdateData() works, you have to go look for it to figure out what the first argument is and what FALSE means.
It takes some skill to learn how to read code slowly and carefully, and many programmers are not patient enough (so they wind up rewriting the code from scratch). But you have to remember that it's still faster to read than to rewrite!
While we're at it, Lou Montulli, one of the founding engineers of Netscape and the creator of Lynx, sent me the following response to my plea never to start over from scratch in 'Things You Should Never Do':
I agree completely, it's one of the major reasons I resigned from Netscape. In 1998, after wasting a year wanking, a group of new but experienced programmers, and one of our misguided founders, decided it was a good idea to rewrite everything. I had alot of vested interest since I had done most of the original design work on Navigator, but I was unable to supply enough visions of doom to divert the effort. The original design had degenerated substantially due to the integration of Java and the rapid pace of zig zag development that went on over the course of 4 years. There was good reason for a large change, but rewriting everything was a bit overboard to say the least. I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.
1111 posts over 14 years. Everything I’ve ever published is right here.
There’s a software company in New York City dedicated to doing things the right way and proving that it can be done profitably and successfully.