Posts Tagged ‘technology’

97 Things Every Programmer Should Know – Book Review

Monday, March 15th, 2010

97 Things Every Programmer Should Know is the third O’Reilly’s 97 Things series.  Editor and contributor Kevlin Henney has done a nice job bringing together some insights from some of today’s most experienced and respected practioners. The book is a compilation of short essays ranging on topics as diverse as Bugs, Error Handling, Customers, Refactoring, and Expertise.

Having tossed my hat into the ring of debate of whether software development is a craft or an engineering discipline, I was thrilled to see essays such as Neal Ford’s “Testing Is the Engineering Rigor of Software Development” that states “Compared to ‘hard’ engineering, the software development world is at about the same place the bridge builders were when the common strategy was to build a bridge and then roll something heavy over it.”  Along this vein I was intrigued by how many times the authors used terms such as ‘simple’ or ‘beautiful’. Peter Sommerlad suggest that we treat our code like “a poem, an essay, a public blog…” while Linda Rising uses the phrase “…a beautiful piece of code this is.” In fact there is an entire collection of essays around the theme of “Simplicity”.  This brings up my one and only annoyance with the book, the organization of the essay’s by title. There is an index of the contributions by category but the actual essays are laid out in alphabetical order. I would have much preferred to read all of the essays on a particular theme together without having to flip through to find them.

The purpose of the short essay is not to answer all your questions or be a definitive guide to programming. Rather the purpose is to provide a starting point for a conversation. To this end, I think a practical way to use this book whether in academia or a development team would be to assign groups of essays to be read ahead of time to stimulate classroom or team meeting discussions.

To highlight a couple of my other favorite essays, I particularly enjoyed Marcus Baker’s whimsical treatment of convincing someone to install your software in “Install Me” and being a script junkie myself, I found myself nodding in agreement with Cay Horstmann’s “Step Back and Automate, Automate, Automate.” As a conversation starter, thought provoker, or small collection of wisdom’s, you will likely enjoy many of these essays yourself.

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

Principles of War as Applied to Business Leadership – Part 1

Sunday, December 21st, 2008

 

Many authors have previously described the relationship between business and war and we believe that the most successful businesses approach their operations as would General Douglas MacArthur when he claimed that “In war, there is no substitute for victory”.

Carl von Clausewitz offered several tenets of war in his essay “Principles of War” and later expanded upon those in his book “On War”.  Many armed forces throughout the world have taken portions of these tenets and adopted them for their own use.  This post is the first in a two part series relating the 9 US Armed Forces Principles of War to your everyday business activities, strategy and tactics.  The 9 US Principles of War are Objective, Offensive, Mass, Economy of Force, Manuever, Unity of Command, Security, Surprise and Simplicity.  We will discuss the first 5 in this post and the next 4 in a subsequent post.

Objective.  The US Armed Forces definition is to direct every military operation toward a clearly defined, decisive and attainable objective.  We think this is pretty self explanatory and includes concepts about which we’ve previously blogged such as the need to set aggressive but achievable goals.  The most important aspects of “Objective” as applied to your business are for your goals to be clearly defined, well understood, measurable and attainable.

Offensive.  The military definition is to seize, retain and exploit the initiative.  The business definition here is found by looking at what Offensive implies – specifically that it’s all about time to market and getting the right features, products and services out and adopted first.  Being first offers the best chance at achieving virility within the market, and creating a viral marketplace or product is the military equivalent of seizing the high ground.

Mass.  The military definition is to mass the overwhelming effects of combat power at the decisive place and time.  Mass here in military terms is different from the concentration of forces which may not be desirable.  Combat power refers to all the aspects of military power from infantry and armor, to field artillery and other combat multipliers. The business equivalent is to ensure that your business units are aligned with your greater business objective and that they are contributing to it properly.  Your technology, product, marketing and finance teams should all realize and be contributing to the core objectives necessary to win your business battle.  If you wish to win quickly, they cannot be marching to separate agendas and they should not be fighting with each other.

Economy of Force.  This one can be confusing, but within the military definition is a reference to “No part of the force should be left without a purpose”.  The military definition also hints that every part of the force should be used in the most effective way possible.  Goals and objectives are again part of this, but more importantly you should be able to answer the question of whether you are using the right team for the job at hand.  Not only should you ensure that every organization has a purpose directly relating to your most important initiatives, you need to ensure that they are the best team to have those specific goals and objectives.  Client Services and Customer Support teams might be useful in helping to QA new products but allocating them 100% to such an endeavor is probably not the most leveraged use of their time.  Conversely, forgetting to include Customer Support or Client Services in any product rollout is a failure to employ a very important part of your “combat power” in achieving product success.  While its useful for engineers to understand customer needs and complaints, allowing more than 5 to 10% of their time to be taken up by such activities is a costly endeavor relative to your future product needs.

Maneuver. Place the enemy in a position of disadvantage through the flexible application of combat power.  This one relates to how flexible you are in your product delivery lifecycle, and whether you are set up to respond to your competitors actions in the marketplace.  This IS NOT an argument that you should abandon products in flight and constantly change your strategy.  Constant change in strategy is a clear indication of a management team incapable of defining a winning path and it’s a early indication of likely future failure.  You should be flexible, and changing features or making course corrections a few times a year is appropriate.  Ensuring that your product delivery processes allow you the flexibility to change (with the additional cost that implies) is critical to success.  But constant change is not a strategy – it’s a recipe for disaster.