August 21, 2014
I read the following article earlier today: Bronze Age Development. The article considers the amount of time spent testing compared to the amount of time in development, and reflects on the fact testing is likely to take longer than development – despite the fact that even now many people believe that it shouldn’t.
On consideration I suggested that, in fact, we could expect the relative amount of time spent testing to increase with the use of modern tools and reuse techniques. A quick search on the subject brought out the following quote:
“Fred Brooks (author of the Mythical Man Month) found that the following rule of thumb allocates time for software development with reasonable accuracy: 1/3 specification and design, 1/6 programming, 1/4 function and integration testing, and 1/4 system test.” (Avoiding software project overruns: watch the ratio!)
It seems that testing is historically three times the size of the development effort. I have been looking, but can’t find any studies which show how these ratios have varied over time, or for the different technologies and development styles. I’m slightly surprised by this, but for the moment would suggest that it would be worth using these values as a starting point. I would also strongly agree with the watch the ratios article above: Keep a track of the ratios of the levels of effort and time expended in your project. If they vary widely from reasonable values investigate why. If not, the chances are something might be going wrong in your process.
November 23, 2010
I have received interesting comments on my Estimation model article which discuss the relationship between project risk and the estimation of a project. In the estimation model I presented there is a consideration of complexity, and an approach to adjust for the stability of the estimation within the different development areas . These areas are likely to use differing development approaches and technologies. Thus, the estimation approach only factors risk into the estimation indirectly. Read the rest of this entry »
August 2, 2010
I was recently reading various articles about the use of “Evidence” in Management. The basic idea is that it is all too easy to start management initiatives based on a prejudice of what is going on. The result can be that inappropriate action on a situation. An example would be if a manager were to believe that his team were unproductive and needed extra motivation there are actions that might be taken to improve motivation, or apply control to demand more output. The reality of the situation might be very different, with the individuals motivated and wanting to produce more – but being hampered by an inability to work effectively in the environment. The appropriate actions here would be quite different, and action on the perceived problem would have no effect. It could even make it worse. Worse still, the problem might be that the team are productive but too much is expected of them for what is achievable in the situation.
What solution is proposed? Read the rest of this entry »
May 19, 2010
How often do you end up looking at one problem, and find that to solve it you have to solve all the others that it is interconnected with at the same time? One of the reasons I have found dealing with performance problems interesting over time is that they tend to be like this. It is only relatively recently, however, that I have come across the idea that this is a general class of management problem that occurs in business. They have been studied under various titles (e.g “wicked” problems), but the common feature is complexity and an inability to have a single easy solution. Read the rest of this entry »
May 6, 2010
As a professional I find that I should do more networking than I do. I’m sure I’m not the only one in this situation. As such the following article may be of interest:
10 Questions for Effective Networking
The article is written by a “professional coach” who discusses the benefits of value-based questioning when networking. It seems a better approach than the standard sales-lead approach, and may be useful in breaking the ice with potential clients for the future. I found it interesting, see if you do.
March 3, 2010
I liked this post and thought it was worth sharing on the Sarquol site… it is a semi-serious look at ways to keep momentum when the going gets tough.
WIMMING YOUR WAY THROUGH A HARD JOB
February 25, 2010
I recently needed to consider the state of a System Architecture and consider the changes likely to be needed over time. Thus, I was trying to produce a “Roadmap” for the architecture into the future. The challenge was that the future is uncertain. Some items can be planned for, and others are dependent on the way the business and technological environments develop. These developments can be considered to be the product of various “forces” playing out in the environment of the system. How then can you address this complexity? Read the rest of this entry »