April 2008 Blog Posts
Walking through the CBD it's difficult to miss the large number of people attempting to attract attention. They're a diverse group, including buskers, survey takers, various partisans attempting to extract donations and advertisers spruiking the pointless and inane. My approach to all of these is the same: I don't acknowledge their existence. This behaviour strikes many as rude, which is precisely what these people leech off. They're attempting to make you believe you have an obligation where no such obligation exists and take some of your time and generally some of your money as well. As your time and money...
Some software has an unfortunate tendency to assume that it's the most important thing ever to be executed on your computer. Programs of this type will add links to themselves in multiple menus and on your desktop, set themselves up as the handler for any file type vaguely related to their function and have themselves set to run at startup. This may be done for malicious reasons, but for software that's at least technically non-malicious it's done because the developers overestimate the utility of their software or just don't care that you're incurring an unnecessary overhead due to their software....
Pink Floyd is the greatest band of all time. Claims to the contrary are false.
Development teams are not static. Team members arrive and depart as the workload changes, staff quit, get reassigned or promoted or die in terrible hunting accidents. Whenever a new team member starts there is overhead before they can become productive. A large part of this is the familiarisation with the problem domain and solution under development. One element of it that is often overlooked is the effort required to establish a working development environment for the new developer.Setting up a development environment includes more than just providing a suitable machine (preferrably not hand me down junk no one else will...
So head over to his blog and subscribe for "all SOA, all the time" goodness.Yes, I am aware that everyone who reads this blog already reads Bill's.
My dishwasher broke down recently. Fascinating though this anecdote about appliance failure is, it does illustrate an important point. When the dishwasher repair guy showed up the dishwasher (naturally) worked as soon as he turned it on. At this point he could have claimed there wasn't a problem and left. Fortunately he instead pulled it out and found that the pump has a slow leak that would eventually trigger the safety switch.Unfortunately in the software world I've seen too many developers stop at the "it works for me" stage. A bug report comes from a tester or user. Developer says...
Over the years I've encountered a large number of graphic designers being required to write code. Generally this is because they're given responsibility for the user interface and this tends to encompass the code to drive the UI in addition to the look and feel. On the whole this has not been a great success, resulting in poorly maintainable, buggy code in the user interface layer. There is a tendency amongst developers to discount the importance of the user interface layer ("So you're saying this is two shades too blue? I care why, exactly?") but this ignores the significance of...
My colleague Bill Poole gave a presentation last night on SOA at the Perth .NET Community of Practice. To those who didn't make it you missed a highly informative tour of the fundamentals of SOA. My only real criticism is that a discussion of service boundaries would have eliminated some of the audience questions (No, I'm not just suggesting that because it was my comment when I reviewed the powerpoint slides before the presentation).These are the kind of presentations that make user groups worthwhile. Attendees get to learn about new topics or see how other people conceive and apply them....
How many times do I have to hang up on telemarketers before they realise I'm never going to listen to their spiel, let alone fall for it. Surely they track these things. It's wasting your money and time (which I approve of) but also mine (which I don't). Just stop it, you evil, evil scum.End of rant.
There appears to be no force on earth capable of stopping some people writing bad code. I strongly suspect that in the event of nuclear holocaust the only things to survive will be cockroaches and terrible programmers, which seems unfair on the cockroaches. But this doom and gloom shouldn't stop you from using Visual Studio to at least put some minor speedbumps in their way. Given that we're all one global armageddon from being terrible programmers ourselves making use of these facilities in your development projects is a good idea.I really hate code that produced compiler warnings. Compiler warnings are...
Telling a co-worker that a good way to ensure he keeps his MVP status is to start his own cult is probably reckless...especially when there's a non-zero chance he will. I might as well be handing out the Kool-Aid myself.Also, recommending he uses the word "Lo" more may not endear me to the people he sits near.
It's well known that software projects fail, by going over budget, producing a solution that is wrong, or by just not producing a working system at all. This has been well addressed and everyone has their own silver bullet to fix it (none of which work quite like they are promissed to). I'm not going to discuss these alleged fixes (mostly because being overrun by methodology partisans is not my idea of fun). I'm instead going to occassionally discuss a sign that your project is in trouble.
Today's sign is focusing more on presentation than the fundamental operation of the system....
Software is much like an iceberg, partially in the sense that it can cause massive disasters, but mostly in the sense that there's a lot to it that's hidden from the end user. This has some consequences for software development. End users will tend to measure your progress based on the elements they can see. This can severely distort their view of the progress being made. At one end if your interface components are still rough and incomplete they will assume that the entire system is rough and incomplete, even if the majority of the system is progressing well. Conversely...