17 December 2009
Well done, Jason!
Congratulations to Jason on becoming the first family-member to get published:
Implement Automatic Discovery in Your Java Code with Annotations — Developer.com
10 September 2009
Network Disasters Happen in Threes Fours
Only 9 more sleeps to go...
Strike 1: Last week, disaster struck in the form of a 2-day DSL outage. Telkom -- my current DSL provider -- blithely went and cleared the fault ticket after 24hours -- without any consultation with me -- because their test centre said that my router was getting a connection to the local exchange. The ticket comment was, "Fault closed at customer request." Liars!
Much wailing and gnashing of teeth later, they discovered that a whole lot of people in the area were experiencing the same problems: very sporadic connectivity with almost no traffic getting through. Turned out to be a fault on the exchange itself.
Strike 2: On the same day that this problem started, my London-housed server went down for Reasons Unknown. Of course I was blissfully unaware of it until Friday. 2 days of server outage. Then my service provider there was terribly slow to rectify the problem (which -- as the universe will insist upon -- involved a fractal nesting of sub-problems with their own sub-sub-problems ad mandelbrot.) As I write, the server is still only partially up. Apache service -- the one my paying customers rely on -- is up and working fine on one IP address, but Tomcat, hosting my personal and "corporate" sites, blogs and wikis still cannot talk through the other IP address. The service I get from VAServ is pretty kak, but not so kak as to be noteworthy -- they really are giving me a very low-cost package, and, as always, You Gets What You Pays For.
Strike 3: At the same time an FTP backup service I use for offsite backups refused to authenticate me, using the same credentials I've been using for years, with the result that I could not even ensure the safety of all the data! Be Still, My Twitching Ulcer.
You're Out: Welcome to this morning, where we present -- for your entertainment and edification -- a reprise of last week's DSL outage. Telkom, predictably, and once again, are in complete denial that there is actually a problem. Their tests show a solid connection between my router and their exchange. No shit, Sherlock! Pity the bits can't squeeze through the tiny opening.
I've always been very happy with the ISP service I've received from WebAfrica, and have, over the years, put many friends and colleagues onto them, not one of whom has had anything less than Sterling service. I've asked WA to take over my DSL service1, too, in light of recent events. The only bit of business Telkom will be getting from me for the foreseeable future will be POTS.
Only 9 more sleeps to go...2
I think this sorry whining actually has a point; it tends to back up my long-held belief that telcos are constitutionally incapable of competently running IP services. The cultures and philosophies that make end-to-end controlled networks are unable to comprehend -- in some weirdly deep, DNA-level way -- how to cope with IP networks which have almost no intelligence in the middle, but live, instead, with all the intelligence at the edges.
People who run IP networks, on the other hand, are able to provide perfectly adequate voice services over IP, which is why they're going to eat the telcos' lunch over the long term.
[1] There's no transfer/installation fee. Their monthly rates are at present the same as Telkom's, and as they roll out their own infrastructure, they anticipate reducing the charges. Their support desk is outstanding, staffed by people who actually know stuff, don't mind admitting mistakes and problems, treat customers like Real Humans instead of problem-id's, and follow through on promises and commitments and ensuring that things get fixed. I can't see any downside, can you?
[2] Of course, it occurs to me a little late, that I'll only be able to actually post this when I get the server working properly again. Which will only happen when I get some reasonable connectivity back. Which might happen slightly after Lucifer goes skiing from his front doorstep.
Strike 1: Last week, disaster struck in the form of a 2-day DSL outage. Telkom -- my current DSL provider -- blithely went and cleared the fault ticket after 24hours -- without any consultation with me -- because their test centre said that my router was getting a connection to the local exchange. The ticket comment was, "Fault closed at customer request." Liars!
Much wailing and gnashing of teeth later, they discovered that a whole lot of people in the area were experiencing the same problems: very sporadic connectivity with almost no traffic getting through. Turned out to be a fault on the exchange itself.
Strike 2: On the same day that this problem started, my London-housed server went down for Reasons Unknown. Of course I was blissfully unaware of it until Friday. 2 days of server outage. Then my service provider there was terribly slow to rectify the problem (which -- as the universe will insist upon -- involved a fractal nesting of sub-problems with their own sub-sub-problems ad mandelbrot.) As I write, the server is still only partially up. Apache service -- the one my paying customers rely on -- is up and working fine on one IP address, but Tomcat, hosting my personal and "corporate" sites, blogs and wikis still cannot talk through the other IP address. The service I get from VAServ is pretty kak, but not so kak as to be noteworthy -- they really are giving me a very low-cost package, and, as always, You Gets What You Pays For.
Strike 3: At the same time an FTP backup service I use for offsite backups refused to authenticate me, using the same credentials I've been using for years, with the result that I could not even ensure the safety of all the data! Be Still, My Twitching Ulcer.
You're Out: Welcome to this morning, where we present -- for your entertainment and edification -- a reprise of last week's DSL outage. Telkom, predictably, and once again, are in complete denial that there is actually a problem. Their tests show a solid connection between my router and their exchange. No shit, Sherlock! Pity the bits can't squeeze through the tiny opening.
I've always been very happy with the ISP service I've received from WebAfrica, and have, over the years, put many friends and colleagues onto them, not one of whom has had anything less than Sterling service. I've asked WA to take over my DSL service1, too, in light of recent events. The only bit of business Telkom will be getting from me for the foreseeable future will be POTS.
Only 9 more sleeps to go...2
I think this sorry whining actually has a point; it tends to back up my long-held belief that telcos are constitutionally incapable of competently running IP services. The cultures and philosophies that make end-to-end controlled networks are unable to comprehend -- in some weirdly deep, DNA-level way -- how to cope with IP networks which have almost no intelligence in the middle, but live, instead, with all the intelligence at the edges.
People who run IP networks, on the other hand, are able to provide perfectly adequate voice services over IP, which is why they're going to eat the telcos' lunch over the long term.
[1] There's no transfer/installation fee. Their monthly rates are at present the same as Telkom's, and as they roll out their own infrastructure, they anticipate reducing the charges. Their support desk is outstanding, staffed by people who actually know stuff, don't mind admitting mistakes and problems, treat customers like Real Humans instead of problem-id's, and follow through on promises and commitments and ensuring that things get fixed. I can't see any downside, can you?
[2] Of course, it occurs to me a little late, that I'll only be able to actually post this when I get the server working properly again. Which will only happen when I get some reasonable connectivity back. Which might happen slightly after Lucifer goes skiing from his front doorstep.
27 May 2009
Word processors
If Word Processors are to Words as Food Processors are to Food.... no wonder they're so bloody awful to use!
15 May 2009
Backups
Nice story on /. this morning about a faulty backup strategy gone wrong and its consequences. I'll bet a lot of smalltime operators are checking their backups this morning.
I know I am ;-)
I know I am ;-)
14 May 2009
MikroBlog Brainstorm, Part One
Part one of a wiki-essay on "Thinking about a new/different way of doing blogging... and about what blogging is all about...
"
Original at: http://mikro2nd.net/bits/Wiki.jsp?page=MikroBlog
Comments/constructive criticism welcome; be aware, though, that Part One is just painting background for a brainstorm, and not intended as a comprehensive, or even accurate, Recent History Of Blogging. Still very much a Work In Progress!
Past
Blogging in the conventional manner -- having a blog at BlogSpot or LiveJournal or WordPress or even at your own domain using some custom blog platform -- it all seems a bit passè, now, after the hype and frenzy of a couple of years ago.
The format is very much that of a newspaper article, isn't it? Headline, dateline, reporter, article. Even TV reporters follow the format. Oh, except for the commenting, of course! And ratings. That's what was so exciting; a new form of conversation. Two different kinds of conversation, really.
The first is the __News Mode__ conversation. It's a ''broadcast'' mode, primarily; News from me and my world to y'all out there who might be interested in following my drivel. Great for venting. Later that morphed into podcasts -- where did that all go to? -- and photoblogs, but it's all much the same thing. Think of Life Magazine in the 50's and 60's. That's why the mainstream news-media has managed, though it took them long enough, to successfully incorporate blogs and the blog style of things into their websites and mainstream content: it's not so very different from what they were doing before blogs came along. Though let's note in passing that many of them are still extremely uncomfortable with the free-and-easy, short-and-to-the-point, frequently vituperative style that commenters use. There's still a whole lot of this style of blogging going on, and I don't think it is going to disappear.
[{Image src='http://www.adfreeblog.org/adfreebutton.jpg' width='150' height='56' align='right' style='' class='image' }] It can be demanding, though, for the C-list bloggers like Yours Truly. Bloggers with, perhaps, a couple of dozen regular readers who share some niche common interests, read and comment regularly on each others' blogs, and, over time, become friends-at-a-distance. These are the bloggers who are not in it for the money. On their sites you'll see "Proudly Ad-Free" badges. They tried AdSense, and made the grand sum of 32 cents from it. The pressure from all those "How to be a Successful Blogger" websites... the feelings of having let people down should you fail to blog three times a week on a regular schedule... keeping that blogroll up to date... acknowledging all the comments... keeping the comment-spam under control... It all becomes too much after a time, and we see many of these C-listers give up their blogs after a couple of years. Sad, really, because many of them bring a fresh, interesting, if slightly myopic, story to the world.
The idea that bloggers were going to replace conventional journalism with news-from-the-streets... where did that go? Sadly not too many bloggers are keen to follow the Courts beat, nor to drag about after boring political hacks looking for the stuff the mainstream media masticates into news.
But! The conversation is peculiarly stilted. You leave a comment on someone's blog. Perhaps they reply via another comment. Perhaps somebody else comments on your comment. You probably never get to see that. Did you bookmark that conversation? Unlikely! And even if you did, will you remember to go back and visit the bookmark? You might comment on half-a-dozen blogs on any given day. It's a hell of a lot of work keeping up with all those conversations!
There have been various technical fixes to the problem -- email notifications on comment follow-ups, websites that follow the conversation for you and attempt to centralise it -- but none of these have been particularly successful. So as a means of actual conversation, conventional blogging comes up deficient.
But it did get us started, didn't it? We're all writing and conversing much more than we were a decade ago when we were still mainly a television audience -- mere passive consumers of the torrent of crap deemed by the Media Powers to be in our best interests -- and their way of ramming crappy advertorial down our collective gullets.
Original at: http://mikro2nd.net/bits/Wiki.jsp?page=MikroBlog
Comments/constructive criticism welcome; be aware, though, that Part One is just painting background for a brainstorm, and not intended as a comprehensive, or even accurate, Recent History Of Blogging. Still very much a Work In Progress!
Past
Blogging in the conventional manner -- having a blog at BlogSpot or LiveJournal or WordPress or even at your own domain using some custom blog platform -- it all seems a bit passè, now, after the hype and frenzy of a couple of years ago.
The format is very much that of a newspaper article, isn't it? Headline, dateline, reporter, article. Even TV reporters follow the format. Oh, except for the commenting, of course! And ratings. That's what was so exciting; a new form of conversation. Two different kinds of conversation, really.
The first is the __News Mode__ conversation. It's a ''broadcast'' mode, primarily; News from me and my world to y'all out there who might be interested in following my drivel. Great for venting. Later that morphed into podcasts -- where did that all go to? -- and photoblogs, but it's all much the same thing. Think of Life Magazine in the 50's and 60's. That's why the mainstream news-media has managed, though it took them long enough, to successfully incorporate blogs and the blog style of things into their websites and mainstream content: it's not so very different from what they were doing before blogs came along. Though let's note in passing that many of them are still extremely uncomfortable with the free-and-easy, short-and-to-the-point, frequently vituperative style that commenters use. There's still a whole lot of this style of blogging going on, and I don't think it is going to disappear.
[{Image src='http://www.adfreeblog.org/adfreebutton.jpg' width='150' height='56' align='right' style='' class='image' }] It can be demanding, though, for the C-list bloggers like Yours Truly. Bloggers with, perhaps, a couple of dozen regular readers who share some niche common interests, read and comment regularly on each others' blogs, and, over time, become friends-at-a-distance. These are the bloggers who are not in it for the money. On their sites you'll see "Proudly Ad-Free" badges. They tried AdSense, and made the grand sum of 32 cents from it. The pressure from all those "How to be a Successful Blogger" websites... the feelings of having let people down should you fail to blog three times a week on a regular schedule... keeping that blogroll up to date... acknowledging all the comments... keeping the comment-spam under control... It all becomes too much after a time, and we see many of these C-listers give up their blogs after a couple of years. Sad, really, because many of them bring a fresh, interesting, if slightly myopic, story to the world.
The idea that bloggers were going to replace conventional journalism with news-from-the-streets... where did that go? Sadly not too many bloggers are keen to follow the Courts beat, nor to drag about after boring political hacks looking for the stuff the mainstream media masticates into news.
But! The conversation is peculiarly stilted. You leave a comment on someone's blog. Perhaps they reply via another comment. Perhaps somebody else comments on your comment. You probably never get to see that. Did you bookmark that conversation? Unlikely! And even if you did, will you remember to go back and visit the bookmark? You might comment on half-a-dozen blogs on any given day. It's a hell of a lot of work keeping up with all those conversations!
There have been various technical fixes to the problem -- email notifications on comment follow-ups, websites that follow the conversation for you and attempt to centralise it -- but none of these have been particularly successful. So as a means of actual conversation, conventional blogging comes up deficient.
But it did get us started, didn't it? We're all writing and conversing much more than we were a decade ago when we were still mainly a television audience -- mere passive consumers of the torrent of crap deemed by the Media Powers to be in our best interests -- and their way of ramming crappy advertorial down our collective gullets.
28 April 2009
Code as Exploration of Unknown Territory
I have come to view coding as the act of exploring and charting unknown territory -- the wilderness of our cognitive space.
If we let it, as we go along, our code illuminates the crevices and crags of our understanding, and shapes as it goes, our ideas of where to go next.
Version-control is the key mapping tool.
I've just reached a point in the development of the mikroblogging tool where I (finally!) believe I understand what's needed; what might work as something new-ish and interesting-ish in the conversations we have over this Internet thingie...
It's not a conventional website like Twitter or Blogger. It's not a standalone desktop/PC-installed system doing some sort of smart p2p stuff. It's not a conversation follower nor a search tool nor a Bayesian-interest-detector. More something hybrid from all of these.
Let's see where the code will take me next...
If we let it, as we go along, our code illuminates the crevices and crags of our understanding, and shapes as it goes, our ideas of where to go next.
Version-control is the key mapping tool.
I've just reached a point in the development of the mikroblogging tool where I (finally!) believe I understand what's needed; what might work as something new-ish and interesting-ish in the conversations we have over this Internet thingie...
It's not a conventional website like Twitter or Blogger. It's not a standalone desktop/PC-installed system doing some sort of smart p2p stuff. It's not a conversation follower nor a search tool nor a Bayesian-interest-detector. More something hybrid from all of these.
Let's see where the code will take me next...
21 April 2009
Sun and Oracle
TL;DR: A fucking disaster for everybody except Oracle and Sun's execs and (maybe) shareholders. i.e. The Kakistocracy wins and the rest of us get shafted. (As usual.)
I think Oracle are getting an absolute bargain. $7.4 billion is chump-change for the IP they're acquiring. The question is, Which pieces are they going to keep, and which are toast? Some of this is blatantly obvious, other bits are pure crystal-ball-gazing on my part.
Java: the no-brainer. Oracle are heavily invested in Java for the Enterprise stack. Bad news for open-source Java? Maybe! Or maybe not... it all depends on whether Oracle were backing Apache simply as a tactic against Sun in the JCP. I've heard a number comments along the lines of "it's GPL -- the boat has sailed". They're forgetting that the owner of the IP can do as they please, including closing the source completely in the next release. (Not that I think it very likely; just a possibility.) Yes, an open-source community might be able to follow, but I'm betting that there would be compatibility problems.
MySQL: Toast. (Personally I never bought the logic behind Sun acquiring MySQL, and then they went and mishandled the whole thing badly.)
Glassfish: More toast. What will this be... Oracles fourth appserver? I lose count.
Netbeans: A cold shaft of ice pierces my gut. I love Netbeans. I just don't much like its competitor (just a personal preference; don't read too much into it!) But I fear that this might be the end of the road for NB... OTOH it can -- unlike so many of Sun's other open-source projects -- probably survive, nay flourish, as a standalone open-source IDE. After all, that where it came from in the first place.
OpenOffice.org: Makes perfect sense for Oracle. I bet on them keeping this one going. In fact, this might be the Secret Weapon Acquisition... the knife with which Oracle goes seriously for Microsoft's jugular in the Enterprise space, together with Solaris and the Sun hardware.
Solaris: I'm betting it stays. Oracle's strategy has been (to the limited extent I bother to keep track) to lock up the mission-critical, "hard-to-do" stuff in the Enterprise space. And there's still a whole lot of stuff that Solaris does way better than Linux.
VirtualBox: also plays well into the Enterprise/datacentre "integrated offering" strategy.
JavaFX: not one I'm capable of guessing about... any offers?
And the Sun hardware: makes pretty good sense for Oracle, in my limited understanding.
On a more personal note, much closer to home: How likely is it that Oracle will retain Sun's training programs for Java? Methinks it unlikely, since they already have their own training programs. What does that mean for the first Sun-authorised Java trainer in Africa?
Not good news at all, I'll bet!
All-in-all I think the acquisition is terrible news for Sun people, and probably not good news for their customers, either. I am finding it hard to see it in a good light for Java, either, and, having (literally) bet the farm on Java for the past 13 years, find the prospects quite discouraging. And for open-source in general it's a disaster. Despite the Slashdot whiners, Sun has sunk an incredible amount of money and effort into open-source projects, and I simply don't believe that Oracle has the same largeness of vision.
Oh well. Shit happens. I suppose its still a step better than Sun going under completely... Best I get a move-on with further developing my own training material and courseware.
I think Oracle are getting an absolute bargain. $7.4 billion is chump-change for the IP they're acquiring. The question is, Which pieces are they going to keep, and which are toast? Some of this is blatantly obvious, other bits are pure crystal-ball-gazing on my part.
Java: the no-brainer. Oracle are heavily invested in Java for the Enterprise stack. Bad news for open-source Java? Maybe! Or maybe not... it all depends on whether Oracle were backing Apache simply as a tactic against Sun in the JCP. I've heard a number comments along the lines of "it's GPL -- the boat has sailed". They're forgetting that the owner of the IP can do as they please, including closing the source completely in the next release. (Not that I think it very likely; just a possibility.) Yes, an open-source community might be able to follow, but I'm betting that there would be compatibility problems.
MySQL: Toast. (Personally I never bought the logic behind Sun acquiring MySQL, and then they went and mishandled the whole thing badly.)
Glassfish: More toast. What will this be... Oracles fourth appserver? I lose count.
Netbeans: A cold shaft of ice pierces my gut. I love Netbeans. I just don't much like its competitor (just a personal preference; don't read too much into it!) But I fear that this might be the end of the road for NB... OTOH it can -- unlike so many of Sun's other open-source projects -- probably survive, nay flourish, as a standalone open-source IDE. After all, that where it came from in the first place.
OpenOffice.org: Makes perfect sense for Oracle. I bet on them keeping this one going. In fact, this might be the Secret Weapon Acquisition... the knife with which Oracle goes seriously for Microsoft's jugular in the Enterprise space, together with Solaris and the Sun hardware.
Solaris: I'm betting it stays. Oracle's strategy has been (to the limited extent I bother to keep track) to lock up the mission-critical, "hard-to-do" stuff in the Enterprise space. And there's still a whole lot of stuff that Solaris does way better than Linux.
VirtualBox: also plays well into the Enterprise/datacentre "integrated offering" strategy.
JavaFX: not one I'm capable of guessing about... any offers?
And the Sun hardware: makes pretty good sense for Oracle, in my limited understanding.
On a more personal note, much closer to home: How likely is it that Oracle will retain Sun's training programs for Java? Methinks it unlikely, since they already have their own training programs. What does that mean for the first Sun-authorised Java trainer in Africa?
Not good news at all, I'll bet!
All-in-all I think the acquisition is terrible news for Sun people, and probably not good news for their customers, either. I am finding it hard to see it in a good light for Java, either, and, having (literally) bet the farm on Java for the past 13 years, find the prospects quite discouraging. And for open-source in general it's a disaster. Despite the Slashdot whiners, Sun has sunk an incredible amount of money and effort into open-source projects, and I simply don't believe that Oracle has the same largeness of vision.
Oh well. Shit happens. I suppose its still a step better than Sun going under completely... Best I get a move-on with further developing my own training material and courseware.
13 April 2009
Twitter looks vaguely interesting. Not too much. Not enough for me to bother with it. I think it's very Flavour Of The Day.
But it does suit one thing I've had in mind for a while... the idea of a "stream of consciousness" blog sort of thing. Essentially a blog where I can just post a line or two or three, without all the formality and palaver of Subject lines, Categories, Tags, etc. In a nutshell, Twitter,but without the 140 character limit, and hosted on my own server as part of my own infrastructure.
Maybe I'll just write it....
<i>I need another development project like I need more holes in my head. Only two major development projects on the go at the moment, and a couple of minor ones.</i>
But it does suit one thing I've had in mind for a while... the idea of a "stream of consciousness" blog sort of thing. Essentially a blog where I can just post a line or two or three, without all the formality and palaver of Subject lines, Categories, Tags, etc. In a nutshell, Twitter,but without the 140 character limit, and hosted on my own server as part of my own infrastructure.
Maybe I'll just write it....
<i>I need another development project like I need more holes in my head. Only two major development projects on the go at the moment, and a couple of minor ones.</i>
26 March 2009
SL-275 and Java Programmer Certification
Midweek; past the halfway mark (in time, anyway) of teaching Sun's SL-275 "Java Programming Language" course. I wonder how many times I've taught this course over the past 12 years... I still love it! Even though its just the basics, there's something just plain fun about introducing Java to new minds.
This one is interesting; 5 of the students have flown from Stockholm, Sweden all the way to Cape Town, especially to attend this course! Wow! (Of course they might pick up some sunshine in the middle of the Northern Winter. I guess that may help. ;-)
The trouble is that Java has grown so large over the years that there's a hard choice: cover (mostly) everything in a shallow way? or leave a lot out to get more depth?
Add to that, Sun punt the course as "the" prerequisite for writing the Java Programmer Certification Exam. Frankly, I shudder at the thought! Programmers would need a lot more than just this course to be in a position to tackle the exam. And programmers who are in a good position to tackle the exam don't really need this course!
As it currently stands, the course is inadequate for students attending it in order to prepare for the Certification Exam. There's very little I can teach them and still remain reasonably close to the course materials. The course is pretty good as an intro to Java for experienced developers, but pressure from more experienced developers in the class -- especially when they are in a significant majority -- could, if I'm not careful and strong in controlling it, leave the less-well-versed-in-Java students stranded. (I assure you that I don't let this happen.)
The solution is to split the course in two. One would be a truly introductory course aimed at otherwise-experienced developers. And the second would avoid all basic material -- syntax of if statements, declaring classes and interfaces -- in favour of homing-in on the deeper, less well known details of Java execution that the Certification Exam aims to test.
I sure wish Sun would do it soon! It would make life so much easier for us trainers, and would deliver a much better focussed value to customers.
This one is interesting; 5 of the students have flown from Stockholm, Sweden all the way to Cape Town, especially to attend this course! Wow! (Of course they might pick up some sunshine in the middle of the Northern Winter. I guess that may help. ;-)
The trouble is that Java has grown so large over the years that there's a hard choice: cover (mostly) everything in a shallow way? or leave a lot out to get more depth?
Add to that, Sun punt the course as "the" prerequisite for writing the Java Programmer Certification Exam. Frankly, I shudder at the thought! Programmers would need a lot more than just this course to be in a position to tackle the exam. And programmers who are in a good position to tackle the exam don't really need this course!
As it currently stands, the course is inadequate for students attending it in order to prepare for the Certification Exam. There's very little I can teach them and still remain reasonably close to the course materials. The course is pretty good as an intro to Java for experienced developers, but pressure from more experienced developers in the class -- especially when they are in a significant majority -- could, if I'm not careful and strong in controlling it, leave the less-well-versed-in-Java students stranded. (I assure you that I don't let this happen.)
The solution is to split the course in two. One would be a truly introductory course aimed at otherwise-experienced developers. And the second would avoid all basic material -- syntax of if statements, declaring classes and interfaces -- in favour of homing-in on the deeper, less well known details of Java execution that the Certification Exam aims to test.
I sure wish Sun would do it soon! It would make life so much easier for us trainers, and would deliver a much better focussed value to customers.
18 January 2009
Open Course Development
It strikes me that, whilst I am deep into the design of a number of programming-related courses, I am making a terrible mistake. The mistake of not talking about what I'm up to. The mistake of assuming the entire burden of course development.
Instead I ought to be employing Open Source development principles. At least some of them. Seems to me that (at least) the Thousand Eyeballs principle applies quite well, at least to the course structure, content and sequencing.
Right now I'm in the thick of codesigning three courses that I (with good reason!) believe are served very poorly by the corporate training world, and I think I can design courses that deliver much, much better value for money. The three I'm busy with right now are "Elements of Object Oriented Programming", "OO Analysis and Design" and "Patterns of Software Design".
"Elements" is intended as an introductory foundation course for programmers coming from a non-OO background who want/need to learn the OO concepts quite quickly. Nobody in their right minds would believe that a 3-day "Elements"-style course is going to turn any Natural programmer into an OO expert... we all know that the process of learning to Think Objects takes 9 months. But I do believe that it is possible to teach the foundation concepts really well.
"OO A&D" seeks to demystify the analysis and design process -- to the degree that it is possible to demystify an essentially creative process.
And, finally, the "Design Patterns" course aims to teach something useful about... well... design patterns. I've taught variations on this one numerous times over the years, but never really been satisfied with the value I was able to deliver, so I've completely rethought the approach from the ground up, and -- I think -- come up with something Just a Bit Different. A whole lot of the Design Patterns courses I've seen offered seem to add up to nothing more than a whole lot of droning through the GoF patterns catalogue. I think there's a whole bunch more to the topic than that, and I plan to use the course to explore that.
I've also outlined a whole bunch of other courses that I want to develop over the next year or so, but developing even these three is a daunting enough task for now.
I'm openly stealing some of the concepts -- the approach to teaching -- exemplified by the Head First books, and I'm really interested to see that O'Reilly are themselves developing a bunch of courses -- I gather they'll be web-based courses -- under the Head First brand. Good for them! It's about time we saw a better approach to teaching technical stuff.
So I'm aiming to make the courses colourful, interactive and fun. I'm trying to build in lots of of pictures, music, video, games, practical exercises, movement. (Trying to figure out how to include flavours and smells... ;-)
I've also been breaking away -- especially for the "Elements" course -- from linearity in the course sequencing. Essentially I'm developing using a Spiral Model. First introduce a concept, then go on to related concepts, etc., in time spiralling round to repeat the discussion of the topic in greater depth, and so on. I've long known that it is too easy to give too much detail all at once, so for my own course material, I'm explicitly shying away from that. I think it equates -- somewhat -- to the concept of Progressive Disclosure in user-interface design. As luck would have it, after several weeks working on this stuff, I tripped across this article just today, and went "Aha! Somebody else who Gets It!"
Right now I am stuck. Struggling to come up with good great practical ways of exploring the topic of "Encapsulation" in a way that doesn't stray too far from the way it's meant in OO programming, whilst remaining vaguely interesting.
As soon as I get the relevant bits of machinery up and running, I'll post the course outlines. (Will take a while: I am unexpectedly and suddenly off to London for a week for a spot of consulting work.)
Instead I ought to be employing Open Source development principles. At least some of them. Seems to me that (at least) the Thousand Eyeballs principle applies quite well, at least to the course structure, content and sequencing.
Right now I'm in the thick of codesigning three courses that I (with good reason!) believe are served very poorly by the corporate training world, and I think I can design courses that deliver much, much better value for money. The three I'm busy with right now are "Elements of Object Oriented Programming", "OO Analysis and Design" and "Patterns of Software Design".
"Elements" is intended as an introductory foundation course for programmers coming from a non-OO background who want/need to learn the OO concepts quite quickly. Nobody in their right minds would believe that a 3-day "Elements"-style course is going to turn any Natural programmer into an OO expert... we all know that the process of learning to Think Objects takes 9 months. But I do believe that it is possible to teach the foundation concepts really well.
"OO A&D" seeks to demystify the analysis and design process -- to the degree that it is possible to demystify an essentially creative process.
And, finally, the "Design Patterns" course aims to teach something useful about... well... design patterns. I've taught variations on this one numerous times over the years, but never really been satisfied with the value I was able to deliver, so I've completely rethought the approach from the ground up, and -- I think -- come up with something Just a Bit Different. A whole lot of the Design Patterns courses I've seen offered seem to add up to nothing more than a whole lot of droning through the GoF patterns catalogue. I think there's a whole bunch more to the topic than that, and I plan to use the course to explore that.
I've also outlined a whole bunch of other courses that I want to develop over the next year or so, but developing even these three is a daunting enough task for now.
I'm openly stealing some of the concepts -- the approach to teaching -- exemplified by the Head First books, and I'm really interested to see that O'Reilly are themselves developing a bunch of courses -- I gather they'll be web-based courses -- under the Head First brand. Good for them! It's about time we saw a better approach to teaching technical stuff.
So I'm aiming to make the courses colourful, interactive and fun. I'm trying to build in lots of of pictures, music, video, games, practical exercises, movement. (Trying to figure out how to include flavours and smells... ;-)
I've also been breaking away -- especially for the "Elements" course -- from linearity in the course sequencing. Essentially I'm developing using a Spiral Model. First introduce a concept, then go on to related concepts, etc., in time spiralling round to repeat the discussion of the topic in greater depth, and so on. I've long known that it is too easy to give too much detail all at once, so for my own course material, I'm explicitly shying away from that. I think it equates -- somewhat -- to the concept of Progressive Disclosure in user-interface design. As luck would have it, after several weeks working on this stuff, I tripped across this article just today, and went "Aha! Somebody else who Gets It!"
Right now I am stuck. Struggling to come up with good great practical ways of exploring the topic of "Encapsulation" in a way that doesn't stray too far from the way it's meant in OO programming, whilst remaining vaguely interesting.
As soon as I get the relevant bits of machinery up and running, I'll post the course outlines. (Will take a while: I am unexpectedly and suddenly off to London for a week for a spot of consulting work.)
30 December 2008
Teaching Servlets and JSP
It's the end of a week teaching Sun's SL-314 course -- "Web Component Development with Servlets and JSP" in Cape Town. It's been challenging and demanding, but, above all, fun! I had a great bunch of participants on the course, a couple of whom were old friends from an "Intro to Java" course (Sun's SL-275 course) some months ago.
The course materials are pretty good, although with a couple of misfeatures -- in my ever-so-humble opinion, as always -- and one glaring omission! (Never mind the details; I won't bite the hand that feeds me. This time. Rest assured that I've passed my thoughts on to the good people at Sun Education.) However, the whole sequencing and structure of the course has set me thinking, "How would I go about structuring such a course? What examples and challenges would I use for lab work?"
I take this teaching stuff pretty seriously1. So I'm always looking for ways to add value above and beyond what is offered by the course materials. Of course, the most valuable thing a trainer can bring into these sorts of skills-oriented technical courses is one's own experience actually using the technology on real-world projects. But beyond that, a lot of value can be added (or subtracted) by the sequence, timing and manner in which the material is presented. In a 5-day course time is terribly limited, so practical examples and labwork are necessarily very constrained, so it is very hard to work-up really good examples.
Setting examples and lab-work for courses is actually a very hard problem. You don't want to restrict the work to toy problems -- students pick up on that very quickly, and, even more quickly, lose interest in the course material, and, more importantly and with longer-term consequences for the remainder of the course, they lose respect for the course (and sometimes for the instructor, too.) On the other hand, time is very limited -- perhaps a couple of hours for any given issue, so extensive examples take too long to implement.
Then, too, one is in the position of trying to illustrate and/or reinforce key points in the course material, and developing actual code always involves a measure of extraneous detail -- housekeeping code. It adds nothing to the teaching purpose of the exercise, but it certainly chews into the time available!
And -- not to be neglected -- I think it is important that examples be at least a little bit entertaining. After all, we can do order-entry at work anytime... But there's a borderline across which "entertaining" becomes "irrelevant". (Much the same can be said of micro-benchmarks.)
Relevance? You wanted relevance from a blog post? As opposed to rambling?
OK.
I'm starting to put together my own material for a number of courses, centring around the gaps in the corporate professional training space (OO and Java technical matters, of course.) that I've been seeing over the past decade.
(Of course, now is a brilliant time to be putting my own course-material together. In times of economic downturn, the very first thing to get the axe is training! How short-sighted is that?)
[1] As with most things, the more you put into it, the more you get out of it!
The course materials are pretty good, although with a couple of misfeatures -- in my ever-so-humble opinion, as always -- and one glaring omission! (Never mind the details; I won't bite the hand that feeds me. This time. Rest assured that I've passed my thoughts on to the good people at Sun Education.) However, the whole sequencing and structure of the course has set me thinking, "How would I go about structuring such a course? What examples and challenges would I use for lab work?"
I take this teaching stuff pretty seriously1. So I'm always looking for ways to add value above and beyond what is offered by the course materials. Of course, the most valuable thing a trainer can bring into these sorts of skills-oriented technical courses is one's own experience actually using the technology on real-world projects. But beyond that, a lot of value can be added (or subtracted) by the sequence, timing and manner in which the material is presented. In a 5-day course time is terribly limited, so practical examples and labwork are necessarily very constrained, so it is very hard to work-up really good examples.
Setting examples and lab-work for courses is actually a very hard problem. You don't want to restrict the work to toy problems -- students pick up on that very quickly, and, even more quickly, lose interest in the course material, and, more importantly and with longer-term consequences for the remainder of the course, they lose respect for the course (and sometimes for the instructor, too.) On the other hand, time is very limited -- perhaps a couple of hours for any given issue, so extensive examples take too long to implement.
Then, too, one is in the position of trying to illustrate and/or reinforce key points in the course material, and developing actual code always involves a measure of extraneous detail -- housekeeping code. It adds nothing to the teaching purpose of the exercise, but it certainly chews into the time available!
And -- not to be neglected -- I think it is important that examples be at least a little bit entertaining. After all, we can do order-entry at work anytime... But there's a borderline across which "entertaining" becomes "irrelevant". (Much the same can be said of micro-benchmarks.)
Relevance? You wanted relevance from a blog post? As opposed to rambling?
OK.
I'm starting to put together my own material for a number of courses, centring around the gaps in the corporate professional training space (OO and Java technical matters, of course.) that I've been seeing over the past decade.
(Of course, now is a brilliant time to be putting my own course-material together. In times of economic downturn, the very first thing to get the axe is training! How short-sighted is that?)
[1] As with most things, the more you put into it, the more you get out of it!
15 November 2008
Brain Delayed - In Transit
On my way down to Cape Town -- yet again -- for a Java Intro course -- yet again...
On arrival at the checking-desk, get told that I'm not booked to go to Cape Town, but am eventually found to be on my way to George from Cape Town. Returning to Cape Town on Friday. Wow! What happened here? OK, so off to the booking office where I have to fork out an extra R700 to cover the ticket change. Fortunately the SAA staff at George and I know each other by first name. (As a result I seldom have to produce ID to check in -- most of the staff can ID me by sight. Beat that for personal service! ;-)
Sudden thought: Let's check the car rental reservation. Sure enough! I'm booked to pick up a car in George. Get that one changed. Things are so screwed up at this point that I called the B&B where I'm allegedly booked to stay in CT. Yes, indeed, they DO have a reservation for me.
WTF was somebody at the travel agency thinking? This guy is going to fly from Cape Town to George, pick up a car there, and then stay 5 nights in Cape Town before reversing the journey?
Now I only have to waste an extra hour-and-a-half in the airport. I just love hanging about in airports, don't you?
On arrival at the checking-desk, get told that I'm not booked to go to Cape Town, but am eventually found to be on my way to George from Cape Town. Returning to Cape Town on Friday. Wow! What happened here? OK, so off to the booking office where I have to fork out an extra R700 to cover the ticket change. Fortunately the SAA staff at George and I know each other by first name. (As a result I seldom have to produce ID to check in -- most of the staff can ID me by sight. Beat that for personal service! ;-)
Sudden thought: Let's check the car rental reservation. Sure enough! I'm booked to pick up a car in George. Get that one changed. Things are so screwed up at this point that I called the B&B where I'm allegedly booked to stay in CT. Yes, indeed, they DO have a reservation for me.
WTF was somebody at the travel agency thinking? This guy is going to fly from Cape Town to George, pick up a car there, and then stay 5 nights in Cape Town before reversing the journey?
Now I only have to waste an extra hour-and-a-half in the airport. I just love hanging about in airports, don't you?
25 September 2008
Back in the Saddle: Java 101
Interesting to be back in the Training Game. It is a Java 101 (Introduction to Java Programming for Programmers) course. With some differences.
Its all for one corporate client. My God, its been a long time since I had to deal with Corporate IT Thinking. There's some of it that exists for good reason. And then there's a whole lot of crap. Stuff that's more to do with politics, staking out of turf, ass-covering... The real downside for a Java 101 course is not so huge, but still... everybody is from the same organisation, though they might well be from different planets, considering the departments they're drawn from... But, there's still not a lot of cross-pollination of ideas. The whiff of groupthink.
I've taken the format of the "usual" 5-day course and adapted it somewhat to a 6-day format split over two 3-day sessions a couple of weeks apart, so there's a lot more breathing room, but, for any "Intro to X" course there is a certain body of knowledge that has to be covered, and there's a certain Logic to the order in which material has to be presented, so there's no escaping... There's just a bunch of stuff that has to get taught before people can realistically handle a tutorial (a.k.a. "homework".) All resulting in a pretty heavy First Three Days. I've just finished Day 3 ("Subscriber Trunk Dialing".) I'm exhausted.
Differences: In the usual "5-day" format I'd have to be really winding up my energy to stay the pace for Day 4. This time around I get a week-long break, and get to start fresh. Mmmmm... Gooooood!
Happily I have a fairly bright bunch. Quite a mix of backgrounds, all the way from a university graduates to "just-a-programmer-can-I-google-a-solution-and-cut-n-paste-the-code". The usual chirpy heckler who borders, at times, on irritating, but helps keep things alive. The usual "deeply tech" who catches all my mistakes and omissions, and keeps me on my toes.
I'll confess that I'm having a ball!
Its all for one corporate client. My God, its been a long time since I had to deal with Corporate IT Thinking. There's some of it that exists for good reason. And then there's a whole lot of crap. Stuff that's more to do with politics, staking out of turf, ass-covering... The real downside for a Java 101 course is not so huge, but still... everybody is from the same organisation, though they might well be from different planets, considering the departments they're drawn from... But, there's still not a lot of cross-pollination of ideas. The whiff of groupthink.
I've taken the format of the "usual" 5-day course and adapted it somewhat to a 6-day format split over two 3-day sessions a couple of weeks apart, so there's a lot more breathing room, but, for any "Intro to X" course there is a certain body of knowledge that has to be covered, and there's a certain Logic to the order in which material has to be presented, so there's no escaping... There's just a bunch of stuff that has to get taught before people can realistically handle a tutorial (a.k.a. "homework".) All resulting in a pretty heavy First Three Days. I've just finished Day 3 ("Subscriber Trunk Dialing".) I'm exhausted.
Differences: In the usual "5-day" format I'd have to be really winding up my energy to stay the pace for Day 4. This time around I get a week-long break, and get to start fresh. Mmmmm... Gooooood!
Happily I have a fairly bright bunch. Quite a mix of backgrounds, all the way from a university graduates to "just-a-programmer-can-I-google-a-solution-and-cut-n-paste-the-code". The usual chirpy heckler who borders, at times, on irritating, but helps keep things alive. The usual "deeply tech" who catches all my mistakes and omissions, and keeps me on my toes.
I'll confess that I'm having a ball!
11 September 2008
Infrastructure Fix
Finally! Took a day off from preparing for the (Advanced Architecture and Design) course I'm hosting next week, and spent the time getting my local infrastructure back on its feet after a breakdown some weeks ago. Basically the LAN server died... motherboard or CPU. Suddenly we realised just how much we've come to depend on that little machine! DNS caching, plus names for all the machine on our farm-LAN1, HTTP proxy, local Subversion server, file-share, music streaming, and not to mention supplying the base-infrastructure for some Jini services that come and go as we play around with Jini and JavaSpaces.
So now that we've beefed-up the CPU and disk a bit, it was "just" a case of getting all the bits of server software installed and cleanly configured. Nothing difficult, but it all takes time! Especially when you're a bit.... fastidious?... about getting the config "right", as opposed to "just poking things until they work". I truly despise "voodoo config" where people don't really make the effort to understand the impact and effects of what they're doing, and fuck it up royally as a result. "Oh, well, I'll install mod_disk_cache and mod_mem_cache... after all, two caches must be better than one, mustn't they?" Ding! You Do Not Win The Lounge Suite!
Well, its been fun! And finally I can forget all about it again until the next hardware failure. The only thing I really would like to achieve is to get the server quiet2, and get its power-consumption way, way down! And maybe have a few more tiny-little servers...
[1] The term "server farm" takes on a whole new significance ;-)
[2] Yeah, I'm a complete arsehole about noise. I really, really, really hate noise...
So now that we've beefed-up the CPU and disk a bit, it was "just" a case of getting all the bits of server software installed and cleanly configured. Nothing difficult, but it all takes time! Especially when you're a bit.... fastidious?... about getting the config "right", as opposed to "just poking things until they work". I truly despise "voodoo config" where people don't really make the effort to understand the impact and effects of what they're doing, and fuck it up royally as a result. "Oh, well, I'll install mod_disk_cache and mod_mem_cache... after all, two caches must be better than one, mustn't they?" Ding! You Do Not Win The Lounge Suite!
Well, its been fun! And finally I can forget all about it again until the next hardware failure. The only thing I really would like to achieve is to get the server quiet2, and get its power-consumption way, way down! And maybe have a few more tiny-little servers...
[1] The term "server farm" takes on a whole new significance ;-)
[2] Yeah, I'm a complete arsehole about noise. I really, really, really hate noise...
22 August 2008
Courseware: The Next Step
Just received my Instructor's Manual (only a week late!) for Sun's SL-425 "Architecting and Designing J2EE Applications"1 and I'm very happy to see that it is basically the same course as the old "Architecture and Design" course I taught several times lo' those many years ago when I was so frequently on my feet as "Herr Instructor".
This is easily the best2 course I ever "taught"! It is aimed a senior, experienced designers and developers3, and confronts head-on the sticky few-good-answers stuff, the ill-defined and the fuzzy grey areas. I have always run the course in a round-table "workshop" format. When you get 8 or 10 senior developers into a room, each with a decade or two of experience, you're not going to be their Teacher. And you sure as hell better not have a tender ego. "I don't know" is a frequent answer. The job is much more one of facilitation: Keeping discussion on-track, drawing quieter participants into the discussion, acknowledging expertise and encouraging people to share their (often vast!) experience. I found it hugely enjoyable to engage with seriously expert people, and to facilitate drawing out their expertise. And I learned a lot!
It has been a very long time that I have wanted to run this course again, so I'm looking forward to it hugely!
So: I have a couple of weeks to catch-up on the changes since last it taught facilitated this course. Mainly the technology has caught up with the tech: Where there was only CORBA or RMI a decade ago, there are now a host of J2EE technologies, and the course now includes them. Where a decade ago the whole idea of enterprise-architecture patterns was pretty new and unheard-of, now there's the J2EE Blueprints Catalogue (even if those yanks can't spell "Catalogue"!)
Of course I'll probably be unable to resist the temptation fo slipping in a few sly teasers about Jini and Javaspaces -- but Hey! Sun seem to encourage instructors to go beyond the boundaries of the course material, and encourage us to bring our own experience into the classroom. Or workshop in this case.
I am still thinking about floating my own version of this course, perhaps a little less attached to Java tech, so that more people might engage. The absolutely best runs of the course were when we had many people from different organisations and backgrounds. Cross-pollination really works. Ask plants!
----
[1] Is there such a word as "Architecting"? My spelling-chequer doesn't seam to think sew.
[2] "Best" from my point of view, anyway. Though, I can honestly report that every participant I've ever had on this course reported exactly the same sentiment!
[3] I don't believe the term/job-title "Architect" had any currency back then. Whilst it had certainly been invented4 it was certainly not popular. In fact there still was no such Job Title as "Software Designer" back then. My boss had to invent it for me!
[4] I believe that I was one of the (probably many) inventors of "Software Architect"a s a job title. Certainly not unique in that, though! Back in 1989 a technical career-path looked much like "Junior Programmer - Programmer - SeniorProgramer - Junior Systems Analyst - Systems Analyst - Senior Systems Analyst - Business Analyst..." I rejected the whole deal5 stating "Analysis is The Art of Taking Things Apart. I don't want to do that. I want to put things together, and that's called Design (and, at the high-end, Architecture)."
[5] ... in a bi-annual merit-assessment that became (in)famous as the one where I told my Manager, "If you want loyalty, get a dog! This is a business relationship; didn't you understand that?" Needless to say I got no increase that year. ;-)
This is easily the best2 course I ever "taught"! It is aimed a senior, experienced designers and developers3, and confronts head-on the sticky few-good-answers stuff, the ill-defined and the fuzzy grey areas. I have always run the course in a round-table "workshop" format. When you get 8 or 10 senior developers into a room, each with a decade or two of experience, you're not going to be their Teacher. And you sure as hell better not have a tender ego. "I don't know" is a frequent answer. The job is much more one of facilitation: Keeping discussion on-track, drawing quieter participants into the discussion, acknowledging expertise and encouraging people to share their (often vast!) experience. I found it hugely enjoyable to engage with seriously expert people, and to facilitate drawing out their expertise. And I learned a lot!
It has been a very long time that I have wanted to run this course again, so I'm looking forward to it hugely!
So: I have a couple of weeks to catch-up on the changes since last it taught facilitated this course. Mainly the technology has caught up with the tech: Where there was only CORBA or RMI a decade ago, there are now a host of J2EE technologies, and the course now includes them. Where a decade ago the whole idea of enterprise-architecture patterns was pretty new and unheard-of, now there's the J2EE Blueprints Catalogue (even if those yanks can't spell "Catalogue"!)
Of course I'll probably be unable to resist the temptation fo slipping in a few sly teasers about Jini and Javaspaces -- but Hey! Sun seem to encourage instructors to go beyond the boundaries of the course material, and encourage us to bring our own experience into the classroom. Or workshop in this case.
I am still thinking about floating my own version of this course, perhaps a little less attached to Java tech, so that more people might engage. The absolutely best runs of the course were when we had many people from different organisations and backgrounds. Cross-pollination really works. Ask plants!
----
[1] Is there such a word as "Architecting"? My spelling-chequer doesn't seam to think sew.
[2] "Best" from my point of view, anyway. Though, I can honestly report that every participant I've ever had on this course reported exactly the same sentiment!
[3] I don't believe the term/job-title "Architect" had any currency back then. Whilst it had certainly been invented4 it was certainly not popular. In fact there still was no such Job Title as "Software Designer" back then. My boss had to invent it for me!
[4] I believe that I was one of the (probably many) inventors of "Software Architect"a s a job title. Certainly not unique in that, though! Back in 1989 a technical career-path looked much like "Junior Programmer - Programmer - SeniorProgramer - Junior Systems Analyst - Systems Analyst - Senior Systems Analyst - Business Analyst..." I rejected the whole deal5 stating "Analysis is The Art of Taking Things Apart. I don't want to do that. I want to put things together, and that's called Design (and, at the high-end, Architecture)."
[5] ... in a bi-annual merit-assessment that became (in)famous as the one where I told my Manager, "If you want loyalty, get a dog! This is a business relationship; didn't you understand that?" Needless to say I got no increase that year. ;-)
19 July 2008
Datapro/Vox Spam Wrapup
Its been a long, long time... way too long... since I promised to report back on my complaint to the ISPA in which I accused Datapro/Vox Telecom of being spammers.
The first part of the ISPA's complaint-handling procedure is to have the parties try and resolve matters between them. Datapro's attempt to brush me off was a laugh:
Datapro/Vox Telecom were found guilty of spamming, and fined R100 000 (about EUR10 000 at the time.)
Naturally Datapro appealed this decision, as was their right. Unfortunately the appeals process is quite a slow one, so it was only about 9 June that I was informed of the outcome of the appeals process:
On appeal it was found that Datapro/Vox Telecom were confirmed as being guilty of spamming (through address repurposing.) The fines were, however, reduced to R45 000, most of which has been suspended for 12 months, provided that Datapro/Vox do not spam again within that period of time. Effectively Datapro/Vox have had to pay a paltry R7 500 in fines. Their guilt remains undisputed.
This strikes me as the ISPA having no balls.
The Appeals Committee recomended that Datapro/Vox
The only communication I have had was on 3 June -- 8 days after the Appeal Ruling -- I received yet another marketing spam from Datapro/Vox... still no opt-out link, still no confirmed opt-in. I just have not had the time or energy to follow-up with another complaint of this violation of the suspension conditions imposed by the ISPA on Datapro/Vox.
Further, the ISPA's documentation carries a notice stating
so I am effectively barred from making the original PDFs available, despite (or perhaps because of) my having made it clear to the ISPA that it was my firm intention to publish the course of events and all documents.
I am also unable to find any notice, link or reference to this ruling on the ISPA website. Are they too afraid of the potential income-loss should one of their largest spammers members get pissed-off enough to depart the Association?
A pretty sorry indication of the general state of the local ISP industry, I'm afraid.
The first part of the ISPA's complaint-handling procedure is to have the parties try and resolve matters between them. Datapro's attempt to brush me off was a laugh:
- Part 1
- Pahttp://onemikro2nd.blogspot.com/2008/02/taking-on-spammers-dataprovox-telecom_21.htmlrt 2
- Pahttp://onemikro2nd.blogspot.com/2008/02/taking-on-spammers-dataprovox-telecom_21.htmlrt 3
- Part 4http://onemikro2nd.blogspot.com/2008/02/taking-on-spammers-dataprovox-telecom_21.html
Datapro/Vox Telecom were found guilty of spamming, and fined R100 000 (about EUR10 000 at the time.)
Naturally Datapro appealed this decision, as was their right. Unfortunately the appeals process is quite a slow one, so it was only about 9 June that I was informed of the outcome of the appeals process:
On appeal it was found that Datapro/Vox Telecom were confirmed as being guilty of spamming (through address repurposing.) The fines were, however, reduced to R45 000, most of which has been suspended for 12 months, provided that Datapro/Vox do not spam again within that period of time. Effectively Datapro/Vox have had to pay a paltry R7 500 in fines. Their guilt remains undisputed.
This strikes me as the ISPA having no balls.
The Appeals Committee recomended that Datapro/Vox
...ensure that a working opt-out facility is provided on all marketing emails and to report back to the ISPA complaints administrator within 1 (one) calendar month of receipt of this report on remedial action taken by it. The Appeals Panel recommended (which recommendation is not binding) that such remedial action should also include cleaning its email marketing lists to avoid a repetition of this complaint. This could be achieved by way of a reminder email requesting recipients to confirm their desire to continue receiving such emails (opt in), which is preferable, or by requesting them to indicate their preference not to receive such communications (opt out), which is adequate and then abiding by the indicated preference.To my knowledge none of this has happened. I have received neither an opt-in request, nor any opportunity to op-out.
The only communication I have had was on 3 June -- 8 days after the Appeal Ruling -- I received yet another marketing spam from Datapro/Vox... still no opt-out link, still no confirmed opt-in. I just have not had the time or energy to follow-up with another complaint of this violation of the suspension conditions imposed by the ISPA on Datapro/Vox.
Further, the ISPA's documentation carries a notice stating
PRIVATE AND CONFIDENTIAL:
All communication is confidential and may not be distributed.
See http://www.ispa.org.za/commsrules for more info.
I am also unable to find any notice, link or reference to this ruling on the ISPA website. Are they too afraid of the potential income-loss should one of their largest spammers members get pissed-off enough to depart the Association?
A pretty sorry indication of the general state of the local ISP industry, I'm afraid.
03 July 2008
Power to the Purple
A week of power-supply problems. Not Eskom's fault, this time, but more localised failures.
First the power-supply for the network server had a fan stop turning. I could have taken the chance on the unit working without cooling, since it is relatively lightly loaded -- no graphics cards, only a single disk -- but, since I had a spare power-supply unit handy it was a task of mere minutes to swap the faulty unit out and get the server back into action. It is a fairly key piece of our little home network, being a web-cache, local domain-name server and cache, Subversion repository and file-share space, so we miss it badly when it is down.
Then the power supply on my desktop machine decided to follow suit. Also a fan failure. I hate those crappy little fans! There's absolutely nothing wrong with the basic electronics of the power supply itself, but the ball bearings in the fan have died. Pricing for a new power-supply runs from a little over R100 if I were in Cape Town with easy access to wholesalers, through R200 from a web-shop, all the way to R300 from the local PC shops! This is for the most basic 350W PSU -- none of that fancy gaming-machine stuff for me. (Though I will confess to being tempted by a unit costing around R800, simply because it is alleged to be completely quiet! I'm a self-confessed anti-noise-maniac.)
My guess is I'm going to spend an hour messing about with the soldering iron, installing new fans (I have a couple just lying about) in the "faulty" power-supplies.
At the same time, several warnings from my server-supplier in London telling the story of a week-long tail-of-woe about power-supply into the datacentre. Apparently a failover switch failed to work correctly during a power-outage last Sunday, causing the battery-based UPS to take the entire load for about 10 minutes before the batteries were totally drained. All servers in the DC went down hard. It has taken them until Thursday to isolate the problem and replace the parts (electrical and mechanical) that were at fault.
During the whole affair, all server owners have been kept fully informed via RSS feeds and emails at every step of the way, since there is a risk (however slight) that servers might go down if there is a power-grid outage again and the on-site staff -- now fully briefed on managing a manual switch from grid power to the backup generator -- should get taken-up at just the wrong moment.
This is exactly the sort of thing I expect from server providers and datacentre operators. Everybody understand that, despite the best-laid plans, sometimes shit happens. It is how they respond, and how transparent and communicative they are in responding to the crisis that truly matters.
This is in very sharp contrast to Verizon's datacentre in Durban, where my other client's servers are housed. About 10 days ago they had some electrical work going on in the DC, which in turn made some server-moves necessary. They did all this without warning their clients that there might be some risk to their operations. Needless to say, my client's servers went down without warning in the wee hours of Sunday morning. No heartbeat monitoring in place, so it was Monday before anybody knew that something was wrong. No peep from Verizon to their customers. Half-arsed, I call it.
There's a lesson in all this about Single Points of Failure. I've been warning for over 8 months that having all the servers housed in a single DC, or even in a single city, is a risk. Maybe now the business will take some action, but, given the general lack of respect or attention to the fact that, like it or not, they are a technology business, I have my doubts.
First the power-supply for the network server had a fan stop turning. I could have taken the chance on the unit working without cooling, since it is relatively lightly loaded -- no graphics cards, only a single disk -- but, since I had a spare power-supply unit handy it was a task of mere minutes to swap the faulty unit out and get the server back into action. It is a fairly key piece of our little home network, being a web-cache, local domain-name server and cache, Subversion repository and file-share space, so we miss it badly when it is down.
Then the power supply on my desktop machine decided to follow suit. Also a fan failure. I hate those crappy little fans! There's absolutely nothing wrong with the basic electronics of the power supply itself, but the ball bearings in the fan have died. Pricing for a new power-supply runs from a little over R100 if I were in Cape Town with easy access to wholesalers, through R200 from a web-shop, all the way to R300 from the local PC shops! This is for the most basic 350W PSU -- none of that fancy gaming-machine stuff for me. (Though I will confess to being tempted by a unit costing around R800, simply because it is alleged to be completely quiet! I'm a self-confessed anti-noise-maniac.)
My guess is I'm going to spend an hour messing about with the soldering iron, installing new fans (I have a couple just lying about) in the "faulty" power-supplies.
At the same time, several warnings from my server-supplier in London telling the story of a week-long tail-of-woe about power-supply into the datacentre. Apparently a failover switch failed to work correctly during a power-outage last Sunday, causing the battery-based UPS to take the entire load for about 10 minutes before the batteries were totally drained. All servers in the DC went down hard. It has taken them until Thursday to isolate the problem and replace the parts (electrical and mechanical) that were at fault.
During the whole affair, all server owners have been kept fully informed via RSS feeds and emails at every step of the way, since there is a risk (however slight) that servers might go down if there is a power-grid outage again and the on-site staff -- now fully briefed on managing a manual switch from grid power to the backup generator -- should get taken-up at just the wrong moment.
This is exactly the sort of thing I expect from server providers and datacentre operators. Everybody understand that, despite the best-laid plans, sometimes shit happens. It is how they respond, and how transparent and communicative they are in responding to the crisis that truly matters.
This is in very sharp contrast to Verizon's datacentre in Durban, where my other client's servers are housed. About 10 days ago they had some electrical work going on in the DC, which in turn made some server-moves necessary. They did all this without warning their clients that there might be some risk to their operations. Needless to say, my client's servers went down without warning in the wee hours of Sunday morning. No heartbeat monitoring in place, so it was Monday before anybody knew that something was wrong. No peep from Verizon to their customers. Half-arsed, I call it.
There's a lesson in all this about Single Points of Failure. I've been warning for over 8 months that having all the servers housed in a single DC, or even in a single city, is a risk. Maybe now the business will take some action, but, given the general lack of respect or attention to the fact that, like it or not, they are a technology business, I have my doubts.
19 June 2008
Damager or Manager?
Since Open Letters to Management seem so flavour du jour, I thought I'd save the following fine rant from oblivion. Names and project details changed to protect the guilty, of course.
DumbTribe is a small startup in the mobile space. They have started seeing some good traction for their product, but are completely chaotic in their "management" of the company. The company is 100% reliant on IT, yet, whilst they're willing to spend an ordleplex of money on fancy new offices, they're astoundingly short of cash when it comes to things like buying another server to act as failover for their single server. Said server is the sole source of income for the business.
What [ManagerX] calls a "blogger tool" is really a form of Content Management system that ends up providing (among other things) Atom and RSS feeds...
[ManagerX] wrote:
> This has certainly taken longer than we initially thought it would. I
> think it was over a few of months back that we were expecting a
> finished blogger tool.
You seem to have forgotten that there were other tasks that YOU prioritised ahead of the "blog" tool -- development of the feed aggregator and the [BigClient] pilot, not to mention system administration tasks more numerous than I can recall, design and coding assistance to my colleague, installation and maintenance of essential technical infrastructure indispensable to organised development (some of which runs on my own servers, at no additional charge to [DumbTribe], simply because that was the fastest way to get the tools in place.) I regret that I am unable to work on more than one thing at a time, but these are rather complex systems dealing with some very erratic, "dirty" data coming-in, and, like most men, I don't multitask well.
> It is of zero use in it's present state(just like the blogger tool you
> created was in it’s 'unskinned' state(to me the level of things that
> fell under 'skinning' was surprising.
First: I warned right from the start that installation of the necessary software was the quick and easy part, but that changing templates -- "skinning" as you call it -- would take at least several days for someone expert in the templating system. I also made it clear that such templating was NOT in my sphere of competence. Evidently nobody was listening to the bits they didn't want to hear.
Second: I will not take responsibility for your inability to produce a coherent specification for the tool. Lack of any technical specification underlies the several misdirections and false starts. A powerpoint does not BEGIN to form a clear technical specification.
Example: I, at one stage, asked you how many "blogs" it is necessary for the system to support. At that time I had in mind to use a particular piece of software as the foundation infrastructure. Your answer to my question was "thousands!" which answer had a significant impact on my technical decision-making, since the tentatively-chosen solution is unsuited to such large volumes. I certainly made it clear that I was unfamiliar with the more suitable tool, and, indeed, the "skinning" -- the writing of custom templates -- turned out to be more problematic than I anticipated. I made a poor guess in the face of inadequate information, a misleading business requirement and insufficient time to evaluate alternative technical solutions.
In the long run it turned out that a "blog" system is just what [DumbTribe] does NOT need. What IS needed is an article/story management system for providing Atom/RSS feed output. This is in the final stages of development.
You seem to have forgotten that using a blog-system was initially mooted merely as a temporary stopgap solution to provide a mechanism for getting article content into feeds; it was never intended to be the "real" solution. What I have been developing is such solution. Assuming you don't sabotage delivery with yet another interruption.
I would have been finished 10 days ago had [my colleague] had enough spare hours to assist me on areas where I do not have the deep knowledge of data structures and code she already has in place, and if the "specification" had not been changed on a number of occasions. Unfortunately other more pressing issues have had to take precedence on her time, with resulting delays on the "blog" project. Furthermore the assistance I have (gladly) given [said colleague] on other projects has also had the effect of taking several days from "blog" development.
> I am sure you understand what this looks like from our end. It just
> feels like you can’t give us what we need.
Yes, I am pretty sure I DO understand. It seems to me that you think one of two things; either:
1. That I am incompetent to produce working software, or
2. That I am dishonest and lie to you about my activities.
I am neither, and find either accusation hurtful, denigrating, and completely unprofessional. Software development, unlike so many other jobs, does not allow one to delude oneself about the limits of ones knowledge or abilities, so the charge of incompetence is easier for me to dismiss when I consider its source; I know exactly how good I am.
Clearly you have absolutely no clue how software development works, nor what is a "normal" pace of production for software systems. The fact that your most-recent experience of software development is exemplified by [colleague], who is prepared, for reasons I cannot comprehend, to endanger her health and wellbeing by working outrageous hours in order to meet ridiculous, unrealistic and arbitrary deadlines does not alter the truth of what I am saying. Nor is it my place to attempt to teach you how software development works; for that sort of work I charge considerably more than you pay me.
The fact that you have badly under-resourced this area of the business is hardly my fault.
> I am so frustrated and feel if I have to explain what we need again I
> will go mad.
Unfortunately software is all about the detail. If you do not tell a developer all the detail that they need, they will guess, and likely guess wrong.
Therefore, where details are lacking I will ask again and again and again. I have on occasion asked users to describe their requirement from beginning to end as many as 8 times in a single day in order to be sure I understood the requirement. Then I asked them a couple more times the next day. I am deeply sorry if my need to know what you want in full detail drives you mad -- I certainly do not wish to cause such mental anguish.
> Please can you confirm that you understand and accept all the
> functionality that we need
No. I do not believe I understand what you need, particularly as you keep changing the requirements. I am not a mind-reader, and you have not produced a comprehensive technical specification.
Example: Your comment on Monday, "Make sure we can direct the 'see original story' link to a site of our choosing (e.g. [ClientA] sites or [ClientB] sites)" This directly CONTRADICTS the requirement laid out in your powerpoint that NO such link be present. What am I supposed to do with that? I can put such a link in (though linking to what, I have no idea, nor do you say -- another missing detail) or I can leave it out (as is done at present.) I am happy to do either, or to make any changes you require, since I understand that business requirements can and do change from time to time. However, changing what is already implemented does unfortunately take some time and cannot simply be done with a wave of a magic wand.
Example: The original requirement was for articles to have a single image attached. Then an image or a URL. Then multiple images or URLS. Then it became "unusable unless we can upload video". Then we didn't need video any longer. Then we were back to one image/URL. Currently I am informed that multiple images/URLS are a non-negotiable requirement. Every time a change such as this is introduced it costs me hours or days in the attempt to comply.
And you wonder why there have been delays.
My current aim is to get the system in place with the capability to upload ONE image or attach ONE URL, either of which shall appear at the tail-end of the feed content (another detail not specified.) It is my belief that it is better to get SOMETHING up and running, even though we all agree that it is NOT the end-product desired. Then we evolve it to the state we desire. After all, that is why it is called "soft"-ware.
> and let me know what *date* we can expect a working tool to start
> testing.
In the absence of a full, clear, comprehensive specification, no such estimate can be made by anybody. In effect you are waving your hands about, saying "build me a Tudor-style house over there" and then demanding that I tell you how long it is going to take without giving me the plans for the house, specifying the building materials, size of the house, number of bedrooms, etc. When you supply me with a proper User Requirement Specification -- for which I will gladly supply a Word template outlining all the necessary information it should contain -- I may consider beginning to make estimates.
> I don’t think it is unreasonable for me to ask you to commit to a
> deadline, the brief is surely clear now after all these emails back
> and forth and the very easily accessed example of blogger.com which I
> asked you to use as a starting point.
On the contrary I think it thoroughly unreasonable to make such demands. The "brief" (whatever THAT is) is non-existent. To point to blogger.com and claim that that is what you want is ridiculous, since blogger.com is totally unsuited to your needs. If it were suitable there would have been no need to build anything else and we would not be having this conversation.
I will remind you that I am contracted to deliver 40 to 80 hours per MONTH of work -- not per week. This was deliberately and clearly negotiated up front. Consequently I do not work full 8-hour days on DumbTribe activities, which, too has its effect on delivery schedules. The fact that I consistently seem to end up working more than the agreed number of hours per month seems to be taken for granted, or alternatively is regarded by you as an attempt to rip you off. On the contrary, it is a good-faith attempt to come some way further than I strictly, am contractually obliged, in an attempt to help DumbTribe meet its goals.
A lack of planning on your part does not constitute a crisis on my part.
In the extremely unlikely event that I elect to extend/renew my contract, should DumbTribe wish to do so, please be assured that I will require a considerable tightening-up of the conditions relating to all of these issues.
DumbTribe is a small startup in the mobile space. They have started seeing some good traction for their product, but are completely chaotic in their "management" of the company. The company is 100% reliant on IT, yet, whilst they're willing to spend an ordleplex of money on fancy new offices, they're astoundingly short of cash when it comes to things like buying another server to act as failover for their single server. Said server is the sole source of income for the business.
What [ManagerX] calls a "blogger tool" is really a form of Content Management system that ends up providing (among other things) Atom and RSS feeds...
[ManagerX] wrote:
> This has certainly taken longer than we initially thought it would. I
> think it was over a few of months back that we were expecting a
> finished blogger tool.
You seem to have forgotten that there were other tasks that YOU prioritised ahead of the "blog" tool -- development of the feed aggregator and the [BigClient] pilot, not to mention system administration tasks more numerous than I can recall, design and coding assistance to my colleague, installation and maintenance of essential technical infrastructure indispensable to organised development (some of which runs on my own servers, at no additional charge to [DumbTribe], simply because that was the fastest way to get the tools in place.) I regret that I am unable to work on more than one thing at a time, but these are rather complex systems dealing with some very erratic, "dirty" data coming-in, and, like most men, I don't multitask well.
> It is of zero use in it's present state(just like the blogger tool you
> created was in it’s 'unskinned' state(to me the level of things that
> fell under 'skinning' was surprising.
First: I warned right from the start that installation of the necessary software was the quick and easy part, but that changing templates -- "skinning" as you call it -- would take at least several days for someone expert in the templating system. I also made it clear that such templating was NOT in my sphere of competence. Evidently nobody was listening to the bits they didn't want to hear.
Second: I will not take responsibility for your inability to produce a coherent specification for the tool. Lack of any technical specification underlies the several misdirections and false starts. A powerpoint does not BEGIN to form a clear technical specification.
Example: I, at one stage, asked you how many "blogs" it is necessary for the system to support. At that time I had in mind to use a particular piece of software as the foundation infrastructure. Your answer to my question was "thousands!" which answer had a significant impact on my technical decision-making, since the tentatively-chosen solution is unsuited to such large volumes. I certainly made it clear that I was unfamiliar with the more suitable tool, and, indeed, the "skinning" -- the writing of custom templates -- turned out to be more problematic than I anticipated. I made a poor guess in the face of inadequate information, a misleading business requirement and insufficient time to evaluate alternative technical solutions.
In the long run it turned out that a "blog" system is just what [DumbTribe] does NOT need. What IS needed is an article/story management system for providing Atom/RSS feed output. This is in the final stages of development.
You seem to have forgotten that using a blog-system was initially mooted merely as a temporary stopgap solution to provide a mechanism for getting article content into feeds; it was never intended to be the "real" solution. What I have been developing is such solution. Assuming you don't sabotage delivery with yet another interruption.
I would have been finished 10 days ago had [my colleague] had enough spare hours to assist me on areas where I do not have the deep knowledge of data structures and code she already has in place, and if the "specification" had not been changed on a number of occasions. Unfortunately other more pressing issues have had to take precedence on her time, with resulting delays on the "blog" project. Furthermore the assistance I have (gladly) given [said colleague] on other projects has also had the effect of taking several days from "blog" development.
> I am sure you understand what this looks like from our end. It just
> feels like you can’t give us what we need.
Yes, I am pretty sure I DO understand. It seems to me that you think one of two things; either:
1. That I am incompetent to produce working software, or
2. That I am dishonest and lie to you about my activities.
I am neither, and find either accusation hurtful, denigrating, and completely unprofessional. Software development, unlike so many other jobs, does not allow one to delude oneself about the limits of ones knowledge or abilities, so the charge of incompetence is easier for me to dismiss when I consider its source; I know exactly how good I am.
Clearly you have absolutely no clue how software development works, nor what is a "normal" pace of production for software systems. The fact that your most-recent experience of software development is exemplified by [colleague], who is prepared, for reasons I cannot comprehend, to endanger her health and wellbeing by working outrageous hours in order to meet ridiculous, unrealistic and arbitrary deadlines does not alter the truth of what I am saying. Nor is it my place to attempt to teach you how software development works; for that sort of work I charge considerably more than you pay me.
The fact that you have badly under-resourced this area of the business is hardly my fault.
> I am so frustrated and feel if I have to explain what we need again I
> will go mad.
Unfortunately software is all about the detail. If you do not tell a developer all the detail that they need, they will guess, and likely guess wrong.
Therefore, where details are lacking I will ask again and again and again. I have on occasion asked users to describe their requirement from beginning to end as many as 8 times in a single day in order to be sure I understood the requirement. Then I asked them a couple more times the next day. I am deeply sorry if my need to know what you want in full detail drives you mad -- I certainly do not wish to cause such mental anguish.
> Please can you confirm that you understand and accept all the
> functionality that we need
No. I do not believe I understand what you need, particularly as you keep changing the requirements. I am not a mind-reader, and you have not produced a comprehensive technical specification.
Example: Your comment on Monday, "Make sure we can direct the 'see original story' link to a site of our choosing (e.g. [ClientA] sites or [ClientB] sites)" This directly CONTRADICTS the requirement laid out in your powerpoint that NO such link be present. What am I supposed to do with that? I can put such a link in (though linking to what, I have no idea, nor do you say -- another missing detail) or I can leave it out (as is done at present.) I am happy to do either, or to make any changes you require, since I understand that business requirements can and do change from time to time. However, changing what is already implemented does unfortunately take some time and cannot simply be done with a wave of a magic wand.
Example: The original requirement was for articles to have a single image attached. Then an image or a URL. Then multiple images or URLS. Then it became "unusable unless we can upload video". Then we didn't need video any longer. Then we were back to one image/URL. Currently I am informed that multiple images/URLS are a non-negotiable requirement. Every time a change such as this is introduced it costs me hours or days in the attempt to comply.
And you wonder why there have been delays.
My current aim is to get the system in place with the capability to upload ONE image or attach ONE URL, either of which shall appear at the tail-end of the feed content (another detail not specified.) It is my belief that it is better to get SOMETHING up and running, even though we all agree that it is NOT the end-product desired. Then we evolve it to the state we desire. After all, that is why it is called "soft"-ware.
> and let me know what *date* we can expect a working tool to start
> testing.
In the absence of a full, clear, comprehensive specification, no such estimate can be made by anybody. In effect you are waving your hands about, saying "build me a Tudor-style house over there" and then demanding that I tell you how long it is going to take without giving me the plans for the house, specifying the building materials, size of the house, number of bedrooms, etc. When you supply me with a proper User Requirement Specification -- for which I will gladly supply a Word template outlining all the necessary information it should contain -- I may consider beginning to make estimates.
> I don’t think it is unreasonable for me to ask you to commit to a
> deadline, the brief is surely clear now after all these emails back
> and forth and the very easily accessed example of blogger.com which I
> asked you to use as a starting point.
On the contrary I think it thoroughly unreasonable to make such demands. The "brief" (whatever THAT is) is non-existent. To point to blogger.com and claim that that is what you want is ridiculous, since blogger.com is totally unsuited to your needs. If it were suitable there would have been no need to build anything else and we would not be having this conversation.
I will remind you that I am contracted to deliver 40 to 80 hours per MONTH of work -- not per week. This was deliberately and clearly negotiated up front. Consequently I do not work full 8-hour days on DumbTribe activities, which, too has its effect on delivery schedules. The fact that I consistently seem to end up working more than the agreed number of hours per month seems to be taken for granted, or alternatively is regarded by you as an attempt to rip you off. On the contrary, it is a good-faith attempt to come some way further than I strictly, am contractually obliged, in an attempt to help DumbTribe meet its goals.
A lack of planning on your part does not constitute a crisis on my part.
In the extremely unlikely event that I elect to extend/renew my contract, should DumbTribe wish to do so, please be assured that I will require a considerable tightening-up of the conditions relating to all of these issues.
13 June 2008
Otherwise Occupied
Spending my time preparing for a course -- "Introduction to Java Programming" -- for a Major Corp in CT next week. It's a course I must have presented dozens of time. Perhaps hundreds. But its been about 5 or 6 years. Actually, I did teach it once a year or two ago... I'm sure the company I did the work for were satisfied. I'm pretty sure my students were mostly happy. I wasn't. The break from teaching had left me rusty. God knows how many tiny but important details I left out by mistake. Did I talk about volatile variables?
In a 5-day "intro" course, there's not much time to fuck about. There's a certain set of Java's features that you simply have to talk about, at least in a simplified and superficial way, simply because your students are guaranteed to trip across them almost immediately they walk out of the classroom.
On the other hand -- let's be honest -- there's a limit to what the human brain can absorb in 5 days!
This time around its a little different. I'm teaching for a single company. The Program Manager's focus seems to be quite squarely on getting her people up-to-speed, and not on any other corporate ass-covering or thinly-veiled-reward-holiday-for-week sort of bullshit. Believe me, I've seen that crap all too often!
I was able to stretch the course schedule to 6 days instead of 5 -- a huge relief and I can take things at a slightly less frantic pace. I frankly don't quite know how I would fit the basics into a 5-day course anymore, given that one has to cover (at least at a shallow level) enums, annotations and generics. I guess that maybe the modules on threading and concurrency would have to fall away, but how the hell do you justify doing that when you absolutely know that your students are -- willingly or un- -- going to confronted with those as soon as you can say "Boo"?
Well, I've been working hard at getting my teach up to scratch, updating the (Day 2) OO module to include enums, and the (Day 4) module on the Collections API to teach generics, etc., etc. Of course my (development) contract customer is a little miffed that I'm not putting in 18 hour days for them... Tough Tittie -- their time is worth about 1/4 what I'll earn from teaching, and they've hardly made any effort to improve the disgusting working conditions!
I think it will be a killer course. I'm certainly aiming to make it so!
Along the way, Jason and I have been having some very entertaining discussion about the deeper, occult details of Java concurrency and system design. Something clicked last night; we both reached the conclusion that it would be fun (and probably educational for all concerned) to get more people in on that conversation, so we've revived my idea-of-many-years-standing -- a workshop/seminar format gathering, aimed at top-level, ten-years-plus-experience OO designers, architects and senior developers: A general framework to guide and channel discussion, aiming for an honest sharing experiences and learning. No fluff!
I facilitated (I would hardly dare claim "taught") one such many years ago, and, in my own humble opinion, it was the best course I ever led! I think that quite a few of the participants would agree with me. Certainly a majority of them kept in touch with me for an otherwise inexcusable number of years afterwards! After all this time, there still exists a huge gap in the professional-education space... beyond a certain level, expert practitioners (and I think it is true of any field, not just software design) have nobody to talk to -- nobody around them who is at a level where they can meaningfully push back on ideas -- nobody to brainstorm with. Or at least, far too few. The Advanced Practitioner Workshops would aim to try and (partially) fill that vacuum.
So maybe its back to teaching again for a while! It could be fun to focus on actually delivering actual deep learning for a change instead of just aiming to be Brilliant Clown For A Week!
In a 5-day "intro" course, there's not much time to fuck about. There's a certain set of Java's features that you simply have to talk about, at least in a simplified and superficial way, simply because your students are guaranteed to trip across them almost immediately they walk out of the classroom.
On the other hand -- let's be honest -- there's a limit to what the human brain can absorb in 5 days!
This time around its a little different. I'm teaching for a single company. The Program Manager's focus seems to be quite squarely on getting her people up-to-speed, and not on any other corporate ass-covering or thinly-veiled-reward-holiday-for-week sort of bullshit. Believe me, I've seen that crap all too often!
I was able to stretch the course schedule to 6 days instead of 5 -- a huge relief and I can take things at a slightly less frantic pace. I frankly don't quite know how I would fit the basics into a 5-day course anymore, given that one has to cover (at least at a shallow level) enums, annotations and generics. I guess that maybe the modules on threading and concurrency would have to fall away, but how the hell do you justify doing that when you absolutely know that your students are -- willingly or un- -- going to confronted with those as soon as you can say "Boo"?
Well, I've been working hard at getting my teach up to scratch, updating the (Day 2) OO module to include enums, and the (Day 4) module on the Collections API to teach generics, etc., etc. Of course my (development) contract customer is a little miffed that I'm not putting in 18 hour days for them... Tough Tittie -- their time is worth about 1/4 what I'll earn from teaching, and they've hardly made any effort to improve the disgusting working conditions!
I think it will be a killer course. I'm certainly aiming to make it so!
Along the way, Jason and I have been having some very entertaining discussion about the deeper, occult details of Java concurrency and system design. Something clicked last night; we both reached the conclusion that it would be fun (and probably educational for all concerned) to get more people in on that conversation, so we've revived my idea-of-many-years-standing -- a workshop/seminar format gathering, aimed at top-level, ten-years-plus-experience OO designers, architects and senior developers: A general framework to guide and channel discussion, aiming for an honest sharing experiences and learning. No fluff!
I facilitated (I would hardly dare claim "taught") one such many years ago, and, in my own humble opinion, it was the best course I ever led! I think that quite a few of the participants would agree with me. Certainly a majority of them kept in touch with me for an otherwise inexcusable number of years afterwards! After all this time, there still exists a huge gap in the professional-education space... beyond a certain level, expert practitioners (and I think it is true of any field, not just software design) have nobody to talk to -- nobody around them who is at a level where they can meaningfully push back on ideas -- nobody to brainstorm with. Or at least, far too few. The Advanced Practitioner Workshops would aim to try and (partially) fill that vacuum.
So maybe its back to teaching again for a while! It could be fun to focus on actually delivering actual deep learning for a change instead of just aiming to be Brilliant Clown For A Week!
03 June 2008
UI Design Encourages Mistakes, Boosts Profits
Having just finished my banking and tax admin for the month, I fire up the bank's online system to fork the money over to the various landsharks, fatcats and leeches.
To make the various tax payments I first have to select which of my accounts to use for paying. Then I select who I want to pay. (For some value of "want".) The system insists that you click the "Search" button to check that you have entered the corect payee account details, but, of course, it only tells you this after you navigate away to the next page, and, when you return to the payment details form, it throws away all the details you have already captured.
I also have to enter a 19-digit reference number and, guess what, if I get it wrong (as I am likely to do with such a long number) it only tells me on the next page, and, again, throws away all the work I have done to fill in the form, forcing me to redo it from scratch. Including forcing me to redo the payee "Search", despite the fact that my browser has captured the field details perfectly.
The real kicker is that it also ditches the account-number from which I want to make payment, substituting the "default" account (which happens to be my personal account and not the business account) Of course, the account number is metres away up at the top of the web-page, so I don't notice that I'm making payment from the wrong account.
As a result I pay business taxes out of my personal account. When I eventually discover my mistake, I have to transfer the money over from my business account to fix things. And I am going to get hit with the withdrawal fees again. To add insult to injury, the payment pushes my personal account into overdraft. Bam! Overdraft fees!
This UI is so wrong, in so many way, you would think that the bank would have "inspired" and "motivated" to fix this monstrosity years ago. Do you wonder why Standard Bank can't be "bothered" to fix their broken user-interface? Do you wonder why they make incredible profits?
Did you think the two facts are unrelated?
To make the various tax payments I first have to select which of my accounts to use for paying. Then I select who I want to pay. (For some value of "want".) The system insists that you click the "Search" button to check that you have entered the corect payee account details, but, of course, it only tells you this after you navigate away to the next page, and, when you return to the payment details form, it throws away all the details you have already captured.I also have to enter a 19-digit reference number and, guess what, if I get it wrong (as I am likely to do with such a long number) it only tells me on the next page, and, again, throws away all the work I have done to fill in the form, forcing me to redo it from scratch. Including forcing me to redo the payee "Search", despite the fact that my browser has captured the field details perfectly.
The real kicker is that it also ditches the account-number from which I want to make payment, substituting the "default" account (which happens to be my personal account and not the business account) Of course, the account number is metres away up at the top of the web-page, so I don't notice that I'm making payment from the wrong account.
As a result I pay business taxes out of my personal account. When I eventually discover my mistake, I have to transfer the money over from my business account to fix things. And I am going to get hit with the withdrawal fees again. To add insult to injury, the payment pushes my personal account into overdraft. Bam! Overdraft fees!
This UI is so wrong, in so many way, you would think that the bank would have "inspired" and "motivated" to fix this monstrosity years ago. Do you wonder why Standard Bank can't be "bothered" to fix their broken user-interface? Do you wonder why they make incredible profits?
Did you think the two facts are unrelated?
20 May 2008
Invisible Work
Here's a great quote from Jim Waldo, courtesy of Dan Creswell's Blitz blog:
…Even worse than not being visible to the customer, work done on designing the system is not visible to the management of the company that is developing the system. Even though managers will pay lip service to the teaching of The Mythical Man Month, there is still the worry that engineers who aren’t producing code are not doing anything useful. While there are few companies that explicitly measure productivity in lines-of-code per week, there is still pressure to produce something that can be seen. The notion that design can take weeks or months and that during that time little or no code will be written is hard to sell to managers. Harder still is selling the notion that any code that does get written will be thrown away, which often appears to be regression rather than progress.Never a truer word!
08 May 2008
Reprise
My week for being haunted by old ghosts.
A bit more than a week, actually... It all started last Thursday with a call from a lady working with a lot of organisations that support HIV counselling, treatment and management. A lot of organisations. She had tripped (how?) across a product/project that a few of us put together some years ago that we called Projectory. Projectory is a collaboration and communication platform, specifically aimed at software-development organisations and teams. Think of CollabNet. But better, of course! ;-) Certainly quite different in some key ways! Except we never got the business off the ground, mostly through an unlucky turn of events that resulted in us losing key sales people at a most critical time.
My caller was wondering whether the Projectory platform could be adapted to help them to communicate, collaborate and coordinate better with a couple of hundred other organisations. Well, we've set up a meeting for next week, and we'll see... What a blast from the past, though! I had all-but-forgotten about Projectory... Thankfully I have the code archived away somewhere safe.
And then it happened again. A call from an ex-colleague a couple of days ago: Could we put together a rough estimate and proposal for a social-networking platform for World Cup 2010. In case you're living in a cave (or the USA where "football" means something completely weird) South Africa will be hosting the 2010 Soccer World Cup, and, for South Africans, it is a very big deal. This is, after all, the second biggest sport event in the world after the Olympics. (China get the hell out of Tibet!) The weird bit is that what's being asked for is very, very close to the project we called Flightwish -- a social-networking platform centred around group travel opportunities and concepts. We failed to get funding for Flightwish, though we tried hard. Normally I would favour a small-start, organic-growth, little-or-no-funding startup model, but that path is clearly a very poor fit for a Grow-Big-Fast webalicious venture. Since then, a few others have started playing in that space, but I have yet to see any of them put together the exact combination of ingredients we planned. Would we have done better? Who knows?
But now we may just get a chance to try it again.
Key takeaways:
A bit more than a week, actually... It all started last Thursday with a call from a lady working with a lot of organisations that support HIV counselling, treatment and management. A lot of organisations. She had tripped (how?) across a product/project that a few of us put together some years ago that we called Projectory. Projectory is a collaboration and communication platform, specifically aimed at software-development organisations and teams. Think of CollabNet. But better, of course! ;-) Certainly quite different in some key ways! Except we never got the business off the ground, mostly through an unlucky turn of events that resulted in us losing key sales people at a most critical time.
My caller was wondering whether the Projectory platform could be adapted to help them to communicate, collaborate and coordinate better with a couple of hundred other organisations. Well, we've set up a meeting for next week, and we'll see... What a blast from the past, though! I had all-but-forgotten about Projectory... Thankfully I have the code archived away somewhere safe.
And then it happened again. A call from an ex-colleague a couple of days ago: Could we put together a rough estimate and proposal for a social-networking platform for World Cup 2010. In case you're living in a cave (or the USA where "football" means something completely weird) South Africa will be hosting the 2010 Soccer World Cup, and, for South Africans, it is a very big deal. This is, after all, the second biggest sport event in the world after the Olympics. (China get the hell out of Tibet!) The weird bit is that what's being asked for is very, very close to the project we called Flightwish -- a social-networking platform centred around group travel opportunities and concepts. We failed to get funding for Flightwish, though we tried hard. Normally I would favour a small-start, organic-growth, little-or-no-funding startup model, but that path is clearly a very poor fit for a Grow-Big-Fast webalicious venture. Since then, a few others have started playing in that space, but I have yet to see any of them put together the exact combination of ingredients we planned. Would we have done better? Who knows?
But now we may just get a chance to try it again.
Key takeaways:
- I suck at Sales and driving Sales, therefore I am a poor fit for CEO of a startup.
- Flightwish taught me a deep hostility to the idea of a single "window of opportunity"; it's rubbish.
- Beware the Websites Of Yesteryear! You put up a website. It's out there. You forget about it. Google doesn't! Fix them up or shut them down.
- The "social" potential -- the ways that the web opens-up for collaboration and group communication -- we've barely scratched the surface of what's possible.
- VC people in SA are mostly bankers with fancier job titles. And we all know the collective noun for bankers, don't we...
30 April 2008
Software Estimation Considered Harmful
problem
"So how long do you think it's going to take?"
We've all been asked the question a thousand times and more. Project Managers, Client Liaison, Salespeople, Marketing Managers,... they all want to know. And we, like sheep, like the suckers we are, because we try to please (you try, too, please!) suck hard on our spacebar-calloused thumbs, and guess.
"I guess a couple of days."
"A week."
"Three months."
"A year; maybe 14 months."
Nobody really trusts those really long guesses, though, so that's where the project management experts get involved, break the task down into itty, tiny bitty little bits, parallelise them, ALAP, ASAP, lead and lag. And then we all sit down around a table, and for each and every one of the itty tiny bitty bits the project manager asks the dreaded question.
"So how long do you think that one's going to take?"
The Real Answer, the Truest Truth, is, "I don't know." Perhaps a tiny voice deep inside our soul cries out, "I don't care! It is going to take as long as it takes." But for mysterious reasons all tangled up in our wetware, all tied up in the social hierarchy dynamics of the human ape and those twisty strand of ribonucleic acid in our hardware, "I don't know" marks me as less-than-competent. And "I don't care" is career limiting; "Not a team player. Fails to identify with the organisations goals and ethos."
So we guess, and we guess, and we guess again. And we're (almost) always wrong!
For 50 years we, as a craft, as an industry, have been guessing wrong. For 50 years our projects have mostly finished "late", and we keep wondering "Why?" Books have been written, Methodologies developed, PhDs awarded, Management Disciplines imposed and entire Consulting Industries built on the premise that it is ''possible'' to estimate software effort better than we presently do. Or, if we can't estimate better, then we can manage the estimation risk better. Or the process. Or those pesky damn programmers.
All in vain. The projects keep coming in late.
where it all comes from
How did this abysmal state come about?
I think it is rooted back in the 1950's, when the first Big Software projects were undertaken, most notably by the US military. Quite naturally they applied the project management strategies that have worked for them since time beyond time. Strategies that have successfully built forts, dug moats, laid siege to cities and moved large numbers of soldiers across continents and seas. The trouble is that those are extremely well understood problems that have been solved thousands -- millions -- of times, ever since Akkad invaded Ur. For such classes of problems, estimates of time and effort are pretty reliable. If you're a logistics planner, an army engineer, you know, from loads of practice and handbooks distilling five thousand years of experience, just how long it takes for a boatload of soldiers to move a given distance, and just how much food, water and fuel they need along the way.
Software development is a different sort of beast. It's all new to us. Amost every problem has never been tackled in its entirety before. I don't claim that software development is unique in this; I am pretty sure that developers of new aircraft, ship engines, new forms of bridges, all face the same problems as software development. What -- perhaps -- distinguishes software development is that it's all new every time! We never get to repeat our past developments. If we were repeating -- exactly -- repeat-developing a requirement -- in every detail -- we would already have the code and we'd have no need to write anything! And if there's one thing I've learned about developers, its that we -- most of us -- hate doing the same thing twice! It's probably a function of our predisposition towards ADD/ADHD.
all change
But, no! In truth there are always differences between the Systems That Have Gone Before, and the Systems We're Developing Now. Even if you've developed interface to a dozen payment gateways, 100 gets you 1 that the next payment gateway has some unique characteristics all its own. Or perhaps some key technology has undergone a significant change in the last few years. Or some new tech has crept into the picture. "Our service is provided through a RESTful API"...
Then, too, how do you account for the Buggerance Factor. Murphy's Law. The simple fact that even the simplest piece of software depends on a ''huge'' number of other bits'n'pieces being in exactly the right places, configured exactly right, at exactly the right time?
I should not have had to spend an hour this morning tracking down the fact that a key library -- a jarfile that should always exist in a standard, accessible place -- had mysteriously been Taken Up. Vaporised. Gone. Perhaps my disk is going flaky? It shouldn't have happened. I should not have wasted an hour figuring out why the application wouldn't run. But I did.
I should not have spent a morning last week discovering that, despite the Vendor's persuasive assurances to the contrary, the version 8.2 driver does emphatically not work properly with the version 8.1 server. Let us not even ask the question, "Who installed the 8.2 driver?" A fruitless waste of time, energy and stress hormones.
How the hell do you predict that particular morning and figure it into your time and effort estimate? Or the half-day spent figuring out that there's a bug in a key data-access library you're using (and it's not your choice that mandated its use, but some arbitrary "policy".) And then another hour figuring out a way to work around the bug. Just how exactly, when you're Project Planning some 4 months ahead of a frustrating and unproductive morning, do you predict those?
You just blew your estimate.
managing estimation risk
I am well aware of various approaches to software development that try to futz around the problem -- some of them with some marginal success -- by giving up the idea of a project being "finished". But nobody seems willing to confront the central problem head-on.
Estimating "How Long It Will Take" is a Broken Idea.
Like the drunk looking for his spectacles under the streetlight "Because that's where I can see to look for them" we keep searching for ways to make estimation more accurate, more reliable, more amenable to conventional management thinking. What we really need to do is screw our courage to the sticking point, and accept that there is, really, honestly, truly, no alternative:
We must completely abandon the whole concept that software effort is amenable to estimation at all.
call to arms
Give up the crutch!
The next time -- and every time after that -- that someone asks you "So how long do you figure that's going to take?" -- "So when do you think we can go live?" -- Just Say No!
Just say, "It will take as long as it takes."
I guarantee you some excitement in the short minutes immediately following, but let go of your fear! Immediately you will find yourself skulling in the calm pond of assurance and truth that lies beyond the fear. Live and enjoy this Truth, for it will set you free. If other people want and need to make deadline commitments, let them be the ones to suck their thumbs, making up fantasies and lies. Do not allow them to push that responsibility onto you. Don't allow them to turn you into the liar. Just tell them,
It takes as long as it takes. It always does, anyway!
"So how long do you think it's going to take?"
We've all been asked the question a thousand times and more. Project Managers, Client Liaison, Salespeople, Marketing Managers,... they all want to know. And we, like sheep, like the suckers we are, because we try to please (you try, too, please!) suck hard on our spacebar-calloused thumbs, and guess.
"I guess a couple of days."
"A week."
"Three months."
"A year; maybe 14 months."
Nobody really trusts those really long guesses, though, so that's where the project management experts get involved, break the task down into itty, tiny bitty little bits, parallelise them, ALAP, ASAP, lead and lag. And then we all sit down around a table, and for each and every one of the itty tiny bitty bits the project manager asks the dreaded question.
"So how long do you think that one's going to take?"
The Real Answer, the Truest Truth, is, "I don't know." Perhaps a tiny voice deep inside our soul cries out, "I don't care! It is going to take as long as it takes." But for mysterious reasons all tangled up in our wetware, all tied up in the social hierarchy dynamics of the human ape and those twisty strand of ribonucleic acid in our hardware, "I don't know" marks me as less-than-competent. And "I don't care" is career limiting; "Not a team player. Fails to identify with the organisations goals and ethos."
So we guess, and we guess, and we guess again. And we're (almost) always wrong!
For 50 years we, as a craft, as an industry, have been guessing wrong. For 50 years our projects have mostly finished "late", and we keep wondering "Why?" Books have been written, Methodologies developed, PhDs awarded, Management Disciplines imposed and entire Consulting Industries built on the premise that it is ''possible'' to estimate software effort better than we presently do. Or, if we can't estimate better, then we can manage the estimation risk better. Or the process. Or those pesky damn programmers.
All in vain. The projects keep coming in late.
where it all comes from
How did this abysmal state come about?
I think it is rooted back in the 1950's, when the first Big Software projects were undertaken, most notably by the US military. Quite naturally they applied the project management strategies that have worked for them since time beyond time. Strategies that have successfully built forts, dug moats, laid siege to cities and moved large numbers of soldiers across continents and seas. The trouble is that those are extremely well understood problems that have been solved thousands -- millions -- of times, ever since Akkad invaded Ur. For such classes of problems, estimates of time and effort are pretty reliable. If you're a logistics planner, an army engineer, you know, from loads of practice and handbooks distilling five thousand years of experience, just how long it takes for a boatload of soldiers to move a given distance, and just how much food, water and fuel they need along the way.
"Where there are in the field a thousand swift chariots, ten thousand heavy chariots, and a hundred thousand mail-clad soldiers, with provisions enough to carry them a thousand ''li'', the expenditure at home, including entertainment of guests, small items such as glue and paint, and sums spent on chariots and armour, will reach the total of a thousand ounces of silver per day."It is an extremely well understood problem domain!
-- Sun Tzu, ''The Art of War''
Software development is a different sort of beast. It's all new to us. Amost every problem has never been tackled in its entirety before. I don't claim that software development is unique in this; I am pretty sure that developers of new aircraft, ship engines, new forms of bridges, all face the same problems as software development. What -- perhaps -- distinguishes software development is that it's all new every time! We never get to repeat our past developments. If we were repeating -- exactly -- repeat-developing a requirement -- in every detail -- we would already have the code and we'd have no need to write anything! And if there's one thing I've learned about developers, its that we -- most of us -- hate doing the same thing twice! It's probably a function of our predisposition towards ADD/ADHD.
all change
But, no! In truth there are always differences between the Systems That Have Gone Before, and the Systems We're Developing Now. Even if you've developed interface to a dozen payment gateways, 100 gets you 1 that the next payment gateway has some unique characteristics all its own. Or perhaps some key technology has undergone a significant change in the last few years. Or some new tech has crept into the picture. "Our service is provided through a RESTful API"...
Then, too, how do you account for the Buggerance Factor. Murphy's Law. The simple fact that even the simplest piece of software depends on a ''huge'' number of other bits'n'pieces being in exactly the right places, configured exactly right, at exactly the right time?
I should not have had to spend an hour this morning tracking down the fact that a key library -- a jarfile that should always exist in a standard, accessible place -- had mysteriously been Taken Up. Vaporised. Gone. Perhaps my disk is going flaky? It shouldn't have happened. I should not have wasted an hour figuring out why the application wouldn't run. But I did.
I should not have spent a morning last week discovering that, despite the Vendor's persuasive assurances to the contrary, the version 8.2 driver does emphatically not work properly with the version 8.1 server. Let us not even ask the question, "Who installed the 8.2 driver?" A fruitless waste of time, energy and stress hormones.
How the hell do you predict that particular morning and figure it into your time and effort estimate? Or the half-day spent figuring out that there's a bug in a key data-access library you're using (and it's not your choice that mandated its use, but some arbitrary "policy".) And then another hour figuring out a way to work around the bug. Just how exactly, when you're Project Planning some 4 months ahead of a frustrating and unproductive morning, do you predict those?
You just blew your estimate.
managing estimation risk
I am well aware of various approaches to software development that try to futz around the problem -- some of them with some marginal success -- by giving up the idea of a project being "finished". But nobody seems willing to confront the central problem head-on.
Estimating "How Long It Will Take" is a Broken Idea.
Like the drunk looking for his spectacles under the streetlight "Because that's where I can see to look for them" we keep searching for ways to make estimation more accurate, more reliable, more amenable to conventional management thinking. What we really need to do is screw our courage to the sticking point, and accept that there is, really, honestly, truly, no alternative:
We must completely abandon the whole concept that software effort is amenable to estimation at all.
call to arms
Give up the crutch!
The next time -- and every time after that -- that someone asks you "So how long do you figure that's going to take?" -- "So when do you think we can go live?" -- Just Say No!
Just say, "It will take as long as it takes."
I guarantee you some excitement in the short minutes immediately following, but let go of your fear! Immediately you will find yourself skulling in the calm pond of assurance and truth that lies beyond the fear. Live and enjoy this Truth, for it will set you free. If other people want and need to make deadline commitments, let them be the ones to suck their thumbs, making up fantasies and lies. Do not allow them to push that responsibility onto you. Don't allow them to turn you into the liar. Just tell them,
It takes as long as it takes. It always does, anyway!
Subscribe to:
Posts (Atom)
