Cape Town Architecture Meetup: Survey Results

Posted on by
Reply

Here’s my overview of the Architecture Meet-up survey results from the 28 people that responded. This is probably better to read than the raw results because the way I guided respondants to use rankings was the wrong way around so the automated results are sometimes tricky to read!

Attendance: First and Future

60% attended the first meetup, 40% didn’t.
Everyone except one person wants to attend future events (that one will attend if topic suits… at least they’re honest!).

Meetup Format

There was a spread of input here but the ranking indicated a preference for both “local” and “discussion” and had the following in joint 1st:

  • 30 Minute presentation of original (local) case studies
  • “How I’d solve that problem” discussions (with topic notification beforehand)

Followed by:

  • 30 Minute re-presentation of other organisations (global) case studies
  • 10 Minute lightning talks

Future Sessions: Top Topics

From the feedback at and following the event I built a list of 11 topics for people to rank. There was quite a spread of preferences but there were three that stood out a little higher amongst the rest:

  1. Infrastructure automation
  2. Building Block Series: Databases – NoSQL or Relational or Both?
  3. Architecting a good team structure and culture

The next grouping was probably (in no particular order):

  1. Scaling with caching
  2. Developing an extensible product/service
  3. Creating and implementing testing for an ecosystem of services
  4. Building Block Series: Test Driven Development
  5. Building Block Series: Queues
  6. Building Block Series: Security

The no-no’s seemed to be:

  1. Architecting for mobile
  2. Building Block Series: Frameworks

Participation by Speaking

Over 60% of respondents were willing to actively take part by speaking/presenting which really surprised (and pleased) me!

Silicon Cape Feedback

Posted on by
5

Tonight there is an open feedback session for the Silicon Cape initiative over in the Alba Lounge at the V&A Waterfront. I can’t go because it’s my good wife’s night at hockey and the kids have had enough babysitters this week! However, I thought it good to stick a stake in the ground for what I would have said had I been there and this post is it. Maybe someone will see it and represent these points if they agree…

The Caveats

Firstly, it’s very easy to sit on the side and criticise a non-profit community initiative like this. Just like the 1000′s of couch-based Stormers coaches every week that know “just how things should be done to get the right results”. But it’s much harder to get stuck in and help move things forward in a way that benefits others and not just their mean selfish interests or ego.

Secondly, I’ve only been in Cape Town since January 2011 and therefore only been to three or four Silicon Cape run events and have no idea of anything before that.

With those things in mind…

Where’s The Foundational Winner?

I’ve always had a sense that the name “Silicon Cape” set expectations way too high and this was really brought home to me by an excellent Fred Wilson post on the New York tech scene called “The Darwinian Evolution of Startup Hubs”. In it he reminds us all of the multi-decade history of Silicon Valley with its roots and branches and wealth generating successes. Those successes begat future successes and so forth but it takes a winner to make that happen. That first seed has not yet been harvested in the Western Cape and its not obvious (at least to me) who it could be.

We’re In Africa

When at the last SC event I went to about the SA eCommerce opportunity, I made a point that I think is worth repeating in this context. US and European models (however successful) are not guaranteed to work here. I think the local phrase is TIA, This Is Africa. Why do people want to be like US/Europe with their boom and bust mentality? Companies are people all the way down and this ruins lives every time the cycle repeats. Sure there’s great and attractive opportunities globally but who can serve the African continent better than the people who have a much better understanding of the local cultures and constraints. Again the Silicon Cape name encourages a global push that I think unhelpful.

Everything and Nothing

It seems to me (again, remember the caveats) that the initiative, though well intended, stepped on a few toes when it started. Now maybe those bridges are mending but creating something with a wide intention and remit can seriously annoy those involved in running more focused groups that also seek to stimulate growth in local success. Trying to be everything to everyone usually leads to being almost nothing to everyone. This is not an irreversible situation

People are Idiots

Lastly, there’s some real tools out there. Seriously, some of the questions that the audience make at events are beyond silly. No, I’m not talking about the infamous questionguy here (who I see was the first to confirm attendance at the feedback meeting!) because though his questions are long they actually have an ounce of thought. I’m talking about the tools wrapping a pitch for their non-existent start-up in a pseudo-statement-question. I’ve talked to a few people that I want to be at events with because they help me stimulate follow-up discussion and conversation beyond the events and they don’t want to go because of a lack of tolerance for the idiots who dominate. The only way to stop this is strong moderation.

Be Positive Mike

So, now I’ve got all that off my chest I can focus on some positives! What would I ask they do more of or start doing?

Developers, Developers, Developers

Channeling my inner Steve Ballmer I think the core of it needs to be that the Initiative finds a way to build stronger bridges into and across the developer community. I would argue that the heart of the success in business comes not from great ideas but from great execution and in a drive for a greater tech hub, that engine room of execution of that is developers. Developers are not a resource to be used and abused in a desire to get your <insert US Success>-clone built. Hey “business people”, you’re not all the same, take the time to understand developers aren’t too.

Find a Strong Voice

The other thing that I think would be really good is to have a strong and knowledgeable advocate for tech business in local and national government. Lets be honest, that successful first-seed we need to generate the cash for a knock-on effect is not going to be HQ’d themselves locally so lets make it attractive for SA companies to stay HQ’d here and not set-up most assets abroad ready for acquisition. This is not simple, I have no expertise here, but I know it can and needs to be done.

Promote the Ecosystem

I believe this has started to be done given recent events around legal advice for start-ups etc. but the reason hubs take off is because the whole ecosystem supports that mentality. Legal, finance, banking, offices, infrastructure services, logistics, etc. All of those need to cut the paper work/red tape down and make themselves start-up friendly.

In Closing

Thanks must be given to the steering committee who’ve got Silicon Cape this far. Don’t quit, but don’t be afraid of a radical change. Do a few things and do them well. Please.

Cape Town Architecture Meet-up 21 May

Posted on by
Reply

This Monday saw the inaugural Architecture Meet-up in Cape Town. The meetup was created to fill the gap that exists for a chance to get together, learn and discuss topics that cross the divides created by language specific groups (like Ruby, Python, etc.).

The session was hosted at Codebridge in Claremont, which is an emerging hacker-space for co-working and events. I’m going to be working from there going forward in one of their upstairs rooms.

After a short delay to the start to allow for a few attendees caught in traffic and a little beer consumption to fade the worries of the day Jonathan Hitchcock (@vhata) and Adrian Moisey (@adrianmoisey) kicked things off.

Jonathan checked audience mixture which seemed to be mostly professional developers, about 6 sysadmins. Most indicated a focus on using Open Source Software with about five proudly confessing a Microsoft-based day-job. Lastly, to round out the demographics there was one proud product marketer (me!) and one student.

What is architecture?

The focus of the first event was two-fold. Firstly, to get solid feedback on the concept and future of the group and secondly to ensure that we were all singing from the same hymn-sheet as we started as to “What is architecture?”.

Jonathan moderated an open discussion with a good number of points from the floor then used some slides from a recent SimpleGeo presentation that mostly backed up what was already discussed in the room and then led us further down some of the points. There is a breakdown in the connection to the analogy of real-world architecture at some points and you can see that detailed in the slides.

The key take aways from this discussion for me were:

  1. The architect needs to see the big picture
  2. If a system exists already its really hard to walk in and be an architect. Something that you need to grow into (Facebook’s hiring policies were referenced here)
  3. That just like real-world architecture, most builds are unique and that the architect must take into account the terrain you’re in (assume nothing)

Then a call from the audience to bring it back to the software world from analogies let to Jonathan using an example problem and solution that he had recently heard at a Basho talk that Yammer had dealt with. You’ll find the video of that talk here) and another “case study” style presentation that was mentioned of the AirBnB Tech Talk on Scaling Instagram here).

What is the purpose of this group going forward?

As a transition to discussing “what’s next” for the group we had a quick review of the kind of talks that can be given that break down a topic (not a company specific issue). This one in particular was jokingly called an example of “Architectorating” (hey, leave the made up words to the product marketers!) and you’ll find it here.

The discussion of the purpose going forward was an open one with anyone able to shout out things and there wasn’t much disagreement on what would be good.

You’ll find all the points raised in my raw notes here but there were some key principles that stuck out for me.

  1. Having technology agnostic approaches to most talks. That doesn’t mean the resulting software/solution answer is not detailed, but the process of problems definition, discovery and decision making is important.
  2. Not to limit ourselves purely to technology. The interconnectedness of things like teams, business and services itself is vital for a good architect to understand and address to some level.
  3. We should always be asking “Why?” and not just be passive in a “spoon-feed me now” attitude.

For me the most interesting topics suitable for upcoming sessions discussed were:

  1. Presentation of a series of building block tools (like queues for example)
  2. Key learnings in posts from highscalability.com articles
  3. Take-aways from a newsletter item in:
  4. Building security into an architecture
  5. Developing for extensibility/MVP (not just re-design every time)
  6. How to address the testability of an ecosystem of services (not just components)

All of these could easily keep us busy for the months of talks but only (and its a big only) if people in the group step up to deliver them. This group will quickly break apart and dissolve if it falls to the usual (thinly spread) few to constantly drag it forward.

Meet-up Logistics

We closed with a short discussion on logistics. There was a short (thankfully) pointless discussion on whether the day was right etc. but you’re never going to get agreement on that in a room of forty-odd people!

The following was generally agreed though:

  1. We’ll shoot for once a month as a start point (again, speaker dependent)
  2. Codebridge is going to be its regular home for the foreseeable future
  3. We’ll move slightly later to 6:30pm (however, people are welcome to rock-up and self-entertain at Codebridge from 5.30)
  4. We’ll continue to work on using multiple communications/collaboration tools for now (such as Facebook/Google Groups etc.)

Next Steps

Codebridge is a going to be a great space for this to happen in but it needs some donations for the comfort of all and not just a few. The faint call for support and donations (the A0 poster not big enough obviously) led to a massive R50 donation on the night which will be used to buy the donor a single chair with his name on. We’ve had a few follow-up with donations subsequently but I would encourage you to consider dropping something in the box next time you visit or email me or Josh about other things you have to offer.

Lastly, from the amount of attendees and the at times lively discussion its obvious this group has a future. However, as I’ve mentioned its dependent on the members agreeing and following through speaking on the topics. Drop a comment on here or Facebook if you’re able to do that…

Avoiding Peter

Posted on by
Reply

I was enjoying a delicious cappuccino in my first visit to Bread, Milk and Honey in the city the other day and catching up with a friend when the concept of the Peter Principle came up. Firstly, I realized I seem to have a great memory for concepts but a terrible one for the names of them! Rian who insisted I have the cappuccino, doesn’t seem to have trouble at all and mentioned a few concepts during our chat that I knew but had forgotten the names of.

The Peter Principle

The Peter Principle states: “in a hierarchy every employee tends to rise to his level of incompetence”. This means that employees will tend to be promoted until they reach a position in which they cannot work competently. It originated in 1969 by Dr. Laurence J. Peter and Raymond Hull in their book carrying the title of the principle.

Quoting from the Wikipedia entry on the subject:

The principle holds that in a hierarchy, members are promoted so long as they work competently. Eventually they are promoted to a position at which they are no longer competent (their “level of incompetence”), and there they remain, being unable to earn further promotions. Peter’s Corollary states that “in time, every post tends to be occupied by an employee who is incompetent to carry out their duties” and adds that “work is accomplished by those employees who have not yet reached their level of incompetence.” “Managing upward” is the concept of a subordinate finding ways to subtly “manage” superiors in order to limit the damage that they end up doing.

Unfortunately, there has never been a large-scale statistical verification of the principle and most evidence given for the axiom is usually humorous and anecdotal.

Pre-designed organisations

However, I’ve been thinking about this principle ever since our chat in the context of building the “right size” organisation from scratch and how important the initial hires are to a start-up. If the Peter Principle is true then in theory you can’t have one layer of promoted management within the organization. But what would happen if you planned the organization like an empty shell from the start and filled the gaps as revenue and available operational budget grows? That way you recruit someone with the express intention of the final scope of their role which which may or may not include the responsibility for others. If you subscribed to the Roman principles of 10:1 management ratios (which I don’t since Sig so ably ripped it apart) that would peak your organization at 100 people. It does of course depend on the nature of your business, but you can usually achieve a lot with 100 people [1].

There’s no denying that hiring well is hard, as is managing the expectations of individuals around their “career growth” but that shouldn’t stop us from trying.

Valuing individual contributors

The underlying challenge is whether we create or join a culture where the role of “management” is viewed as something for all to aspire to and a greater goal than that of “individual contributor”. The collateral damage of badly formed cultures is sometimes seen in situations where managers with two-direct reports themselves work for a manager with two-direct reports and compound job titles such Distinguished Senior Principal Something Manager as attempts to standardize pay-grades and give people “something to aim for”.

There has to be respect for the craftsman, the creator, the knowledge worker, the domain expert. Those roles are not ones where you can shift straight into fifth-gear, they take a steady compound month-on-month, year-on-year development of knowledge and skill. Even if you look at an industry like manufacturing which many knowledge workers would look down their nose at, companies like Toyota have proven that an expert and empowered work-force is a powerful one.

In his book, Delivering Happiness, Tony Hsieh descibes how the moved to a more regular and granular approach to setting goals and related merit increases. I believe this could help remove some of these compound job title type issues and improve the motivation for growth within roles.

Management as administration

Joel Spolsky recently wrote a post on management as part of the MBA Mondays series on Fred Wilson’s must-read blog. You need to read the whole thing but these paragraphs really jumped out for me:

The “management team” isn’t the “decision making” team. It’s a support function. You may want to call them administration instead of management, which will keep them from getting too big for their britches.

Administrators aren’t supposed to make the hard decisions. They don’t know enough. All those super genius computer scientists that you had to recruit from MIT at great expense are supposed to make the hard decisions. That’s why you’re paying them. Administrators exist to move the furniture around so that the people at the top of the tree can make the hard decisions.

When two engineers get into an argument about whether to use one big Flash SSD drive or several small SSD drives, do you really think the CEO is going to know better than the two line engineers, who have just spent three days arguing and researching and testing?

If people are hired with the expectation that if they ever get management responsibility they should consider they’ve just moved into an administrative function then maybe some of these problems can be preempted. I’ve met some killer administrators and these deserve their own higher levels of respect!

A recent embarrassing outburst from a former-CEO in the online gaming world led Dave Winer, who continues to push whole communities along with his polarising but well thought-out views wrote:

There’s a lot of hands-off-ness, a lot of delegation. And humanity never entered into it.

OMGPOP was not a 20-year old company, it should not have had an ingrained culture that was impossible to reform due to constraints built up over many years of corridor-walking employees.

Get Out of the Way

Joel’s article closed with:

For every Steve Jobs, there are a thousand leaders who learned to hire smart people and let them build great things in a nurturing environment of empowerment and it was AWESOME. That doesn’t mean lowering your standards. It doesn’t mean letting people do bad work. It means hiring smart people who get things done—and then getting the hell out of the way.

However I believe these thoughts best closed by a quote from a classic two-fighting-brothers band:

“We need each other, we believe in one another” – Acquiesce, Oasis

[1] I hate it when people refer to organization with less than 100 people a “small business” as it seems so belittling of the achievement of providing that many people with work. In places like South Africa and other similar countries, one person with a job often supports many more people in a family and community group.*

People First. With Exoskeleton Support.

Posted on by
Reply

[Note: Cross-posted from my employers blog where I occasionally write]

Last week’s Cost of a Data Breach Study update had one particular statistic that stuck with me and to which I keep being drawn to when discussing it with others. In the UK study, they discovered that where an organisation that suffered a breach had a Chief Information Security Officer (CISO) or someone with the equivalent level of responsibility in place, the cost per record dropped by an average of £18. I think the key word in the previous sentence is “responsibility” for a few reasons.

Firstly, we have the increasing amount of fines and penalties that can be applied to the individuals involved in failing to deliver against expectations. These have gone beyond the original highly regulated industries and out into the broader business context. With the coming updates to EU legislation, it’s likely to get more attention in the boardrooms of Briton, not less.

Secondly, and contrary to popular thinking, stopping data loss and protection of the key information assets an organisation has goes way beyond using scanners to prevent credit card details being emailed out. Primarily, it’s not a technical problem, it’s a people-process-technology challenge.

In the past, I have heard references to people-process-technology being like a three-legged stool of which you can’t remove any without falling off! This can be considered a fair comparison but, for me, the ‘people’ part of this stool is the most critical starting point. People have negotiation skills. People have perspective. People drive change.

When it comes to the role of technology in stopping data loss I view it like an exoskeleton to the people involved. That may sound a little sci-fi but what they need to be able to do is say “this stuff is important, please tell me how it’s being used, where it’s going and who uses it”. Technology enables them to reach into network pipes with gigabits of data pumping through them. Technology enables them to piece together a process involving four employees and an outside contractor. Technology enables them to see the HR director does not like using the VPN from his second home in the Cotswolds.

The reason I view it as an exoskeleton is that the knowledge of what’s important comes from the people involved, as does the appropriate response and the negotiation to get from where they are today, to a more secure future-state.

The relentless growth in information and systems shows we’re not moving towards a state where data loss won’t happen anymore. However, this report shows that if you put someone in charge with responsibility and authority to make change happen when it does occur, the impact to an organisation’s bottom-line is significantly reduced. I’m happy to predict the gap between those that take it seriously and those that stick their head in the sand will only get larger in the coming years.

Do I Really Hate Maps?

Posted on by
1

For the third time in a week I’ve been asked some variation on “what the deal with you hating maps?”, this time by Rian on Twitter. The underlying reason for this question is my username on nearly every service is “imsickofmaps”. I realised however that I’ve not actually posted the history and maybe it was time to lay down a post, because it certainly doesn’t fit into 140 characters!

The story starts with Hotmail, which I started using back in the 90′s. I had an account there pretty early on and had mr_mike_jones@hotmail.com as my address instead of some inane mikejones938832932@hotmail.com address they’d probably give you these days. In ’98 or ’99 sometime I got sick of the “directory harvest attack” spam waves that Hotmail just didn’t seem to be able to deal with and decided to move usernames. I wanted “imsickofspam” but “spam” along with “help” and “support” etc. was not allowed in your username in case you tried to spoof those functions. So I just reversed the word! Maps is Spam backwards…

The spam stopped and choosing an account name at every service ever released ever since has been a piece of cake!

So there you go, I don’t hate maps… I fact when you walk into our house you’re greeted with a giant map of the world that’s about 3M wide … I LOVE MAPS!

 

How does Cape Town increase developer/business engagement?

Posted on by
Reply

The developers-developer and ScaleConf organiser Mr Hitchcock and I were having a little back and forth on Twitter this morning here about how effective or ineffective the Silicon Cape initiative is. The point of contention is how to move from “talk” to “action”.

Moving from talk to action was one of my New Years resolutions this year so its top of mind for me personally, hence the link to the quote on the Silicon Cape interview that said:

We don’t need more people talking about it. We need people to act. We need people to ship things.

So the question I want to pose and collect feedback on is this: Do developers in Cape Town want to increase their business skills or partner with non-coders who are stronger in that area?

I can’t remember where I read it this weekend, but the predominate Founding CEO’s in Internet-first businesses in Silicon Valley are Technical Founders not business folks… what’s the feedback developer friends?

Curiosity Killed the Productivity

Quote

Posted on by
Reply

I got to end of the article and all I could think was, “Why do I read this crap?” Well, I read it because my curiosity sometimes overcomes my importance filter. And getting that balance right is what we all need to make this curiosity thing work for good, not evil.

from Should designers learn to code? Who cares, as long as they always remain curious.

 

2012 Resolutions: One month in

Posted on by
Reply

So 1/12th of the year is gone. Goodbye January. How are we doing on the resolutions front I hear you ask…

#1 – Print one picture per week
Slight change in strategy to save money on this one. I’ve been choosing one photo per week and storing them in a folder to bulk print and save money.  On Track.

#2 – Read less, write more
I culled a bunch of my inputs in Google Reader and deleted some irrelevant Twitter follows. I’ve written one of the longest posts I’ve ever written on ScaleConf (which has had over 250 people read it so far!), plus a few on my project blog.  On Track.

#3 – Cook something new every month
I cooked spicy meatballs that I made by hand and a awesome chicken balti. On Track.

#4 – Do the Freshpak Tri in under 1 hour 25 mins
I’ll have to wait a while on this one. Need to run more though generally. Pending.

#5 – Stop talking, build and launch a new site before April 1st
I’ve not stopped talking or building code. But I have begun to solidify the fundamentals so I can direct my activities wisely! On Track. 

#6 – Read the Bible in a year
This started well but trailed off. I changed tactic to read every day until inspired, a better resolution, but that failed too! This is officially not a habit yet! Failing.