What really gets my goat is that users will often just click an apparently random button when a dialog box pops up, even if it's the first time they've ever seen it. They don't even read it and try to understand it.
Hell I've seen so-called "programmers" do this with their development tools. Whenever they call me over to help with a problem and show me what they did and that demonstration includes clicking a dialog closed faster than I can read it, I just say, "Hmm, I need to look into this issue a bit. Let me get back to you."
From Earth to the Moon series is great, largely based on Andrew Chaikin's book, "A Man on the Moon", a great read. Tom Hanks did it, after doing Apollo 13. The book that movie is based on was written by Jim Lovell, the commander, and was originally called "Lost Moon". Also worth a read.
Regarding Steve Bales getting a medal, score a big one for the geeks.
>GIF is the only well-documented animation format that popular web browsers can display without a plug-in
And the sooner the dancing spam dies, the better.
Well a proof of my own point -- miscommunicated what I was trying to say about mentoring. When I wrote that suggestion, I was referring to the specific context of within a company where they like formalized pre-packaged training and the training department is "in charge" of all employee training programs. My prediction is that the experiment as I suggested it will reveal an anti-mentoring bias among formal professional trainers.
You are correct, in tight-fisted companies there will be way more work than people to do it, and certainly no program to develop talented people up through experience.
I am more than happy to commit my knowledge to paper (or bits), because I know that the written information will likely be a ghostly echo of real knowledge. It is Hard to communicate explicit understanding through writing, and all but impossible to communicate the implicit knowledge that is the real value of experience. If a business were to attempt a moderately effective program of creating written records of the institutional knowledge of their people, they would quickly discover the cost and effort swamping the budget.
Most attempts to write documents for things that are contained in the practices and processes of the people, of which I have experience with a few, result in a listless pile of binders that few read and fewer get any understanding from. In the cases I've been involved with, once the written document was published to the organization, the calls and emails from people trying to understand and put into practice the material just added another demand on the time of person who has the knowledge.
Knowledge can't be effectively captured merely through writing it down for many reasons, but a good one is that not everyone learns most effectively by reading. On the other hand, so-called "social learning" techniques like those discussed in Situated Learning and The Social Life of Information are much better guides for how to retain and spread knowledge.
It appears common, however, that professional trainers are threatened by anything that would reduce the budget and power of the corporate training department. As an experiment, if your company is big into pre-packaged training materials, try getting a formal mentoring program going in your company.
Except, as the parent clearly pointed out, PMs don't have the qualifications either. At least as a software developer, I know how to do my job and can tell when someone telling me what to do is full of shit.
> customers are only asking about it because Microsoft is baiting them to - it doesn't really buy him anything to port.
Well that's exactly it. The article is a long hagiography on how great Joel says it is that the windows team has done everything possible to make it so old software continues to work, and hey, Windows is pretty darn good as it is, so please please, says Joel, don't make me port to.NET and lose 12 man-years and get wiped out by Microsoft anyway when they ship MSDesk for.NET.
Joel's just whining because he knows he's going to have to port CityDesk and his other products to.NET soon, because customers are probably already asking about it. He's screwed by the same vendor lock-in that all other 3rd-party MS developers get blown away with. By the time his company is done with the port, MS will have thrown 3 times as many people at developing a "good enough" competing product that will ship ready for Longhorn, and Fog Creek will be just another assimilated victim.
Is it also possible that Joel's entire career and his company are centered on the last generation of MS technology, and they are about to become dinosaurs because they haven't kept up? It's very telling that he knows how expensive and rare Windows C++ programmers have become.
As for the free advertising, he's trying to convince those customers that have become trapped on the Microsoft upgrade treadmill (and are paying excessive subscription fees for the privilege) that everything is fine and dandy with the current Windows technology, and they should feel perfectly comfortable staying on 98 or NT as long as they keep buying FogCreek software and don't switch products before CityDesk is ready for Longhorn. A Longhorn Joel desperately hopes doesn't come charging through the door before his team can finish their rewrites.
Too bad the interviewer, Jorge Castro didn't press for details in clarifying a couple of Collins' statements. In speculating on what's wrong with Microsoft, Collins says it's hubris, "that they have all the answers, that they know what's right for you, but yet we keep getting more and more security patches from them, because they don't actually know what's right for us," and adds, "it is their hubris in knowing what people want, and saying "we know what is good for you," that is eventually going to pull them down. It's not going to be that somebody else actually knows better, because Microsoft actually does have a pretty good idea of what one generalized virtual person wants.". Yet when discussing FireFox default theme change for 0.9 Collins asserts, "Ben Goodger is the ultimate decider of what happens to Firefox, it's not a democracy, it's Ben Goodger, and that's fine."
It would have been great for Castro to dig a little deepr and ask Collins what makes Goodger knowing what's best for users different from the hubris Collins ascribes to Microsoft.
At the end of the story is a "Base Case" for the Stanford PeopleSoft/Oracle upgrade. There are three "Baseline Goals" listed that are just the start of wrong thinking in a project so full of wrong thinking (if the story is accurate) that it could be used as a the basis of a study of how not to run a enterprise software replacement.
To start with, it was inevitable that the close connections between the Stanford officials and the vendors would result in management blindness to problems. Either they would refuse to see problems, or the technical staff would be under tremendous political pressure to hide the problems.
Another dead wrong move: the "big bang" rollout. Of course the helpdesk and support folks were going to be overwhelmed. Things never work perfectly in the beginning, and what might have been limited to a small troubleshooting effort if they'd done a limited, staged rollout swamped everthing else with problems.
The complaint that the software was designed for a particular mainstream business process and not well suited for a university is reasonable in some respects. Yes, for the dollars spent, the software should be more flexible, and it is unreasonable to expect a university to re-engineer its process to fit the standard ERP model. On the other hand, if, as the story implies, the people running the project didn't realize in advance that university administrative computing is unlike private businesses they were wholly at fault for problems. At the very least, had they identified the areas where Stanford's processes could not be changed to match the software's expectations they would have known to budget more for the customizations.
Another problem mentioned in the story is the apparent disconnect between the IT people in charge of the project and the people expected to use the product. There are multiple mentions of the userbase feeling shafted by the results. Any large IT project that fails to include input from the people whose jobs require using the system constantly every day will be a textbook failure.
The story also mentions the CIO saying, "Stanford should distinguish itself through teaching and research, not unorthodox administrative processes that software vendors could standardize and ultimately make cheaper". This is a form of the increasingly common fallacy of "core business" that pops up a lot in management. The thinking is that a company should focus only on being better at whatever business it's in, and that the "non-core" things, like IT, should be standardized and outsourced. The fallacy is that it is generally impossible to separate a company's way of competing in business from the way it is structured and the support processes it has created. As an extreme example, take FedEx. Nominally they are just a shipping company. They collect boxes, move them around, and deliver them. But it is impossible to say that FedEx would be better by focusing on better box-handling and buying some standardized pre-packaged logistics software.
The real core of the problems, however, appears to be the bottom line, as stated in all three of the base case points:
Finish adapting financial systems to Oracle software by September, after five-year delay.
Maintain quality of information system operations, amid budget cuts of 5% to 10% per year.
Cut annual software ownership costs, which run up to 18% of purchase price, by outsourcing and thus licensing fewer modules.
In small words: do the same work with less money. Apparently, the rule of "cheap, fast, good: pick two" is no longer part of the vocabulary of management. Of course the users, and to some extent the poor overworked and underpaid techies tasked with making the steaming heap work, are the ones who actually end up with the burden of the cost, in money and time.
One final observation. Several slashdotters have commented on the apparent irony that a university with some of the smartest people in computer science screwed up this project so badly.
When were were writing with typewriters, we didn't have font size changes, we would put a heading in all upper case. I remember even learning to oh-so-carefully go back over a typed word to bold it. Now we have so much support in our word processors -- even in HTML for emphasizing text. You can bold it, italicize, you can even define all-caps styles so you get the caps whether you type with shift on or off. So now, the caps lock key just gets in the way, to get accidently pushed when we are typing, usually at the worst time. How many of you have had to remind someone (or yourself) to make sure capslock is off when typing your password? (I'm not going to get into the case-sensitive vs. case-insensitive debate at the moment). So, rip it out. Or at least move it someplace on the keyboard away from the common keys. About that little LED above the numeric keypad the comes on when capslock is down. That's horrible design. Some keyboards, like the one on my iBook, have an LED in the capslock key itself, which is better, if you insist of having the key. I can see having the whole key be translucent and lit up when it's on.
Perhaps this is just my own biases. Ask yourself, though: when is the last time you turned on caps lock intentionally? Even when you type one of the many TLIs that are the bane of our industry, you probably just hold down the shift key -- even the "wrong" key: if you are QWERTY touch-typist, holding down the left shift with your left pinky while typing "T" is the wrong key.
So yes, it's time to say goodbye to the capslock key. Make the tab key bigger, perhaps.
Steve McConnell wrote about this in his book After the Gold Rush, in a chapter entitled "Orphans Preferred". He slams the heroic crunch coding style of programming and gives his ideas for a saner, more professional, development process.
>I'm currently working in a big project that involves creating tons of reports
Ahh, there's your problem right there. Now, the reports are static, meaning they are standards, run at specific intervals.
When a business asks for "some reports", it's an indicator that they only have an implicit, at best, understanding of their own business process. They treat the computer as a big bin in which to dump "facts" and generate some output in standard formats which they use to do manual analysis and processing. If your application consists primarily of reports, this is a smell because:
It's an indicator of incomplete or vague user needs. Essentially, a request for a report means "Gather a bunch of data and show it to me nicely formatted". Fine, but what exactly do all the pretty rows and columns tell you? Discover the true "why" for the report, and the need for the report evaporates.
Reporting tools often cast domain objects in the role of dumb data containers. Instead of having useful business-oriented behavior, classes that otherwise would define suitable behaviors are diminished to just carrying around values from one location (usually an RDBMS) to another location, a piece of paper.
There is a certain implication that the reports, once defined and written, never change and will always be what is necessary. Stories of reports that continue for years being generated and sent to people who never use them or even know why they are getting them are not uncommon.
The typical reporting run, being a batch-and-queue process, can wreak havoc with the functioning an interactive system while the reporting is occurring. Reports against databases often do expensive table scans, killing performance for users doing transactional work. They exercise the object model in ways that are different enough from live transactional usage, and the tradeoffs between what's right for reporting and what's right for interactive are difficult to resolve.
The request for a report is often a sign of an implicit idea that the computer can only do "data processing", and that the real analysis can only be done by hand. While that is still true for many classes of problems, the ability of programmers and systems to simulate and analyse is well advanced.
Reports are often artifacts of times before the user interface hardware and software had reasonable formatting capabilities. Low-resolution screens and the limited ability of a screen print to a low-quality local printer, for example, compared to the capabilities of generating formatted output to a centralized quality line printer. With modern user interfaces and hardware, the information is often presentable on the visual, and if not, printing from the application in suitably formatted and high-quality manner is quite easy.
All are complete PHB bullshit. Paying money for software doesn't guarantee any of these. For each of those points it's trivial to point out an example of the exact problem with closed-source/non-free software. Nothing in the license or EULA gives a company buying from any vendor any way to force that vendor to address these or any way to get damages after the fact. There's nothing behind those "reasons" but ignorance, a desire to build and keep little business fiefdoms, and single-skill tool custodians who'd lose their jobs if software just worked.
Slashdot Mirror
You mean the version that Microsoft has officially abandoned?
Hell I've seen so-called "programmers" do this with their development tools. Whenever they call me over to help with a problem and show me what they did and that demonstration includes clicking a dialog closed faster than I can read it, I just say, "Hmm, I need to look into this issue a bit. Let me get back to you."
From Earth to the Moon series is great, largely based on Andrew Chaikin's book, "A Man on the Moon", a great read. Tom Hanks did it, after doing Apollo 13. The book that movie is based on was written by Jim Lovell, the commander, and was originally called "Lost Moon". Also worth a read.
Regarding Steve Bales getting a medal, score a big one for the geeks.
>GIF is the only well-documented animation format that popular web browsers can display without a plug-in And the sooner the dancing spam dies, the better.
yeh! You need a website for it, though. goats.com is taken, how about goatse.cx?
You forgot:
0. A robot must never harm humanity.
1. (revised) A robot must never harm a human being unless that conflicts with the zeroth law.
Lone Star! +5 Funny
Well a proof of my own point -- miscommunicated what I was trying to say about mentoring. When I wrote that suggestion, I was referring to the specific context of within a company where they like formalized pre-packaged training and the training department is "in charge" of all employee training programs. My prediction is that the experiment as I suggested it will reveal an anti-mentoring bias among formal professional trainers.
You are correct, in tight-fisted companies there will be way more work than people to do it, and certainly no program to develop talented people up through experience.
I am more than happy to commit my knowledge to paper (or bits), because I know that the written information will likely be a ghostly echo of real knowledge. It is Hard to communicate explicit understanding through writing, and all but impossible to communicate the implicit knowledge that is the real value of experience. If a business were to attempt a moderately effective program of creating written records of the institutional knowledge of their people, they would quickly discover the cost and effort swamping the budget.
Most attempts to write documents for things that are contained in the practices and processes of the people, of which I have experience with a few, result in a listless pile of binders that few read and fewer get any understanding from. In the cases I've been involved with, once the written document was published to the organization, the calls and emails from people trying to understand and put into practice the material just added another demand on the time of person who has the knowledge.
Knowledge can't be effectively captured merely through writing it down for many reasons, but a good one is that not everyone learns most effectively by reading. On the other hand, so-called "social learning" techniques like those discussed in Situated Learning and The Social Life of Information are much better guides for how to retain and spread knowledge.
It appears common, however, that professional trainers are threatened by anything that would reduce the budget and power of the corporate training department. As an experiment, if your company is big into pre-packaged training materials, try getting a formal mentoring program going in your company.
Except, as the parent clearly pointed out, PMs don't have the qualifications either. At least as a software developer, I know how to do my job and can tell when someone telling me what to do is full of shit.
> customers are only asking about it because Microsoft is baiting them to - it doesn't really buy him anything to port.
.NET and lose 12 man-years and get wiped out by Microsoft anyway when they ship MSDesk for .NET.
Well that's exactly it. The article is a long hagiography on how great Joel says it is that the windows team has done everything possible to make it so old software continues to work, and hey, Windows is pretty darn good as it is, so please please, says Joel, don't make me port to
Joel's just whining because he knows he's going to have to port CityDesk and his other products to .NET soon, because customers are probably already asking about it. He's screwed by the same vendor lock-in that all other 3rd-party MS developers get blown away with. By the time his company is done with the port, MS will have thrown 3 times as many people at developing a "good enough" competing product that will ship ready for Longhorn, and Fog Creek will be just another assimilated victim.
Is it also possible that Joel's entire career and his company are centered on the last generation of MS technology, and they are about to become dinosaurs because they haven't kept up? It's very telling that he knows how expensive and rare Windows C++ programmers have become.
As for the free advertising, he's trying to convince those customers that have become trapped on the Microsoft upgrade treadmill (and are paying excessive subscription fees for the privilege) that everything is fine and dandy with the current Windows technology, and they should feel perfectly comfortable staying on 98 or NT as long as they keep buying FogCreek software and don't switch products before CityDesk is ready for Longhorn. A Longhorn Joel desperately hopes doesn't come charging through the door before his team can finish their rewrites.
Too bad the interviewer, Jorge Castro didn't press for details in clarifying a couple of Collins' statements. In speculating on what's wrong with Microsoft, Collins says it's hubris, "that they have all the answers, that they know what's right for you, but yet we keep getting more and more security patches from them, because they don't actually know what's right for us," and adds, "it is their hubris in knowing what people want, and saying "we know what is good for you," that is eventually going to pull them down. It's not going to be that somebody else actually knows better, because Microsoft actually does have a pretty good idea of what one generalized virtual person wants.". Yet when discussing FireFox default theme change for 0.9 Collins asserts, "Ben Goodger is the ultimate decider of what happens to Firefox, it's not a democracy, it's Ben Goodger, and that's fine."
It would have been great for Castro to dig a little deepr and ask Collins what makes Goodger knowing what's best for users different from the hubris Collins ascribes to Microsoft.
At the end of the story is a "Base Case" for the Stanford PeopleSoft/Oracle upgrade. There are three "Baseline Goals" listed that are just the start of wrong thinking in a project so full of wrong thinking (if the story is accurate) that it could be used as a the basis of a study of how not to run a enterprise software replacement.
To start with, it was inevitable that the close connections between the Stanford officials and the vendors would result in management blindness to problems. Either they would refuse to see problems, or the technical staff would be under tremendous political pressure to hide the problems.
Another dead wrong move: the "big bang" rollout. Of course the helpdesk and support folks were going to be overwhelmed. Things never work perfectly in the beginning, and what might have been limited to a small troubleshooting effort if they'd done a limited, staged rollout swamped everthing else with problems.
The complaint that the software was designed for a particular mainstream business process and not well suited for a university is reasonable in some respects. Yes, for the dollars spent, the software should be more flexible, and it is unreasonable to expect a university to re-engineer its process to fit the standard ERP model. On the other hand, if, as the story implies, the people running the project didn't realize in advance that university administrative computing is unlike private businesses they were wholly at fault for problems. At the very least, had they identified the areas where Stanford's processes could not be changed to match the software's expectations they would have known to budget more for the customizations.
Another problem mentioned in the story is the apparent disconnect between the IT people in charge of the project and the people expected to use the product. There are multiple mentions of the userbase feeling shafted by the results. Any large IT project that fails to include input from the people whose jobs require using the system constantly every day will be a textbook failure.
The story also mentions the CIO saying, "Stanford should distinguish itself through teaching and research, not unorthodox administrative processes that software vendors could standardize and ultimately make cheaper". This is a form of the increasingly common fallacy of "core business" that pops up a lot in management. The thinking is that a company should focus only on being better at whatever business it's in, and that the "non-core" things, like IT, should be standardized and outsourced. The fallacy is that it is generally impossible to separate a company's way of competing in business from the way it is structured and the support processes it has created. As an extreme example, take FedEx. Nominally they are just a shipping company. They collect boxes, move them around, and deliver them. But it is impossible to say that FedEx would be better by focusing on better box-handling and buying some standardized pre-packaged logistics software.
The real core of the problems, however, appears to be the bottom line, as stated in all three of the base case points:
In small words: do the same work with less money. Apparently, the rule of "cheap, fast, good: pick two" is no longer part of the vocabulary of management. Of course the users, and to some extent the poor overworked and underpaid techies tasked with making the steaming heap work, are the ones who actually end up with the burden of the cost, in money and time.
One final observation. Several slashdotters have commented on the apparent irony that a university with some of the smartest people in computer science screwed up this project so badly.
''Silicon carne'' Ha! I'm gonna steal that.
TODO: write shell command to apply above regex to all source files.
oooooo..... Thank you! That's going to give me a big push towards making FireFox my default browser.
But when do we get custom sidebar tabs in PheoBirdFox? Or is that part of the "bloat" that led to the split with the core Mozilla team?
Perhaps this is just my own biases. Ask yourself, though: when is the last time you turned on caps lock intentionally? Even when you type one of the many TLIs that are the bane of our industry, you probably just hold down the shift key -- even the "wrong" key: if you are QWERTY touch-typist, holding down the left shift with your left pinky while typing "T" is the wrong key.
So yes, it's time to say goodbye to the capslock key. Make the tab key bigger, perhaps.
Steve McConnell wrote about this in his book After the Gold Rush, in a chapter entitled "Orphans Preferred". He slams the heroic crunch coding style of programming and gives his ideas for a saner, more professional, development process.
Ahh, there's your problem right there. Now, the reports are static, meaning they are standards, run at specific intervals.
When a business asks for "some reports", it's an indicator that they only have an implicit, at best, understanding of their own business process. They treat the computer as a big bin in which to dump "facts" and generate some output in standard formats which they use to do manual analysis and processing. If your application consists primarily of reports, this is a smell because:
If the programmer and designer aren't the same person, I'd argue that the project is already in trouble. The source code is the design.
You're welcome. Let me know how it works out.
ArgoUML is the tool you want. BSD License.
- Informal support
- Velocity of change
- No roadmap
- Functional gaps
- Licensing caveats
- ISV endorsements
All are complete PHB bullshit. Paying money for software doesn't guarantee any of these. For each of those points it's trivial to point out an example of the exact problem with closed-source/non-free software. Nothing in the license or EULA gives a company buying from any vendor any way to force that vendor to address these or any way to get damages after the fact. There's nothing behind those "reasons" but ignorance, a desire to build and keep little business fiefdoms, and single-skill tool custodians who'd lose their jobs if software just worked.