I finally got a download site set up for the free CityDesk Starter Edition. It's free, fun, and easy to use, so there's no reason not to download it and try it out!
Fog Creek Software is looking for a Director of Sales & Marketing.
Yes, Virginia, CityDesk can be used to generate XML. How to create an RSS feed using CityDesk. Using a similar technique you could output your site using any XML schema you want.
Back to Basics. Wax on, wax off.
Michael asks: "I'm interested in anyone's ideas on either good or bad interface issues that they've seen while buying things. Remember that I'm selling software, so order tracking and fulfillment don't really exist..."
I have really smart readers. Wow.
Google now has 20 years of Usenet online. You can entertain yourself with some scary stuff from my past.
Lazy programmers who didn't read about how users don't read anything:
The main purpose of this screen seems to be so that users blame themselves when they hit reload and find themselves blown back to step one. Oh darn! I'm so stupid! say the users. Yes, that's what happens. Watch any usability test where the product is failing - the users inevitably blame "their own stupidity." Better that 100,000 users should feel stupid than one programmer admit he didn't do a very good job.
Don't let anyone tell you that as a programmer you don't have to make moral or ethical decisions. Every time you decide that making users feel stupid is better than fixing your code, you're making an ethical decision.
Razib Kahn: "So I finally gave up and created a shopping system exactly like amazon.com, and the e-mails stopped at a screeching halt."
I'm still working my way through a pile of books I bought with the purpose of updating my list of recommended books. One of these days I'll get to the bottom of the pile and update the recommended list. All in good time!
FogBUGZ 3.0 Development
The FogBUGZ 3.0 development process is in full swing now. One of our first priorities is to refactor and clean up some of the code. There were a bunch of places with duplicated or almost-duplicated code; our logic wasn't cleanly separated from the UI; the HTML we generated was based on ancient browsers. It's the kind of project that would tempt a lesser programmer to "throw it out and start from scratch." Instead, we're going through the code one file at a time, cutting and pasting blocks, scrubbing the HTML (to use fully-XHTML valid code with all formatting isolated style sheets), and creating new classes for underlying logic that used to be scattered all over the place.
In the ideal world, when you refactor, you simply apply almost mechanical transformations to an existing code base that can be clearly understood to have no effect on the correctness of the code. The simplest example I can think of is changing "if not x then A else B" to "if x then B else A". You know that you can always do such a thing without breaking the code, and if it's a little clearer to read, it's a safe fix.
Here's a typical thing that happens. As I go through the code, I'll find some SQL statement in the middle of some HTML. So I create a class and give it a method that executes the SQL statement, and call that method from the HTML. I'll start with the old SQL code and move it into my new class unchanged. Then I'll look at that class for opportunities to apply more simple, bite-sized transformations that make it cleaner or faster. In the principle of eating our own dogfood, all daily changes go up on our internal bug database right away. Because we're refactoring rather than starting from scratch, at any given time we always have a working version of FogBUGZ checked into CVS. In the worst scenario, we've introduced a small bug.
The best time to refactor is at the beginning of a development cycle. That gives you the maximum amount of time to catch any bugs that you introduced accidentally.
In the ideal world, we would have strong unit tests so that we could convince ourselves that nothing was broken that used to work. As we applied transformations, the unit tests would tell us automatically if we had broken anything and we could probably stay at zero bugs throughout the process. This is one of the valuable principles of Extreme Programming. We haven't created unit tests yet, because all the HTML->XHTML+CSS cleanup that we're doing makes FogBUGZ's "correct" output a rapidly moving target. As the output stablizes, we'll build unit tests. We did not follow the XP principle of writing unit tests first, because it is so much easier to (a) write the code (b) hand-check the HTML that it produced (c) use that HTML as the basis for the unit test. If you do things in the XP order you have to figure out character-by-character what your output HTML is supposed to look like in advance, which strikes me as mind-numbingly tedious and a serious waste of time.
This site is supposed to be about software management. But sometimes you don't have the power to create change in your organization by executive fiat. Obviously, if you're just a grunt programmer at the bottom of the totem pole, you can't exactly order people to start creating schedules or bug databases. And in fact even if you're a manager, you've probably discovered that managing developers is a lot like herding cats, only not as fun. Merely saying "make it so" doesn't make it so.
WhatCounts Replaces Mailman
I used to use mailman to send the notification email to the 7568 subscribers who signed up. It had some problems. The biggest one was that every email that went out had to be exactly the same, and there was no way to include a recipient's email address in the text of the outgoing message. This made it a pain to unsubscribe people who didn't quite know why they were subscribed (usually they had an old email address forwarding to their current address). In fact I'm embarassed to admit that under the old system the only way to unsubscribe people was for me to go through all the unsubscribe messages and remove people manually. Why I put up with this for so long is completely beyond me.
Thanks to David Geller at WhatCounts, I have a new system to manage the notification email. Every outgoing message will automatically have a custom return address on the WhatCounts server and a custom link you can click to unsubscribe. I hope this will make list management, finally, a totally painless process. The only problem with the new system is that if you receive one of my notifications and reply to it, I never see the reply. WhatCounts will assume it's a bounce or an unsubscribe request and deal with it appropriately. If you want to contact me you have to send email, rather than just replying to the message.
Kevin wants to hear about people's experience with pair programming. (I'm curious too!)
Doc says, "When the software industry is mature, it will look a lot like the construction industry." This is a common theme. A lot of people complain about how the creation of software suffers from all kinds of problems that mature professions (construction, civil engineering, etc) don't. The key problem is always that the software coding process doesn't seem to be reproducible and predictable. Programmers think things will take 10 weeks and then they take 20 weeks, and they have weird bugs that you would never tolerate from a bridge built by a civic engineer.
Implicit in the claim that the software industry is "immature" is the belief that this is just because we haven't learned all the tricks yet to getting reproducible results. But this idea rests on a falsehood. The unique thing about software is that it is infinitely clonable. Once you've written a subroutine, you can call it as often as you want. This means that almost everything we do as software developers is something that has never been done before. This is very different than what construction workers do. Herman the Handyman, who just installed a tile floor for me, has probably installed hundreds of tile floors. He has to keep installing tile floors again and again as long as new tile floors are needed. We in the software industry would have long since written a Tile Floor Template Library (TFTL) and generating new tile floors would be trivial. (OK, maybe there would be six versions of the library, one for Delphi, one for perl, etc. And some sick puppy programmers like me would rewrite it. But only once, and I would use it everywhere I needed a tile floor, and I would try to convince my clients that their back lawn would look really nice with tile instead of grass.)
In software, the boring problems are solved. Everything you do is on the cutting edge by definition. So by definition it is unpredictable. That's why software has more of a science nature than a construction nature.
1111 posts over 13 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.