June 2004 Archives
Todd Bishop talks about a poll Reliability vs. Features. Users were choosing "Software that works reliably" over "Software with innovative new features" with 95% over 5%.
Sorry to say, but that's bullshit.
What's reliability? Software isn't crashing? Software performs correct calculation (speaking in most generic terms)? Software performs calculation as user expects? Software has the feature set (both in breadth & depth) users expect? Software is "bug-free"? What's considered a "bug" - from a users point of view? From a vendors point of view?
Reliability isn't the absence of bugs. It's not about stability. It's about meeting the users expectations. And that's damned hard. Most of the time, it involves creating new features.
Exactly. As a third-party app, the Dashboard - uhm - Konfabulator concept is great. As part of the OS? Get real.
User friendly. Hilarious.
A couple of impressive features in MacOS 10.4 (Tiger). I like Spotlight, iChat AV conferencing, RSS in Safari etc.
However, it looks like Apple ran over the developers of Konfabulator and to some, way lesser extent, the various RSS readers.
Having been affected badly myself by Apple's decision to shelf OpenDoc in 1997, I think I qualify for some comments on this matter.
If you are working with a company much larger than yours providing you with software infrastructure (OS, host application etc.), there's always the risk of being run over. Especially if your application is pretty generic or fills a gaping hole in the hosting infrastructure.
Get over it. Shit happens. If you are as smart & creative as you think you are, you won't have trouble coming up with something new & even cooler tomorrow.
Note that I don't say Apple couldn't have done better.
Code Improvement Through Cyclomatic Complexity (via DevelopingStorm).
Interesting read. A couple of comments of yours truly:
- I don't think there's a need for metrics here. Applying common sense is sufficient. Do you have to scroll to read the whole message?. It's pretty likely that the method is too complex. More than 2 or three if..then..elses? It's pretty likely that the method is too complex.
- As the example on page 2 shows, you'll need to use good judgement when getting rid of cyclomatic complexity. Getting rid of intra-method complexity may introduce complexity on an architectural level. Although I prefer architectural complexity (or, for the lack of a better word - elaborate architecture) over cyclomatic complexity, I don't think getting rid of two if..then..elses justifies a substantial architectural change. If you re-visit those if..then..elses later on and you feel the need to add a few more if..then..else in the same method, go for the architectural change. But go for it when there's an actual need and not for the sake of architectural beauty.
Griechenland - Frankreich 1:0
Greece - France 1:0
Unglaublich. Unbelievable.
Leckere Auberginen Lasagne angefertigt aus Riste d'Aubergine. Direktimport aus Frankreich. Hersteller: Jean Martin. Tja, bei dem Namen kein Wunder daß das schmeckt.
Niederlande - Tschechien 2:3
Phantastisches Spiel. Man muß neidlos feststellen, daß es die deutsche Mannschaft nicht verdient hätte, ins Viertelfinale zu kommen.
Of course, I can't keep my mouth shut on Joel's latest rant How Microsoft Lost the API War.
Joel, keep in mind that there are lots of applications out there used by millions of customers which won't migrate to the web any time soon.
Do you really think Adobe, Autodesk, Microsoft, Lotus, Quark (just to name a few) will move their vastly successful rich-client applications to .NET/WinFX/... in the foreseeable future? Think again. Most likely, they will stick with their tools and technologies and APIs as long as possible. Which are based (way down in the systems where rubber meets road) Win32 on Microsoft Windows. And Carbon on MacOS.
Win32/MFC/COM etc. won't go away for a very long time. I agree, it has become an unholy mess. But we gotta deal with this mess.
A more interesting discussion on APIs would be: How do we marry existing application ecosystems, plug-in architectures and APIs with new technologies like .NET, scripting languages, ..insert-your-favorite-technology-here...?
For example, how do we enable an AutoCAD plug-in developer to take advantage of the productivity gains found in .NET?
Uhm, on a second thought, let me rephrase my example: How do we enable a VectorWorks plug-in developer to take advantage of the productivity gains found in .NET or Cocoa? :-)
Lot's of good advice here (from a "birds-eye-perspective-in-an-ideal-world-with-no-legacy-code", though) in the Introduction to Apple Software Design Guidelines. There's also a PDF version. (via Ranchero.com).
See also:
- Apple Human Interface Guidelines (PDF)
- Windows Guidelines for User Interface Developers and Designers
- Windows XP Visual Guidelines for Applications
Good read for anybody in geek-land. Advertising is hard. Marketing is super hard, too. (via Scobleizer)
My favorite quote:
"It always bothers me when people outside a discipline believe that it is trivially simple".
Airport Express. Pretty cool. I can even use it to extend the range of my wireless network.
I recently ran across a marketing blog talking about trying to be all things to all people. In this context it was recommended to focus on a small target market first, e.g. small & home office.
Just for the record.
Small & home office is not a target market. It's just a categorization of businesses in terms of size (no# of employees).
Haircutters are probably a small business. The local burrito take-out shop also qualifies as a small business. I'm pretty sure that the burrito shops' software requirements differ quite substantially from those of the haircutter next door.
Interesting enough, trades like woodworkers probably look like a target market, too. Look closer. They're not. There are folks specializing in doing kitchens, folks doing office furniture, folks doing restauration, shopfitters, folks specializing in windows or doors, folks designing and creating stairs etc. Most likely, a shop specializing in designing and producing windows has very different requirements from a shop doing stairs. And I'm just giving the birds-eye overview here.
Demoing Software for Fun & Profit. As Dave admits, the terminology is a little bit dated, but it's still a great read.
