My Life Passing Before My Eyes
I have been going through books, papers, etc. in preparation for our move (to another building in the same complex). The new facility is brighter, more modern and should be wonderful. But throwing away anything has never been my strong suit.
I now think I know what people mean when they say they see their lives passing before their eyes.
- How could I throw away Ed Yourdon’s “Writings or the Revolution” or any of Ed Yourdon’s books for that matter. I nearly wore out the pages of his structured analysis & design books.
- A complete library of Ada handbooks, specs, ways to estimate Ada, etc. This included a paper I wrote saying Ada may not be the panacea that people hoped for.
- Books on CP/M, the predecessor to MS DOS
- My college text books in management, mathematics and other areas
- Numerous courses we developed and presented. Including the view-graphs for one. View-graphs were transparencies put on a light source and projected similar to today’s Powerpoints…only they weighed a ton.
- The programming books for the CDC 1700 and the IBM 1130 computers where I cut my teeth.
- My wife’s business card where I first met her (that is a keeper)
- The letters we sent in 1988. And on and on
Someone said many of these books might be sellable on Ebay. I hope not.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
296 Billion Dollars in DOD Cost Overruns: 2009 GAO Weapons Systems Assessments
The full document GAO assessment of Weapons Systems is an update to the 2007 assessment.
It states “ Our review this year indicates that while the overall performance of weapon system programs is still poor; there have been some modest improvements in DOD’s acquisition outcomes: total cost growth on this year’s portfolio of 96 major defense acquisition programs has decreased marginally compared to the 2007 portfolio.”
Programs started in recent years have more knowledge about technology and design at key points in the acquisition process.
- Cumulative cost overruns are almost $296 billion in 2009 dollars
- 64 of 96 active defense programs reported increases in their projected cost since their initial cost estimate.
Sources of the problem:
While there are different ways to measure the extent and nature of cost growth, there is agreement between DOD and us on the sources of the problem:
(1) POOR REQUIREMENTS AND KNOWLEDGE: programs are started with poor foundations and inadequate knowledge for developing realistic cost estimates
(2) ARTIFICALLY LOW COST & SCHEDULE ESTIMATES WITH LOW TECHNOLOGY READINESS LEVELS: programs move forward with artificially low cost estimates, optimistic schedules and assumptions, immature technologies and designs, and fluid requirements
(3) REQUIREMENTS VOLITILITY: changing or excessive requirements cause cost growth
(4) REQUIREMENTS GROWTH and INADEQUATE VALUE CONSIDERATION OF CHANGES: an imbalance between wants and needs contributes to budget and program instability.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
10 Laws of Software Productivity
I have been teaching these productivity laws for years and these effects can be modeled in our SEER-SEM model. But the real point is you cant just mandate software completion dates and effort without paying the consequences. Consequences included technical debt, failing applications, unfortunate limited functionality (this is where agile can help in many situations by building the most critical functionality first) and more. Much of this is based on entropy (decreased productivity) as team sizes increase.
Some people make a case that there is no entropy or even more efficiencies as software gets bigger. When analysis is completed this is generally the result of natural reuse or copy / paste, more efficient reintegration and retest, and reduced rework. The 10 laws are: Read more
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
The Three Cloud Definitions Refined
It is so interesting how people call anything that is not based on on-premises computing as cloud these days. Rent an off premise server and suddenly you are “on the cloud.” Host your web site with an outside Internet Service Provider (ISP) and your web is “in the cloud” The evolved definition accounts for any approach where IT is not on your premises and users connect via the network to an infrastructure you do not own. You can further break down the cloud into three categories:
1. Software as a Service (SaaS) - Application hosted in an off-premise data center users connect to and pay for in a utility model. Customers don’t own the license or hardware; rather, they connect to the application over a public or private network.
2. Platform as a Service (PaaS) - A PaaS model means the servers, storage, and development environment for a specific custom application are hosted by a specific supplier, such as the ecommerce web engine owned by Amazon. Customers write and host their applications on that provider’s network, paying by the megabyte and CPU cycle.
3. Infrastructure as a Service (IaaS) - This is a virtualized infrastructure in the sky – sometimes without even an operating system – you connect to and do with it whatever you wish. IaaS is essentially a co-location strategy where the IT assets are virtualized and provided to you in a unit consumption model.
This was abstracted from this article from baseline.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
ScrumMaster and Techical Debt
Technical debt can be reduced by ensuring “done” is a robust “done” rather than a weak “done.” A robust “done” means the software is adequately tested, and meeting the objectives of the development. Unfortunately many projects use the exhaustive rule of testing… that is test until you run out of time, then ship. One of the major benefits of agile methods are (hopefully) that the software is sufficiently tested.
I recently heard of projects that had 10 teams of 10 doing agile approaches successfully on a single program. Hard to manage but working. This is a good thing.
It must be noted that Scrum addresses uncertain requirements and attempts to put multiple disciplines into a team. ScrumMasters are multi-talented and experienced. Just claiming to be doing Scrum, Agile, etc. is not a way to success.
Recent data showed about 80% of experienced agile teams do a macro level estimate upon project start. For larger projects this is essential… For very small projects it is probably OK to tell the stake holders you will be done when you are done since it will only be a few months. That doesn’t fly for larger programs.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Barry Boehm Tribute
What a privilege it was to participate in the recent tribute to Dr Barry Boehm in Beijing. In addition to Professor Boehm himself, many of the icons of software research were present. There were some amazing presentations which should be posted on the web soon. The presentation I gave includes an introduction to Barry’s academic genealogy and his PhD legacies, Jo Ann Lane and Ricardo Valerdi, as well as an amplification of the 8 principles in Barry’s introduction to my book: Software Sizing, Estimation, and Risk Management.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Software Integrate Then Test
I have recently heard people referring to the integrate then test approach to software development and was concerned about its risks.
After an excellent talk by Rational’s Walker Royce, I now understand the approach and agree that it can reduce project risk.
Here is what is meant:
Essentially it doesn’t mean to not test units of software at all, just throwing initial compiled versions into the integration mix.
It does mean taking nominally working software components, before all the coverage testing, stress testing, etc. and integrating them to test the integration itself before spending all the time on the individual testing of software that might not integrate… working out the integration issues first. Read more
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Project Prediction Infographic
