Archive for the ‘CTO/CIO’ Category

UC Berkeley’s take on cloud computing

Wednesday, February 25th, 2009

Researchers at UC Berkeley have outlined their take on cloud computing in an paper “Above the Clouds: A Berkeley View of Cloud Computing.“ They cover a lot of material in this paper and it’s well worth reading.  Section 7 was particularly interesting to us because it covers the top 10 obstacles that companies must overcome in order to utilize the cloud.  According to them these are:

  • Availability of service
  • Data lock-in
  • Data confidentiality and auditability
  • Data transfer bottlenecks
  • Performance unpredictability
  • Scalable storage
  • Bugs in large distributed systems
  • Scaling quickly
  • Reputation fate sharing
  • Software licensing

 

These look very similar to our top five concerns that we outlined in our article on Venturebeat.com.  Our list was:

  • Security
  • Non-portability
  • Control (availability)
  • Limitations (non-persistent storage) 
  • Performance

Their article concludes with “Although Cloud Computing providers may run afoul of the obstacles …we believe that over the long run providers will successfully navigate these challenges…” They continue saying “Hence, developers would be wise to design their next generation of systems to be deployed into Cloud Computing.”  

We agree and reiterate our conclusion from “The Cloud Isn’t For Everyone

“Of course, most importantly, we should all keep an eye on how cloud computing evolves over the coming months and years. This technology has the potential to change the fundamental cost and organization structures of most SaaS companies. And as cloud providers mature, we’re sure they’ll address our top five concerns, becoming more viable companies in their own right.”

New Year’s Tech Resolutions

Friday, January 2nd, 2009

 

In the spirit of the New Year, we thought we would share our list of top things that you should consider putting on your technology’s roadmap for 2009.   

  1. Develop the ability to rollback: If you can make only one change to your product and process in 2009 and you don’t currently have the ability to rollback, this should be at the top of your list.  Being able to push code changes and then pull them back from production in the event of a problem will save you more customers and more effort than any other single item.
  2. Break changes into smaller pieces: There is almost never a need to redesign the entire site or service at once.  Break it into parts and take it one piece at a time.  This will be lower risk and give you an opportunity to learn along the way.
  3. Remove SPOFs:  Commit to removing all single points of failure in your architecture.  Single servers, firewalls, load balancers, power supplies, etc should all be listed and tackled one at a time until they are all eliminated
  4. Remove synchronous calls:  Having one service call another service in a synchronous manner causes a multiplicative effect of failure.  Five synchronous calls on servers with five 9’s availability (99.999% uptime) leads to a maximum of 99.995% for the system.  Eliminate synchronous calls wherever possible and create fault-isolative architectures to help you identify problems quickly.
  5. Incent a culture of excellence:  Hire the right people and hold them to high standards. Set aggressive yet achievable goals and motivate them with your vision. Be a leader.  
  6. Develop a disaster recovery plan: Disasters happen, no one expects an entire data center to be down but things like that happen.  Plan on it and start making changes today to keep your services up and running in the event of a disaster.
  7. Develop quality into the product from the start:  Don’t expect QA to ensure quality is built into the product.  We’ll post more about this in the New Year but quality starts much, much earlier in the product development life cycle.
  8. Split your application or database:  Start this year thinking about how to split your application and database.   We recommend our cube model for both because working on all three axes gives you unlimited scalability in both your app and database.
  9. Start Logging:  As we discussed in a recent post, start logging your application data but follow our three key guidelines – 1) logging must not impede the performance of the application 2) use a common framework and 3) look at the data
  10. Celebrate your success:  Take time now and throughout the year to look back and congratulate your team and yourself.  If you want to foster creativity on your team, celebrating victories is a great way to keep the energy up on your team.  If you are getting ready to present your 2009 goals to your team, we recommend that you start by focusing on the amazing accomplishments that you have had in 2008.

Wishing you and your teams a great New Year!   

 

-The AKF Team

Foster Creativity

Monday, December 15th, 2008

With the economic downturn in full force, you are probably spending a great deal of time thinking about how to cut cost, reprioritize revenue generating features, or delivering more in 2009 with less resources.  You might think now is not the time to care about “creativity” and “energy” but we think this it is even more important.  Having a team that is fully engaged with all of their creative forces focused on your business is crucial to achieve any of those other objectives.  The way to achieve this is by creating an environment where people know where they stand in terms of performance, get to own deliverables, can openly question decisions or standards, and show each other respect.  

 

A couple ideas that we have either read about or seen in practice in organizations are team or individual training events, four day work weeks, allocated time to work on personal interests, self selection of features/stories, and mentoring.  Training can take the shape of many different forms including formal classes at universities, external workshops (WARNING: self-promotional plug….such as our Technology Workshop), or internal classes taught to each other by members of the team.  Everyone knows different things, sharing this knowledge is good for both the team as well as the presenter, giving her practice explaining technical items verbally  and ensuring she knows the subject completely.  

Mentoring is another low cost method of helping foster a more open and creative environment.  Pairing junior and senior engineers together provides both parties the opportunity to practice different skills.  Additionally, it helps facilitate what are likely two different groups to begin a dialog.  Mentoring can be extended in many different forms.  Ask the CEO to take a different engineer as a mentee each quarter, meeting with them for lunch or breakfast every second or third week for the quarter.  This is a great way to remind the top executive to appreciate the engineers and gets engineers exposure to the business challenges that the CEO faces daily, a real win-win proposition.

Some of the more radical approaches for developing a creative environment are already well documented by some very popular companies including Google and 37Signals.  If you haven’t read the 37Signals book, we recommend this as a great source of ideas for fostering a creative and unique environment for your team.

Team Size

Friday, November 7th, 2008

As you consider hiring plans for next year, one aspect of your organization that you should give some thought to is what is the optimal team size?  You may have heard of Amazon’s rule of “two pizzas”, which basically says a team should be no larger than what it takes to feed with two large pizzas.  If our experience in feeding engineers pizza is typical, this means about 8 to 10 people.  As a general rule, we think this is fine but we have some other factors that we recommend incorporating if you want a more precise number.  These factors include experience of the managers, how long the team has been together, and manager responsibilities.

Before we explore the factors that influence optimal team size, first we should discuss why team size is important.  Consider a team of two people, they know each other’s quirks, they always know what each other are working on, and they never forget to communicate with each other, sounds perfect right?  Well consider they also don’t have enough engineering effort to tackle big projects in a timely manner, they don’t have the flexibility to transfer to another team because each one probably knows stuff that no one else does and they probably have their own coding standards that are not common among other two person teams.  Obviously, small teams and large teams each have their pros and cons.  They key is to balance each to get the optimal result for your organization. 

The first factor that you should consider is the experience level of the managers.  If the managers are experienced they should be capable of handling more direct reports.  New managers should be given fewer direct reports in order for them to have time to develop their management skills.  Keeping resource maps up to date for 15 engineers can be overwhelming for a new manager but one that has done it for years would have no problem doing it.  If you are filling vacancies in your management ranks try to be as detailed in the organization chart as possible spelling out the manager positions that you are keeping for junior managers and those that your are expecting to hire a more senior manager.  If you have a team that will be assigned a very large project and therefore needs to be large in numbers, mark it down as requiring a more seasoned manager.

The next factor to consider is how long the team has been together.  A team of twelve people who have been together for eighteen months is likely to have entrenched processes that make management of them easier.  The team may already have mentoring relationships established or clear divisions of code for easier feature assignment.  A brand new team probably has none of these as well as no bonding and possibly personality conflicts that need to be worked through. 

The last factor that we consider key to determining the optimal team size is what management responsibilities are expected from the manager.  Do you expect managers to conduct a weekly half hour one-on-one meeting with every engineer?  Do your managers need to create and maintain resource maps for the engineers?  Do managers need to periodically assign themselves features to code?  All of these questions and more will influence how many direct reports they should have.  Obviously the more managerial or development tasks that you expect your managers to handle the fewer team members they should have.  If you have a Project Management Organization that helps managers handle assignments and statuses, the teams can be much larger. 

So the answer to how large the team should be is, it depends.  It depends on a variety of factors that we’ve outlined here.  As you start preparing your budget for next year, take a few minutes to consider these factors and ask your existing managers for feedback on how their team size has affected their ability to perform as a manager.

Recommended Reading

Friday, August 15th, 2008

We mentioned in a previous post, Business Acumen and the CIO/CTO, that we would provide a list of our recommended reading material.  We’ve decided to break our list into three sections, business, technology, and just for fun we’ve thrown in some fiction.  This isn’t a complete list, so don’t expect to read these books and be a technology or business genius.  This is just a starter list that we feel every CIO/CTO should have read.  There are plenty more great business, technology, and fiction books that we all should keep reading.  Let us know some of your favorites.

Technology
The Mythical Man Month – Frederick Brooks
Design Patterns: Elements of Reusable Object-Oriented Software – Gamma et al
Patterns of Enterprise Application Architecture – Martin Fowler
The C Programming Language – Kernighan & Ritchie
The C++ Programming Language – Bjarne Stoustrup
The Art of Computer Programming – Donald Knuth
Data Structures and Algorithms – Aho, Ullman, Hopcroft
Inspired: How to Create Product Customers Love – Marty Cagan
The Singularity Is Near – Ray Kurzweil
On Intelligence – Jeff Hawkins & Sandra Blakeslee 
A New Kind of Science – Stephen Wolfram

Business
Purple Cow, The Dip, etc - Seth Godin
Good to Great, Built to Last – James Collins
Crossing the Chasm – Geoffrey Moore
The Art of War – Sun Tzu
The Prince – Machiavelli
Malcom Gladwell – Blink and The Tipping Point
Black Swan – Nassim Nicholas Taleb
The Innovator’s Dilemma, The Innovator’s Solution – Clayton Christensen
Competitve Strategy – Michael Porter

Fiction
Works by William Gibson i.e. Neuromancer, Spook country, etc
Works by Neal Stephenson i.e.  Quicksilver, Cryptonomicon, etc