2013 was the year that I finally decided to replace my ancient two channel sound system with a 5.1 channel home 
theater capable system. My old setup was very simple. A pair of ADS speakers that I had bought when I was in college (1981) and a Nakamichi receiver that I had bought shortly after I was married (1989 or so). I had other components, but most had been replaced with a cheap Blu-ray player that I “won” at a silent auction a few years back that played most of my CD’s. I still have a B&O turntable that is serviceable, but I rarely play my vinyl these days.Continue Reading
Posts Tagged with estimates
Top Six Estimating Tips for Programmers
Every programmer struggles with providing estimates. It is a universal truth of software development. Most of the time we go way too deep, try to be more precise than we have any reason to be. Many times we have fear driving our estimates – what if they are too big (will they cancel the project? or will they assign the work to someone else?) or worse, what if they are too small (will they fire me because I appear incompetent?).
Here are my top six tips for solving estimation challenges in software development projects:Continue Reading
Proper Task Length
Glen Alleman in his post How Long Should Tasks Be gets to the heart of an important issue. When planning, how long can you wait before you know that you are late.
In principle, it works like this – you don’t know you are late until you fail to complete a task on schedule. How late you are depends on the remaining work in the late task. How long can you wait to determine that a task is behind schedule? That depends on where you are on the project timeline and how much “margin” is remaining in the plan.
In practice there are other dependencies. Measurement frequency is important. The more frequently you measure progress against the plan, the smaller tasks increments you will naturally prefer. You want to see progress at every measurement cycle.Continue Reading
Estimation Purposes
Mike Cottmeyer’s post about How to Think About Estimating is freakin’ brilliant. I applaud him for speaking his mind, and telling us how professional software delivery can get done.
Why? Because he gets down to the guts of why estimation is hard for so many teams, and while it seems to me that half of the agile community is ready to give up on estimation altogether, Mike hangs in there with a reminder that the customer has a right to a rational contemplation of cost and delivery schedule. Why – because they are paying the bill. Period. Maybe there are cases (startups, or companies with more money that sense), where the budget or the schedule are not constraining the delivery of software, where the customer doesn’t ask how much or how long. I have never been in that situation.Continue Reading
Reality
Spent the weekend (really the last two weeks) preparing to engage some
business partners on a project whose plan got somewhat sideways.
much longer to elicit because the business vision was not complete, nor
were all that participated invested in a vision. There has been a lot of drama around this project, because business execs
felt deceived. While the project team felt like it had been
extraordinarily transparent. Then someone said it. Business reality implied a fixed bid process. While
IT was working on a time and materials project. It explains why business gets angry and hostile when we shed scope to meet
a date. Their reality is fixed bid. Internal IT rarely does fixed bid estimates. There is no motivation. No
profit. We only ever bill what we spend. But what if we did? What would
we do with the profit? Reality?