AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Tag » software developers

Newsletter – New Associate Partners

Below is part of our recent newsletter. If you haven’t subscribed yet, click here to do so.

New Associate Partners
We are very excited to announce that Geoff Kershner and Dave Berardi are joining AKF Partners.

For those who have worked with AKF in the past, you might recognize Geoff as he was part of our extended team a couple years ago. He most recently spent time at LiveOps running a Program Management Office in efforts including Agile development and PCI-DSS certification. He also spent 6 years at eBay and PayPal.

Dave is a long time friend and colleague as well who recently spent a number of years helping Progressive with incident and problem management processes. He has led various software development teams and spent 8 years at GE working on data warehousing and six sigma projects.

Check out Dave and Geoff’s full profiles.

We’re seeing three interesting areas continue to popup this summer:

  1. Cloud Computing
  2. Becoming a SaaS Company
  3. Agile Organizations

Here are some highlights:

Cloud Computing
One of our latest blog posts discusses the current trends with cloud computing. A common definition of cloud computing is the delivery of computing and storage capacity as a service. A distinct characteristic is that users are charged based on usage instead of a more conventional licensing or upfront purchase. There are three basic types of cloud computing: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Servie (SaaS).The major trend is that we are seeing more and more companies becoming comfortable with cloud offerings. In a 2012 survey with 785 respondents by North Bridge Venture Partners a very low 3% of respondents consider cloud services to be too risky and 50% of the survey respondents now say they have “complete confidence” in the cloud. The demand for SaaS offerings is growing rapidly as Gartner predicts that SaaS will hit $14.5 billion in 2012 continuing through 2015 when it will be $22.1 billion. This means your company should be leveraging the cloud as infrastructure where possible (burst capacity, rapid provisioning, etc) and if you’re not already a SaaS provider you need to be thinking about moving their rapidly. Which brings us to the second trend…

Becoming a SaaS Company
Given the comfort with cloud offerings that is now pervasive in industry if you’re don’t already provide a SaaS offering you need to start thinking about it now. One of the hardest things to do is to move from an on-premise or shrink-wrapped software company and become a Software-as-a-Service company. It is not enough to simply bundle up an application in a hosted fashion and label yourself a “SaaS” company.  If you don’t work aggressively to increase availability and decrease your cost of operations, someone with greater experience will come along and simply put you out of business.  After all, your business is now about SERVICE – not SOFTWARE. We have pulled together some advice such as start thinking about having two different products (on-premise and SaaS) or determine which business you want and kill the other one off. Attempting to satisfy both with a single architecture will likely result in you failing at both.

Our belief is that scalability and ultimately business success require architecture, organization, and process to all be aligned and functioning well. This brings up our last trend, how to organize for success as a SaaS company.

Agile Organizations
We’ve written lots of posts about this issue starting with how“old school” organizations are aligned functionally and then hownew Agile organizations are aligned by delivery of services. The organizations that align this way have remained remarkably nimble and agile despite sometimes having thousands of software developers. As a SaaS provider you need to rethink the traditional organizational structure and start thinking about how to organize to provide the best service possible at the lowest cost.

1 comment

From Technician to Engineer

We’ve had a couple posts on this topic of engineer vs craftsman vs technician but I found myself in the past couple of days discussing this topic in two different settings and thought it would be fun to revisit on the blog. I started the conversation with a post that quoted Tom DeMarco concluding that “software engineering is an idea whose time has come and gone.” Also quoted was Jeff Atwood stating that “If you want to move your project forward, the only reliable way to do that is to cultivate a deep sense of software craftsmanship and professionalism around it.” Marty picked up the conversation in another post stating that:

All of this goes to say that software developers rarely “engineer” anything – at least not anymore and not in the sense defined by other engineering disciplines. Most software developers are closer to the technicians within other engineering disciplines; they have a knowledge that certain approaches work but do not necessarily understand the “physics” behind the approach. In fact, such “physics” (or the equivalent) rarely exist. Many no longer even understand how compilers and interpreters do their jobs (or care to do so).

I think it is possible that we are seeing the evolution of our discipline as it struggles to determine what its final form will take. Computer science, information technology, software engineering, and other related disciplines are all relatively new fields of study. With a new discipline it should be expected that definitions and themes will need to be stretched or reconsidered.

Software engineers, similar to other engineering disciplines who are taught more “true” laws such as Newton’s or Faraday’s, also undergo something of an apprenticeship once their degree is conferred. Mechanical and electrical engineers work beside senior engineers who help them transition from the theoretical to the practical. Software engineers are often apprenticed in the same manner by more senior engineers. If the practical implementation of one discipline is considered engineering because it is based upon laws and principles, I would argue that the principles of architecture for scalability are of a similar nature. This in fact I think is a strong differentiator between technicians and engineers within the software development discipline. A technician can write code, setup a database, or administer a server. An engineer can architect a database or system or pool of servers such that it can scale. We’ve written several posts about the principles and patterns of scalability and a large part of our book is dedicated to these principles. Are these sufficiently established to be called a principle as defined in Wikipedia?

A principle is one of several things: (a) a descriptive comprehensive and fundamental law, doctrine, or assumption; (b) a normative rule or code of conduct, and (c) a law or fact of nature underlying the working of an artificial device

I still like the idea of software developers as craftsmen and -women but as I concluded in the other post, that discussion for me is as much about organizational size and control as it is anything else. The technician vs engineer discussion I think is best held in the light of are they or are they not applying laws or principles. As the American Engineers’ Council for Professional Development defines engineering “The creative application of scientific principles to design or develop…” Have we as a discipline, especially in terms of scalability, advanced enough to call what we use “principles”? Let us know what you think.


No Such Thing As a Software Engineer

Mike Fisher recently blogged about all the recent activity decrying the death of software engineering in his post “Engineering or Craftsmanship”.  The two terms should never have been stuck together in the first place.  Compared to the “true” engineering disciplines, the construct is as ridiculous as the term “sanitation engineer”.

Most other engineering disciplines require school trained engineers with deep technical and scientific knowledge to accomplish their associated tasks.  There probably aren’t many ground breaking airplanes designed by people who do not understand lift and drag, few ground breaking electronic devices designed by people who don’t understand the principles of electromotive force and few skyscrapers designed by people who do not understand the principles of statics and dynamics.  This isn’t to say that such things haven’t happened (e.g. the bicycle manufacturers turned airplane pioneers named the Wright brothers), but rather that these exceptions are examples of contributions by geniuses and savants rather than the norm.

The development of software is simply different than the work performed within true engineering disciplines.  With just a little bit of time and very little training or deep knowledge, one can create a website or product that is disruptive within any given market segment.  You don’t need to learn a great deal about science or technology to begin being successful and you need not be a genius.  The barrier to entry to develop a business changing service on the internet simply isn’t the same as the knowledge necessary to send a man to the moon.  Software, as it turns out, simply isn’t “rocket science”.   To develop it we don’t need a great deal of scientific or technical experience and it’s really not the application of a “real science” (one with immutable laws etc) as is say electrical engineering.

Sure, there are some people who as a result of training are better than other people and there is still incredible value in going to school to learn the classic components of computer science such as asymptotic analysis.  Experience increases one’s ability to create efficient programs that reduce the cost of operations, increase scalability and decrease the cost of development.  But consider this, many people with classical engineering backgrounds simply walk into software development jobs and are incredibly successful.  Seldom is it the case that a software engineer without an appropriate undergraduate engineering background will walk into a chemical, electrical or mechanical engineering position and start kicking ass.

The “laws” that developers refer to (Brooks Law, Moore’s Law, etc) aren’t really laws as much as they are observations of things that have held true for some time.  It’s entirely possible that at some point Moore’s Law won’t even be a “law” anymore.  They just aren’t the same as Faraday’s Law or Bernoulli’s Principle.  It’s a heck of a lot easier to understand an observation than it is to understand, “prove” or derive the equations within the other engineering disciplines.  Reading a Wikipedia page and applying the knowledge to your work is not as difficult as spending months learning calculus so that one can use differential equations.

All of this goes to say that software developers rarely “engineer” anything – at least not anymore and not in the sense defined by other engineering disciplines.  Most software developers are closer to the technicians within other engineering disciplines; they have a knowledge that certain approaches work but do not necessarily understand the “physics” behind the approach.  In fact, such “physics” (or the equivalent) rarely exist.  Many no longer even understand how compilers and interpreters do their jobs (or care to do so).

None of this goes to say that we should give up managing our people or projects.  Many articles decry the end of management in software, claiming that it just runs up costs.  I doubt this is the case as the articles I have read do not indicate the cost of developing software without attempting to manage its quality or cost.  Rather they point to the failures of past measurement and containment strategies as a reason to get rid of them.  To me, it’s a reason to refine them and get better.  Agile methods may be a better way to develop software over time, or it may be the next coming of the “iterative or cyclic method of software development”.  Either way, we owe it to ourselves to run the scientific experiment appropriately and measure it against previous models to determine if there are true benefits in our goal of maximizing shareholder value.