I had a conversation about estimates during a recent interview. I asked about how the company deals with those, and the interviewer said they don't do estimates because there's never been a time where something productive came out of one, and I think it makes sense. In my experience, when an estimate is spot on the world goes on as if nothing happened. When it's incorrect, all hell breaks loose and it's every man for…
When a company uses software estimation, it suggests strong distrust towards the software people and is looking for justification of those huge costs.
Most often it means some shitshow happened or is still going on in there.
The issue is that you are being asked to estimate something that has never been done before. Even houses always go over time and money and that is fairly straight forward. These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Some relatively small number of those units. If you want a quote it will take an extra 1/4 of the estimate worth of time for an…
'I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"'. In well-run sales teams, that is exactly what happens. There is a constant move towards more accuracy and tightness in forecasting. In poorly run sales teams, the reps basically set their owns quotas (padded, of course, to mitigate against massive uncertainty) and then are very imprecise at m…
i think well run teams in general have a lot in common. Not just sales or engineering but all well run teams.
At least in a business setting I think the whole concept of a project needs serious reconsideration. We end up more often than not trying to fit developing a digital product into an enormously stupid gantt chart to execute some poorly thought “business requirements”. I prefer to talk products and not projects, I deliver the full thing including “growth” as adoption doesn’t come “if you build it” even within a Company…
Funny when you look at the actual definition of a project straight from PMP.
"a temporary endeavor undertaken to create a unique project service or result."
No "projects" in software fhat I know of are actually temporary. They only end when management fires the people behind them, it gets cut off or there is no adoption.
We in software think of projects really as things which we create and which need maintenance in order to live. There is never some "end" to it.
Because it doesn't even conform to its own definitions, we could therefore conclude that the whole PMP project management discipline, as applied to software, is a scam.
In his book “Code Complete”, Steven McConnel speaks about metaphors. He reasons that metaphors are necessary to be a good developer as it helps visualize the act of coding. The metaphor he prefers is the “construction” metaphor. This metaphor he argues best explain the act (some would say art) of programming and gives developers a language to speak in that brings clarity to the development process. When in constructi…
The reality is that software development is nothing like engineering or construction, it's totally different. You don't build a quick house, let people live in it and start building the walls whilst they live there. Humans like to think via metaphor because it's a least-effort mode of thought but sometimes there just isn't one and it's just tough luck and start thinking from first principles instead.
My point was more that the software developer have to not just build with existing material and equipment but have to invent and build those on the fly.
My problem with this is all estimation is hard. Period. Quantitative discussions of something that has been done? Fairly easy, if still not accurate. Discussing something that hasn't been rehearsed before? You can really only discuss how long you are willing to work on it. Not how long it will take to get done. Fun examples. How long would it take you to clean out your fridge? How long would it take you to learn to p…
I like this analogy. But I was picturing myself asking my sales manager "How long would it take you to learn to play a song on piano?", and I'm pretty sure he would reply "but you touched a piano before, you are supposed to be a professional piano player ! A professional piano player surely knows how long it would take him to learn how to play a song". So I guess he would miss the point totally :/
Ironically missing that some folks will never be able to learn some songs.
And, learning to play an existing song doesn't necessarily translate to being able to write one.
Make a complete list of things to develop in a spreadsheet, "complete" means every single item the customer wants to see in the product, not only every single button but also every single label, that should be definable by reading the project specs or mockups. I think "forgetting things" is the first big mistake leading to under estimations. Add an estimate that you multiply by three in front of each, ie. if the dev…
> "complete" means every single item the customer wants to see in the product, Ah, but the customer does not know everything they want, due to the fractal nature of reality. The closer you get to the end product, the more detail is resolved, and more work is added.
it's pretty a well known saying that the last 10% of any project takes 90% of the time.
Make a complete list of things to develop in a spreadsheet, "complete" means every single item the customer wants to see in the product, not only every single button but also every single label, that should be definable by reading the project specs or mockups. I think "forgetting things" is the first big mistake leading to under estimations. Add an estimate that you multiply by three in front of each, ie. if the dev…
ReRe's Law of Re petition and Re dundancy [4] somehow does not apply to you: A programmer can accurately estimate the schedule for only the repeated and the redundant. Yet, A programmer's job is to automate the repeated and the redundant. Thus, A programmer delivering to an estimated or predictable schedule is... Not doing their job (or is redundant). [4] https://news.ycombinator.com/item?id=25797519
I think the explanation was made in another comment where they say "don't forget to estimate time for research & design", which explains why the *3 multiplier works for me. And yes, I feel that most of the work is redundant, there's always like network services of some sort or web pages, databases, linux servers, a humain interface, other services depending on the project like a message queue or a caching server or both, background workers and scheduled code execution... things I had been doing for ~10 years back in 2012. Data structures, workflows, they change between gigs, and each gig has its own particularity, but 90% is the redundant from a gig to another: HTML/CSS/JS/Python/SQL/Networking/Storage/Linux stuff
If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who'd love to have this :) My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software dev…
More important than estimating is knowing how to sequence the work. I often see teams try to build the entire DB schema first, or built the interface out one wire at a time. The agile approach of building small, vertical parts of each feature tends to work much better in my experience. For example say you have a CRUD application with a page for editing and searching complex objects. Rather than building the entire se…
agree with the adaptability of change requests from clients, but i would say only insofar as the design issues you're mentioning are actually addressed as quickly as they are surfaced. Otherwise this type of building eventually grinds to a halt.
another commenter sort of hinted at this, but this type of process has a downside of prioritizing short term design decisions that lead to working code. It takes time and sometimes a lot of thought to think about the system and the problems deeply and ask yourself if you've created the right primitives.
If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who'd love to have this :) My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software dev…
Make a complete list of things to develop in a spreadsheet, "complete" means every single item the customer wants to see in the product, not only every single button but also every single label, that should be definable by reading the project specs or mockups. I think "forgetting things" is the first big mistake leading to under estimations. Add an estimate that you multiply by three in front of each, ie. if the dev…
Software development is the process of writing a complete specification, including every single button and label. If you have a formalised complete design, you could write a compiler to do the work for you.
> And I’ve also seen wise use of estimation but that is rarer I've got a question for you here, what is a wise use of estimation? What problems are estimates the ideal solution for? In the context of software development? I can think of only two: planning headcount and priorities (aka planning the order in which you do things). When you focus on those problems, you realize there's no need for an accurate estimate. Al…
Wise use of estimation is projection. You don't need to do much more than count stories. It would be honest and without agenda. I've never seen it either.
Yes exactly! When you ask someone for their estimate, you're getting a quote from them.
When you actually want to predict the length of time something will take, you rely on historical data and create a projected forecast. It never involves asking somebody for their best guess. That's how every single "other thing" we predict is handled, so why is software done differently.
Actually, I've seen some of these ideas being talked about in KanBan circles, like tracking lead time and cycle time, and then using monte carlo simulations to forecast, but I've never actually seen them in practice.