Development or Discovery
The biggest cost in any software development effort is always a factor of time. It became pretty obvious to me while working on a new reporting project. I've worked on a "ton" of systems over the past few years and with very few exceptions I can sit down and start making tangible progress very quickly (this may not be evident to my clients while I'm working on the plumbing, but that's a topic for another post) but with this project I've got about 4-6 hours into it and although I'm making headway on a couple of fronts I'm starting to sense the "churn" where it's more of a discovery process than a development effort. How much of your time is spent in discovery and how much in pure development? I think the ratio of discovery to development is major factor in developer efficiency and thus the time/cost in a software development effort. Although some external factors such as training, pair programming, documentation and mature processes may help with this ratio, the biggest impact on the ratio will be the person doing the development.
Discovery does not provide any real business value. Discovery is a critical investment that needs to be made. Just as you invest in your financial future, you should invest in your professional one as well. Once you’ve made this investment you start building capital, the capital can then be used to increase your Development time, this is where your investments should pay off. As Frederick Brooks states in his timeless classic “The difference between an exceptional developer and a Mediocre one is generally an order of magnitude”. Why is this the case? One reason is Developer Efficiency but the other is the capital the developer brings to the effort. Effective program manager realize this. When we talk about capital/experience/knowledge this can really be in three categories, general technology, domain specific, implementation specific.
Technology Capital
You, my dear reader are 100% responsible for this. If you work for a corporation that’s nice in that they may pay you to learn this knowledge, but in the end, this is how to program an Http Handler in ASP.NET or write a SQL Query, create a clustered index and so on. These skills are not implementation specific. The wider background of skill sets you have the more capital you will have and the more value you bring. As a consultant, if I am stuck doing “discovery” on a new technology I very rarely bill the client for this time. My clients pay me to “develop” they assume I know they technology.
Domain Specific
This is where you can start developing additional capital. Unless you pick on specific vertical, there will always be a portion of the time working on development efforts where you will be doing discovery within that domain. An example of this is my experience working in a Sales Force Automation company for 3 years on a number of different efforts. Although there was an initial learning curve in this vertical, over time the value I brought to the table during the system design meetings increased, the more knowledge I brought to the table, the quicker we could talk about what made their problems unique and in most cases these so-called “unique” problems were actually solved in other efforts and that experience could be capitalized on. My goal going forward is to pick a new domain every other year and start gaining that knowledge. Have you worked in one industry all your life? How many jobs are there in that industry? How well are you compensated in your industry with respect to others?
Client/Implementation Specific
Now is where it get’s interesting, each client does indeed have certain technologies, systems, database schemas that are unique to their organization. I would suspect that a considerable number of developers are “experts” in this area. As a consultant I worked at one client for about 3 or 4 years. They made a considerable investment in me in their specific data, not only just the structure, tables but also the subject matter. I made a significant investment in time in their data. At the point I started scaling back my work on their efforts, I had a much better understanding of the data within their systems then anyone did internally. This was a great engagement for both parties (Client & Software Logistics) however when I look back over those 3 or 4 years, what can I take away from that client specific data knowledge? Not very much as it turns out. From a billing perspective, I don’t have any problem doing “discovery” of a clients systems on their “nickel” especially if in the long run that knowledge won’t be useful anywhere but their systems.
The bottom line is in software development, the more capital you bring to the table, the less time you are doing discovery and the more time you do performing development. You are paid by your organization as an employee or a consultant to do development and not discovery.
-ec