I'm Sure It Will Only Take You A Few Days To Code • Hacker News Board

Re: I'm Sure It Will Only Take You A Few Days To Code

#51

Post by m_eiman » Wed, Apr 04, 2012, 6:03 AM UTC

dshipper wrote: post #15

hkmurakami wrote: post #12

Disclosure: I am currently a software PM I actually think that the same principles apply to _any_ form of creative activity. Let's say I'm going to write a 300 page book. I can take my typical wpm speed, do some math on it, and say that it will take me X hours to do this. A book, on the surface, should fit into the "size and speed" heuristic. But of course, this is nowhere near the case. No decent piece of writing ev…

I agree completely but I think there are two things that make software slightly unique from any piece of art: 1. We have a cultural context that tells us how hard it is to produce something like a song, or a painting. There's a reverence for it. And so people tend to back off of their estimations for the amount of time required to produce it. 2. Software isn't physical. You can hold a big book in your hand say CRAP!…

We should always deliver a physical copy, on paper, of everything written during a project together with the invoice. Every whiteboard brainstorm, every source code diff and every email sent and received. Should make a decent stack of paper to give the customer a sense of perspective!

Re: I'm Sure It Will Only Take You A Few Days To Code

#52

Post by gruseom » Wed, Apr 04, 2012, 6:07 AM UTC

6ren wrote: post #49

gruseom wrote: post #41

Earlier quoted context omitted.

the existence of the right library can save 10,000 hours Can anyone define for me the difference between a library and a language? If I take all my functions and put them in a "library" and then just call them, have I made my program shorter? What if I define them all as built-in to the language? Intuitively, those seem like tricks and not genuine simplifications. Why don't they count?

Perhaps, moving into a library means it must be a clean abstraction and reusable - there's some legitimacy to considering it no longer "part of your program", so your program's shorter. If it is in fact used by other programs, by distributing its length over them all, your first program literally is "shorter" even including the library cost. The library/language distinction seems less important these days (e.g. stand…

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 mine, then yours is my "library" and I need not add its size to my total?

If I make a system and call parts of it a "library", is it less complex than if I call everything the same program?

Re: I'm Sure It Will Only Take You A Few Days To Code

#53

Post by jtheory » Wed, Apr 04, 2012, 6:36 AM UTC

Is Pachelbel's Canon considered complicated as far as music performance goes? Reading that knocked me right out of the flow of this article. What's he thinking of? Maybe someone's complicated improvisations on top of the (really simple) canon?

On topic: the post didn't really cover where the layperson's base estimate comes from -- a layperson sees X pages, or X features, and multiplies that by... what?

The reference they use varies hugely, in my experience; many are trying to imagine what's involved in developing a "feature" -- which yes, will generally be a massive underestimate... not always, though.

There are also plenty of laypeople who imagine that everything they see is incredibly complex & difficult to create (I have a neighbor who imagined that writing software meant typing in the gunk he saw when accidentally opening a binary file in notepad), and all written from scratch -- so a simple blog would take ages to build, because it's obviously complicated stuff.

In real life, some quite complicated things come for free, other seemingly simple things take gobs of time, sometimes unexpectedly... it's a big mess. And just as some of the harshest wildcards (like nasty bugs in old browsers) are calming down, more form factors, interaction modes, etc. are popping up, so I'm not sure it's going to be a problem we can stop talking about anytime soon.

Re: I'm Sure It Will Only Take You A Few Days To Code

#54

Post by xiaoma » Wed, Apr 04, 2012, 6:58 AM UTC

gruseom wrote: post #40

6ren wrote: post #27

Reminds me of "open textured" in legal philosophy: the idea of precedent in law is you can use it to predict how a court will decide in future. This mostly works, but if you have a bunch of cases (data points in multidimensional space), simple interpolation isn't always accurate. You need to look at the specifics of the present case (there's still uncertainty because each judge has an individual perspective, but that…

That makes me wonder what other disciplines there are that have the unpredictability and open-endedness of software. I read that on large construction projects, a 1% overrun is considered failure. That is clearly a different universe. Who else is in our universe?

Mathematicians are. They couldn't tell if Fermat's last theorem was solvable in a day, or a year... or not by the efforts of many of the world's greatest minds for centuries.

Re: I'm Sure It Will Only Take You A Few Days To Code

#55

Post by keithpeter » Wed, Apr 04, 2012, 7:11 AM UTC

m_eiman wrote: post #51

dshipper wrote: post #15

Earlier quoted context omitted.

I agree completely but I think there are two things that make software slightly unique from any piece of art: 1. We have a cultural context that tells us how hard it is to produce something like a song, or a painting. There's a reverence for it. And so people tend to back off of their estimations for the amount of time required to produce it. 2. Software isn't physical. You can hold a big book in your hand say CRAP!…

We should always deliver a physical copy, on paper, of everything written during a project together with the invoice. Every whiteboard brainstorm, every source code diff and every email sent and received. Should make a decent stack of paper to give the customer a sense of perspective!

Like this?

http://craigmod.com/journal/digital_physical/

(was on daringfireball the other day)

Re: I'm Sure It Will Only Take You A Few Days To Code

#56

Post by gruseom » Wed, Apr 04, 2012, 7:14 AM UTC

xiaoma wrote: post #54

gruseom wrote: post #40

Earlier quoted context omitted.

That makes me wonder what other disciplines there are that have the unpredictability and open-endedness of software. I read that on large construction projects, a 1% overrun is considered failure. That is clearly a different universe. Who else is in our universe?

Mathematicians are. They couldn't tell if Fermat's last theorem was solvable in a day, or a year... or not by the efforts of many of the world's greatest minds for centuries.

Agreed. Math is art with proofs. Or formalized imagination. Or something. It would be significant if that's the closest thing to what we do in software. (Obviously, math and computing are close as theoretical disciplines, if not overlapping totally, but that's not the same question.) Is there any kind of construction or engineering that comes closer? Because those are the analogues people have mostly (and largely unhelpfully) turned to when trying to understand how software projects work. People say "engineer" when they mean "programmer"; they never say "mathematician".

Re: I'm Sure It Will Only Take You A Few Days To Code

#57

Post by keithpeter » Wed, Apr 04, 2012, 7:16 AM UTC

kamaal wrote: post #34

bigiain wrote: post #26

Earlier quoted context omitted.

Not only that, but they require all the skill and experience of truly world-class experts in their fields. Yes, Linus can throw together an amazing dvcs that scratches his particular current itch in a weekend. The just-graduated CS major you're pitching your idea to? The one with three whole php and/or ruby websites under his belt? He'll be able to do that too - after spending 20 years running the worlds most popular…

I can/have built in some amazing stuff over weekends. But generally the requirements for that are, and in no specific order. 1. I must be in a flow. 2. I am using a technology very familar, so I know the tools and many things. 3. I am doing something new. Not maintaining some ones code or interacting with an external team. 4. No disturbances and other office distractions like office emails. Building new things are di…

Mark Bernstein is recoding a program called StorySpace which dates from 1980s?. He is blogging about it. Day 6 will give a flavour

http://www.markbernstein.org/Mar12/Day6.html

He is working on a familiar design, and knows the old code. He is recoding in newer tools.

Re: I'm Sure It Will Only Take You A Few Days To Code

#58

Post by 6ren » Wed, Apr 04, 2012, 7:25 AM UTC

gruseom wrote: post #52

6ren wrote: post #49

Earlier quoted context omitted.

Perhaps, moving into a library means it must be a clean abstraction and reusable - there's some legitimacy to considering it no longer "part of your program", so your program's shorter. If it is in fact used by other programs, by distributing its length over them all, your first program literally is "shorter" even including the library cost. The library/language distinction seems less important these days (e.g. stand…

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 applied to turing machines which include libraries of arbitrary size. So again, it's up to you where you draw the line.

I wonder if the confusion is to do with why you want to draw the line?

I doubt these answers will satisfy, because I'm not clear on your question. I find such questions easier to answer if I get clear on the purpose - why exactly do I want to know how complex a program is? If it's purely out of curiosity, what is the nature of that curiosity? Complexity, from what point of view? how am I thinking about it? What am I worried/concerned about?

BTW: I was going to use "amortized", but it seems specific to over time (an online dictionary supports this). But it does feel correct - is it a legitimate generalization?

EDIT I really think my first answer was best, so I'll flesh it out a little. I understand your question as being, when we measure the length of a program, we can factor some of out into a library routine, to make it shorter. But isn't this shifting things around just cheating? If it simply was cheating, then I don't think you'd have any question about it. I think the puzzle is that it does seem legitimate, in some way, yet also seems like cheating.

My answer is that instead of measuring the length of your program, you measure the aggregate length of all the programs on your computer. From the perspective of this larger system, if that part that was factored into a library was also used by other programs, then it would make the total length shorter. The "clean abstraction" isn't an important consideration in itself, but comes into it only because that's the (a?) way to make it reusable; and being reused is crucial for factoring a component out into a library, to decrease the total length of all programs.

[ One could generalize beyond "all the programs on your computer" all possible programs, weighted by their probability. The probability captures the usefulness of the programs (there's many more nonsense programs than useful ones in the set of all possible programs). This is important, because a uniform probability density wouldn't enable factoring out to make the total shorter - you need some regularity/redundancy for that, which requires some unevenness. Typically, programs do have commonalities because the programs they solve have commonalities. ]

Basically, taking the widest view, would factoring this aspect out make the total system shorter?

I think this explains the sense that factoring out some code into a library does make it shorter, even though when looking at that program in isolation it's just moving things around.

Re: I'm Sure It Will Only Take You A Few Days To Code

#59

Post by aerique » Wed, Apr 04, 2012, 7:30 AM UTC

jarrettcoggin wrote: post #22

dshipper wrote: post #15

Earlier quoted context omitted.

I agree completely but I think there are two things that make software slightly unique from any piece of art: 1. We have a cultural context that tells us how hard it is to produce something like a song, or a painting. There's a reverence for it. And so people tend to back off of their estimations for the amount of time required to produce it. 2. Software isn't physical. You can hold a big book in your hand say CRAP!…

And one of the things that throws some software estimates out the window is when a developer/programmer gets in the zone. There have been times I've hammered out a problem that I had spent days on in a few hours when the inspiration/flow/etc. hit. Something I would have guessed would have taken me a few days more, I end up hammering out in 3 hours. And when you pull these kinds of tricks... People think you can do it…

But would the problem have taken only a few hours if you hadn't spent those days on it?

Re: I'm Sure It Will Only Take You A Few Days To Code

#60

Post by dustin » Wed, Apr 04, 2012, 7:31 AM UTC

edw519 wrote: post #19

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…

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!