171–180 of 230 posts
So yeah, maybe throw away the first draft, but don't do what I did.
[Brook's Law of Prototypes] Plan to throw one away, you will anyhow. Fred Brooks, University of North Carolina
If you plan to throw one away, you will throw away two. Craig Zerouni, Computer FX Ltd., London, England
Prototyping cuts the work to produce a system by 40 percent. Larry Bernstein, Bell Communications Research
[Thompson's rule for first-time telescope makers] It is faster to make a four-inch mirror and then a six-inch mirror than to make a six-inch mirror. Bill McKeeman, Wang Institute
The short version is that the team formed and started working on the designated product, but very shortly after a VP-level exec got directly involved and started asking about where "his" product was. This was before I joined, so I'm not sure if the original direction was supposed to include this or if there was some management nonsense behind it, but the team had to quickly pivot and deliver something for this needy VP that was kind of sort of related to their stated goal.
In any case, the programmers got their marching orders and rushed out something to satisfy the VP, then went back to focusing on their original goals.
The real work overlapped, in technology and business function, with the rush goal. After they were done, they could have stepped back, taken a look at what they did to get it done, identify the shortcomings, missteps, and undesirable consequences of the decisions made for that work.
They could have proceeded with the main work using all the lessons from the 'emergency' work, and avoided a lot of the problems they'd created in rush to production. Instead, they decided to build, or perhaps more accurately defaulted to building, the real product on top of the work they done for the rush job.
After another six or eight months, the project was in serious enough trouble that programmers were leaving, and they ended up with an almost 100% turnover in engineers. The manager's response was to start micromanaging everything and set the team up for a death march to a predefined release date.
This would sound like questionable advice except that the best code I wrote in college resulted from an accident… I’d sat down all night and written some C for a graphics class. Everything was great, yay, victory. Proceeded to tar it up per class guidelines and did something like this: tar cvf assignment.c assignment.h data.txt readme whatever.cuz And as many of you no doubt recognize, I’d forgotten to supply a desti…
This is exactly the type of story I tell when people are anti pair programming. I ask them if they’ve ever lost a days code (usually asking if they ever used source safe) and that when they finally knuckled down to write it again, it took about 20 minutes. As the writing the code wasn’t really the hard part or the bottleneck, solving the problem was the hard part. Hence pair programming having two heads on one proble…
Earlier quoted context omitted.
I don't understand why you consider loops an abstraction. They are some of the most basic building block.
Loops are an abstraction over conditional branching and, depending on the kind of loop, some other things.
How?
"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." [0]
I don't throw my first version away, I just start really simple and evolve it iteratively, making sure it works at each stage, and by the time it's done very little of the original code remains.
0. https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_la...
What every HN commenter is replying to: "throw away your code"
--
I've written software professionally for 14 years and just last week I wrote code for ~3 days and then decided I was on the wrong track, and checked out main and made a totally new branch, spent ~1.5 days re-writing my feature in a totally different way. I had come to realize the new way would be easier to write, MUCH easier to test, and a bit more maintainable long-term. Nothing wrong with throwing away un-merged code if you decide that merging isn't the right decision, and feel you have learned valuable lessons to inform the re-write.
As an ML-focused python dev I have never been able to break the habit of REPL-driven development, but I find it works really well for "building code that works" rather than coming up with a tower of abstractions immediately. A typical python development workflow for me is: * Start with a blank `main` file and proceed linearly down the page, executing as I go. * Gradually pull out visually awkward chunks of code and p…
I don't understand why you consider loops an abstraction. They are some of the most basic building block.
It would be unnecessary to have a loop over keys of a dictionary to call function xyz when you can just repeat the xyz calls (it would look nicer too)
Unless the dictionary is huge and dynamically loaded.