101–110 of 117 posts
Earlier quoted context omitted.
I once interviewed a project manager.. asked how he came up with deadlines. He said "ask the programmers and subtract 20%". Talk about a red flag in an interview!
I heard somewhere long ago "double the estimate and add a unit". Two weeks ==> Four months.
One of my favorite ones was a fellow who wanted an iPhone and iPad game done. He proclaimed that it had to be done for $10K. This game easily required six months of work. It also required server-side development and support. He also had no idea that every so often you need to fix, I mean, update, your apps because new iOS releases might break them. I was open-minded and decided to invest some time educating him on th…
Come on now. Don't blame the programmer being Indian for the problems your friend is having. Good programmers anywhere cost almost as much as they do in the US now. Globalization means that an Indian programmer has the same access to salary information in the west. He/she might knock off 10% to be competitive. You're friend could have easily got a cheap, inexperienced programmer anywhere else in the world, including…
If they searched for the lowest possible bidder in the US or Europe they'd get exactly the same thing.
I did not intend to imply that Indian programmers are not good. An ignorant fool looking for rock bottom prices will, more than likely, find them in India rather than the US or Europe.
You are in a closet, looking at a closed door. How big is the house?
You are limited by how long you can spend inspecting every nook and cranny of something, but you're only limited by time. The "door" metaphor is misleading. Nothing is standing in your way from exploring the space.
If you can find the "hard parts" of the house faster than someone else, you're likely to be a better estimator. In fact, my favorite trick is to focus on one hard part and extrapolate up. For example, write down how tricky it is to build the kitchen, or heck just a cabinet in the kitchen, so everyone gets it when you say "oh, by the way, there are 10 more rooms."
The Lifecycle of a Project Manager: Phase I: (Idealism) Treat building software like building a bridge. Analysis --> Design --> Development --> Testing --> Implementation. Phase II: (Pragmatism) Realize that Phase I doesn't work. Try to figure out why. Decide that the weak link is Analysis, i.e. we're no good at estimating and hitting deadlines because we never have good enough specs. Devote your life to the art and…
Then there are those who care very much how pretty the deliverable is (Eg Apple) but who also hit their deadlines. How? It's not via Phase IV as stated.
Apple is willing to wait and get it right in the next iteration.
They are doing a variant of Phase IV. The PMs are disciplined and upper management has the mindset of what we would hope for from sharp PMs.
You are in a closet, looking at a closed door. How big is the house?
P = programmer; NP = non-programmer NP: How long will it take? P: It'll take as long as it takes. NP: I don't understand. What does that mean? P: When you tell me that the product is finished, it's done. NP: You mean you can't estimate how long it'll take? P: I can't estimate when you'll decide that it is done, therefore an accurate prediction is impossible. From experience I know that a project like this can take fr…
So you have an easily identified problem to solve. Specification and Responding to Change are not mutually exclusive. You do the first. You get an estimate. When a change is mandated, you specify the change. You estimate it. When you discover a feature was under-specified, you re-specify it. You wouldn't find out your code doesn't work, and then not update the tests. Why would you treat specification any differently?…
Otherwise, you might have only a general feel for the magnitude of the problem at first: this is a 6-12 month kind of project. Perhaps a few days of prototyping and proof-of-concept tests will narrow that down a bit, though: we'll do the work in three stages, likely to take 2-3 months, 2-3 months and 3-4 months respectively, putting us in a 7-10 month window. As each stage develops, the reliability of any estimate for remaining time tends to increase, and perhaps a clearer idea emerges for the later stages as well.
In short, an estimate isn't worth much without some indication of confidence attached to it.
FWIW, my personal preference is to aim for about four qualitative levels: very general magnitude from initial overview of the project, more systematic estimate after clarifying detailed requirements and probably a bit of prototyping or proof-of-concept work, definite target date unless unexpected major disruption or change of requirements happens, and very confident once the project is into the final stages and no major hurdles remain.
Earlier quoted context omitted.
Your suggestion that a library's complexity/cost be amortized over the programs that use it is an interesting one. What I really want to know is when a program counts as independent of another program, so its length (and thus complexity) can be measured separately. Terms like "clean abstraction" don't clarify this for me. Is it as simple as saying: if my program calls your program and your program knows nothing about…
Sounds like mathematicians defining their assumptions - it's up to them where they draw the line as to what they will work on themselves, and what they'll accept as a given. i.e. it's arbitrary. Taking it back to turing machines, you can simulate any specific design/implementation of a turing machine on some another turing machine, given a program of constant size (an emulator for the first machine). This can be appl…
It's easy enough to measure the size of a program: LOC or something like it. But how do we define what a program is? Surprisingly, that's not obvious. As you say, how one carves it up seems arbitrary. The conclusion you came to is also one I've come to: you end up having to measure the total size of all the code that's running. But that seems absurd. (Unless you're a Forth person.) It means I can't measure my program's size without measuring, say, Linux's.
So to stave off the apparently absurd, we need a simple way to distinguish programs or systems from one another. That's my question.
If A and B both call each other, surely they are part of the same system. But what if A calls B, but B doesn't know about A? Does that make them separate? Sometimes one would say yes, for example if B is Linux. Can we always say yes? That would be convenient. But there are lots of such As and Bs in any complex program. That doesn't mean there are lots of programs.
I wonder if like so many other things in programming, this is in the end a social question and not a technical one. That's the trouble with referring to "reuse": it depends on how many people know about B and like it well enough to use it. It seems weird to say that A (or the system it belongs to) gets less complex depending on how many other programs use B. That would mean that a system's codebase could get more or less complex without a line of its code actually changing. Again - not an impossible view, but seems absurd.
I'm looking for a principle here because this way of thinking about complexity is a big part of how I work and because I want to have an entire company that thinks this way.
Earlier quoted context omitted.
I once interviewed a project manager.. asked how he came up with deadlines. He said "ask the programmers and subtract 20%". Talk about a red flag in an interview!
Brilliant. So much for 'just take whatever I tell you and multiply it by three'.
P = programmer; NP = non-programmer NP: How long will it take? P: It'll take as long as it takes. NP: I don't understand. What does that mean? P: When you tell me that the product is finished, it's done. NP: You mean you can't estimate how long it'll take? P: I can't estimate when you'll decide that it is done, therefore an accurate prediction is impossible. From experience I know that a project like this can take fr…
You are in a closet, looking at a closed door. How big is the house?
The problem is no one has locked you in the closet - just open the door and look around. Heck, you have a whole hour to look around the house and estimate how long it takes to build the thing. You are limited by how long you can spend inspecting every nook and cranny of something, but you're only limited by time. The "door" metaphor is misleading. Nothing is standing in your way from exploring the space. If you can f…
Its fractal. That "last" door could lead to 100 more. Oh and its almost always a horror flick with axe wielding maniacs(1) and booby traps(2) in each room intent on your destruction.
(1) The boss's boss's nephew who's a "computer whiz".
(2) $300,000 "developer tools" you have to use by fiat policy because, dammit, we spent a lot of money on them.