One of the disadvantages of being a passionate person is the ride that passion can take you on. At my first big Open Source event approximately a decade ago, I was this eager young thing happy to be around people who actually got Open Source. I was so excited at the potential that Open Source had to help South Africa, Africa, and the world solve all sorts of problems. As time went by, while I was reinvigorated somewhat by each passing event, I was also growing more and more cynical about how achievable and realistic many of our goals were.
As I've followed the hype and pomp around social media as it arrived in South Africa, that cynicism was quick to come to the fore and point out that talk is cheap. And, really, so much of what has happened in the past few years in the space in South Africa (and abroad, I guess) is talk.
Strangely, that cynicism has been very quiet when thinking about the Silicon Cape Initiative. (I suppose it is good politics to back an initiative of the person who has my current and future financial situation in his hands, but anyone who knows me knows that I'm very rarely that insightful of office politics, and equally rarely cautious of it.)
Over the past week or so, I've wondered why that cynicism has been absent.
A large part of that, I think, has come from the Cape Town GeekDinners, my beloved *Camp two years back, 27dinner, and BarCamp Cape Town. Through these events, I've expanded my understanding of the level of talent and interest and energy available in Cape Town and South Africa, underneath the facade of the social media/personal branding hype, and I'm excited by what I see there.
Another potential reason is that I'm seeing a few people I respect emerge from their silent action-focused mentality and tentatively enter the fray - both here and abroad. Willing to give belief a chance again after being a little ahead of the curve and getting more than a little burnt.
Or perhaps the cynicism just thinks it will have a stronger hold if I get empassioned about it and it fails to deliver.
I doubt many could find any non-trivial faults with the Silicon Cape Launch event itself.
The speaking line-up was excellent:
A good balance - a lot of optimism, some realism, foreign and more experienced perspectives, an enumeration of challenges, a few posited solutions, and generally a feeling that this is something that can be done, if enough (and the right) people put the effort into it.
The panel discussion was very interactive (certainly more so than any I've seen before), giving the attendees an opportunity to air their thoughts, and ask questions and get answers. (I wish Henk had more opportunity to talk, though, being my pick of the entrepreneurial representation on the panel.)
So, a well-executed event. Some sparks of interest fanned into passion. Obviously, where to from here? How do we keep the passion going? What are the most effective next steps? How do we measure the progress?
I started by saying that passion comes with disadvantages. Passion ill-tended leads to a cynicism that inhibits not only that person, but those around them.
A few hundred people empassioned can turn into a lot of cynicism, and fast.
More reading:
Since Yola (formerly known as SynthaSite) has a distributed team using many Agile practices, having Scott Ambler speaking in Cape Town on Agility At Scale was too good to pass up. Four of us from Yola woke up cruelly and unusually early to attend. It was interesting to me just how much of what I believe was described, although I did learn a lot too.
Distributed teams are hard, no matter the methodology followed. Scott reported (the numbers in the link are slightly different) that while 79% of co-located projects using Agile practices were considered "successful", only 55% of "far-located" (ie, requires a plane trip to get people together) teams reported that. I suspect that anyone who has had experience with both scenarios would not be surprised.
Distributed teams generally require "hand-offs", and these are generally done via documentation. Scott suggests that every hand-off contains a risk of defects being injected. He referenced Media Richness Theory, which posits that documents are the worst way to communicate information, whereas face-to-face communication (Scott suggests with a shared sketching area) is the best.
My experience with Open Source projects has shown that it is possible to have successful distributed development using text as the primary form of communication. However, I've found that those without experience with developing on Open Source projects generally just don't have the same ability to deal with text as a primary form of communication. (Interestingly, my best work relationships have almost always been with people who have developed on Open Source projects before.)
Scott's suggestions for organising distributed teams match exactly the suggestions I've put forward about distributed teams — basically that you should arrange the teams such that there is as little need for distributed communication as possible. Put another way — a team should be co- or near-located if at all possible, and able to perform as much of the work themselves without needing to communicate externally.
Answering a question from the audience, Scott promoted the idea of code, usability, and data guidelines/conventions so that team members could follow them themselves as much as possible to reduce reliance on skills silos in that area. He also suggested automating as much of the guidelines checking as possible.
On the subject of testing, Scott broke it up into two functions. Within the team there should be "confirmatory" testing — these are tests that the team make to confirm that they've developed a feature correctly, to confirm that they haven't broken an existing feature, or to confirm that a previously-discovered bug has not been reintroduced. The most common of these tests are unit tests, but other types of tests could be done here. Real professionals test their own stuff to the best of their ability.
He suggested having an external team of testers perform "investigative" testing — testing that determines suitability of the delivered software. This includes "exploratory" testing, which seeks to discover bugs through learning and use of the system as a user would, as well as usability and security testing.
On the subject of usability and security, Scott suggested that every developer be sent on a two-day usability course, and the same with security. Besides helping team autonomy, it also makes it easier for a developer to know when they're out of their depth in these fields so that they can consult others on how to address these concerns.
There were a lot of nodding heads and a lot of laughing from the audience. Some of the laughter was because of Scott's entertaining (if a little disorganised) delivery, but I suspect a non-trivial amount of the laughter was of the nervous variety as he nailed quite how dysfunctional and unprofessional our industry and organisations building software are.
Maxims abound in the self-help/productivity game. They're peddled primarily by people who reword or, more optimistically, repurpose existing rules generated by others for a new context. Whether you're using the maxim "single-task", "say no", "do less", you are using a rule that has been created by another, hopefully from a process that involved seeking an understanding of some problem. You may gain much by following the maxim but you haven't gained the understanding that was gained leading to its formation.
Maxims seem to have the most power when actively wielded (usually when they're first discovered), with their power diminishing over time. This isn't so much about the consciousness of the maxim so much as being able to get away with delaying tasks that don't fit into them. Most tasks can't be delayed indefinitely, and then things break down when the incompatible task hits the rule made rigid by not having sufficient understanding to seek compatibility (or, perhaps, to specifically not seek compatibility).
The general response to that is that the maxim is a guideline (or perhaps a mantra), not a rule. That one is supposed to keep it in mind, rather than rigidly follow it. Consider it as a factor in every decision. But it matters little — without the understanding, you are left powerless to deal with incompatibility.
There seem to be three levels of understanding of an activity, whether about how you work as a person or about how one develops software. In the first level, you follow the rules others give you. In the second level, you try to understand how the rule works, why the rule works, what other rules exist out there as competition or as allies, and begin to be able to create your own rules. In the third level, you no longer think in terms of rules, but rather just act appropriately based on the full available context — making decisions from your "gut".
(Somewhat separately, I discovered or possibly rediscovered Shu-ha-ri, which has the same levels, but may or may not suggest these same meaning for these levels depending on which article you read about it. The current Wikipedia page, as linked, has the same meanings.)
This leads us to an interesting problem — someone who has achieved a high level of understanding about an activity can appear to those with a lower level of understanding about that activity to be acting incorrectly. They aren't following the rules that others have heard of, and they haven't followed the rules that observer individuals may have made for themselves.
Where your success speaks for itself, say in some martial arts (Bruce Lee's Jeet Kune Do being perhaps the most apt example) or in self-development, this may not be a problem, or may even gain you respect. However, in business and many other communal/organisational activities, even continual success doesn't confer any sort of pass on describing why things should go as you say.
Since you're not using rules from a particular well-known practise, you can't refer to any sort of "definitive" sources. You also can't be sure what rules your audience has made themselves. In this case, you have to teach your new set of rules to others, possibly helping some to unlearn contrary rules, layer by layer until you reach your suggested outcome.
Does one need to work from first principles every time? This is a very time-consuming and energy-sapping undertaking. Does one need to work from first principles every time someone new is brought in? Should one make that assumption that someone you've convinced from first principles before will remember the argument from first principles, or still agree with it?
I guess this is an activity that requires mastering itself, and there's no good quick answer to it either.
I haven't had an interaction with SARS eFiling that didn't involve a screwup on their part. I thought that at least one of them wasn't — I was surprised at how well my 2006/2007 return process was. But, it seems, while I was happy with the 2006/2007 return, SARS isn't.
I first contacted SARS eFiling in September 2003 with query, and posted "SARS efiling unsupportive" a month later when I hadn't received a reply. I sent reminders in October 2003 and March 2004 prompting the post "SARS eFiling still unsupportive". In July 2004, after another reminder, I posted "SARS eFiling unrepentantly still unsupportive", and I wasn't the only one complaining. In August 2004, I contacted the SARS service monitoring office, and got my first reply about this ever, as documented in "Finally hear from SARS".
In this reply, it was made clear that the email and telephone support for eFiling was handled by an external company. This struck me as troublesome, but it was also made clear that the fact I hadn't got any replies "remains the responsibility of SARS I
believe and we will make sure that your e-mail is responded to". That's the attitude!
Shortly thereafter, I received a reply from Interfile (obviously someone needed a fire lit under them), the people who run eFiling, prompting "Interfile replies about efiling". I found their old-world thinking a bit scary — they wanted me not to divulge to people that they were working on improving their site! Can't say I enjoyed my subsequent interactions with them — including saying they'd be happy to reply to further queries, but not doing so when I had some.
At some point thereafter, I signed up with eFiling. Because of their inane policy of auto-appending a number to the username you want, you spend more time trying to remember your username than your password. Also, you need to fax (FAX?! WTF?!) some authorisation to them to activate your account, so I gave up.
The 2006/2007 return season came, and I used the PDF return. It worked beautifully (or so I thought).
Post 2006/2007 return season, I finally authorised my eFiling account, hoping to be able to do my provisional tax returns with it. However, somehow two accounts were created for me and all sorts of weirdness (possibly due to migration issues, since I'd set my account up quite some time before authorising).
Because of the two accounts, I couldn't start from scratch over again to correct the problem. When I complained to SARS about this, I had to go through three different call centers, including getting routed back to one after being directed to another, and getting my call unceremonially cut off somewhere. Eventually I got to a person who could fix my problem. And he did. Which was awesome. And I did my provisional tax return (or, at least, I hope I did).
However, it seems the 2006/2007 income tax return wasn't submitted correctly, maybe because of my weird account configuration on eFiling. I get a call from SARS asking me about the 2006/2007 return. I can't express how disappointed I feel at this point, and tell them I submitted it through eFiling. I check eFiling, and the return isn't there. Maybe it was deleted when my double accounts problem was fixed? Maybe it was a problem at submission time? Who knows?
Anyway, I have an email from eFiling thanking me for my submission of the tax return, which I've faxed to SARS now. Hopefully that prevents undue penalties due to their failure. (I've already done that once, thank you very much.)
However, I'm very disappointed at how SARS and eFiling are being operated as two totally different entities, and how SARS is unable to verify things about me in eFiling "because you have your username and password". eFiling is an interface SARS provides to me as a taxpayer, and any brokenness in eFiling is entirely the responsibility of SARS, and "it isn't us, it is a company we outsource to" is not an excuse.
The SynthaSite Cape Town office recently surprised its staff with iPhones. We're predominantly an office of people who work weird hours and work from home or wherever we happen to be frequently, so there probably is some sort of justification possible if one were looking for one.
I'm not all that much of a gadget person. I've never owned an iPod (although I've borrowed one for international plane flights), a PDA, or any other sort of portable electronic device. Well, except my Nintendo DS and DS Lite, which is part of my gaming addiction. I've never been one to use a cellphone for anything beyond making phone calls and sending a few messages. As such, I had no real expectations going in.
The iPhone is just plain intuitive — things are were I expect them to be and work the way I expect them to. Perhaps having used OS X for the past year has helped, but I think it should be relatively universal. Convincing iTunes that I didn't want to register it was about the hardest part of the start-up process. Using iTunes already probably helped, but my MacBookPro life synced over to the iPhone readily enough (had to prune my 10+ GB of podcasts a bit to fit, admittedly). The default mail application works fairly decently for my Google Apps For Your Domain mail — archiving in GMail terms means moving the mail from the Inbox to the All Mail folder.
Would have liked to see my MacBookPro's wireless networks transferred to the iPhone. Wish there was something that could handle my Google Apps For Your Domain calendar by default. The contact import from my Google contacts created hundreds more entries than I expected it to — most imports from Google contacts don't import every person who has ever sent me email. Can't make ringtones from my existing music, or just use any old MP3 as a ringtone. The built-in Maps application is pretty useless, since Google Maps are pretty useless in South Africa, and no sane option seems to exist to use the decent OpenStreetMap coverage that exists in at least Cape Town. The GPS also seems to take its time to figure out where I am.
The biggest irritation, however, is the iTunes Store/App Store. The South African store is crippled. Besides the relatively understandable (ie, not entirely in their control) total lack of music, TV series, and movies, it also lacks podcasts, games, and some fundamental applications. A few "must-have" applications my iPhone or iPod Touch-wielding friends use elsewhere don't appear. For example, the Google Mobile App. I can't see Google being behind not having the Google Mobile App available to South African users. So, it seems Apple is being weird.
Still early days, but I'm pretty positive about the whole thing. I'm especially enjoying having a portable mail reader and web browser from my couch at home, so I don't enter that "at a computer" mode in front of my MacBookPro. Time will tell if Apple's restrictive application environment will increasingly get to me, or if I'll find a killer app that will make the iPhone invaluable.