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?
15 November 2008
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.
Subscribe to:
Posts (Atom)
