The Final Push

Comments (Archived):

1. Oh, yeah, the infamous Pareto Principle https://en.wikipedia.org/wi…

   1. Yup.I was going to paste that link to the Pareto principle in here but first I did a quick search and found your comment, therefore I didn’t bother.In Judaism the person who completes a mitzvah (commandment or good deed) is the person who get credit for it, not necessarily the person who started it. Our sages (great rabbis) understood that it’s often much easier to start a task than finish it.See…Completing a Mitzvahhttps://rchaimqoton.blogspo…”The Midrash maintains that the fulfillment of a commandment is only attributed to the one who completed the fulfillment of the commandment.”Jews move forward by looking to our tradition for wisdom and guidance. Many modern Americans, by contrast, tend to struggle to make sense of a mishmash of information from whatever tradition happens to be popular during their lives, er, uh I mean take an eclectic approach to…. falling flat on their faces.

2. Shipped lots of successful projects. Never had to pull features.Why? Initial project planning was good enough. Any cutting the pattern to fit the cloth happened early in the planning.Current project is partly an exception: All the work that is uniquely mine has gone just as planned, fast, fun, easy, nice project design to begin with, no features pulled, code, in 100,000 lines of typing, apparently ready for serious production — never did a prototype version; didn’t try to do a minimum viable product.But some external events beyond my control and not in my planning got in the way, so far, big time. Bummer. I’m digging my way out, indeed was just up all night and made some good progress, now have some data backup, actually installed operating system, running. To get past the nonsense is just routine, often mud wrestling with lots of nonsense, but still routine. Pulling features would not make this digging out any faster.How to avoid this last 10% rush, pulling features? Good initial problem selection, good initial technical work on the crucial core technology, if have some of that, good project planning — the key is to pick and plan projects that are appropriately clean, simple, and, when the initial chancy stuff came out well, nicely routine.E.g., my Web site has only two main Web pages. That’s all I need. The code for the pages is simple — just simple HTML and CSS with layout based on tables. The pages don’t much need JavaScript; I haven’t written any JavaScript, but some of Microsoft’s code writes a little for me. The page design and the user interface are dirt simple. The pages have large fonts and high contrast.The financial potential of the project just doesn’t need complicated Web pages. So, for the Web pages, it’s use the KISS technique — keep it simple, stupid. If the project looked like it was to need complicated Web pages, then I might have picked a different project.The first time I saved FedEx took me six weeks of typing in code while I taught two sections of computer science at Georgetown U. The work was reasonably small and quite clean because I got to design it. Also because I got to design the project, the results were powerful enough to save FedEx. Early on, talking with others, there were possibilities to spend weeks or months, now I can also see years, on basically the same problem FedEx needed solved. Yup, the much longer projects would have been better in some possibly valuable ways, but the goal was just to save FedEx, and my little approach did that.So, broadly, try to stay away from big, messy projects with poor focus on what needs to be done and too many knobs, dials, options, features, etc. Or, again, KISS.

3. Ain’t that a truth that never really changes.

4. This resonates with me so much.We say it is like an iron triangle. For people not from the country it is these Tavern puzzles: https://www.google.com/sear… They have them everywhere.So you have three sides: quality, time, number of features.We cannot shave quality. The other two you can move around.

   1. The alternative to this is I’ve heard is “fast (time), cheap, and good (quality)” — so in place of “number of features” the version I’m more familiar with assumes a fixed scope and adds the variable of money.My experience is that almost invariably it’s quality that, when “the final push” is reached, that clients, product management, execs, are willing to throw overboard.Somewhat related rant: I think as I’ve mentioned before here, the whole “f*ck it ship it” mentality that has become so prevalent, especially in the NYC tech community from I’ve see in the last 10 years or so, just has to go. I kinda, sorta, get it with a CI/CD SFDC for a truly trivial consumer product. But this approach has crept into enterprise grade development too — edtech in particular is where I’ve seen it, though a bit in fintech too — and it’s just a comically stupid idea to 1) approach your paying customers as alpha testers and 2) think it’s ok to push out new version of software, especially untested, just whenever you please regardless of considerations such as a school or fiscal calendar around which your customers’ business is run.

      1. See my comment below. First timers think they can shave quality. There is a term for that “technical debt”.Now technical debt is very expensive. It’s very expensive to go back and fix things.But here is the huge cost:When something goes wrong your users and much, much worse your employees will assume it is because you suck.I cannot express this strongly enough.If you hit a tough customer like LE 🙂 he gets the joke.Or worse.Your employees will just cower and apologize and their morale will suck and the customer will beat them down.

         1. I wish you’d come up to NYC and talk to some dev and management teams up here. I wish this would all sink in.As an side, this (“f*ck it, ship ip”) is one of the 3 things I think are issues in what is otherwise an incredible community here in NYC. Those 3 things are, incidentally:- Ageism … no one much over 23 could ever know how to code- (Somewhat related to that first one): Technology trend chasing … did you know that GraphQL, zero-knowledge proofs, and Kubernetes are now all hopelessly obsolete?- “F*ck it, ship it”

            1. I’ll talk anytime any place. Under two hours door to door anywhere in NYC.I have knowledge because I have experience. I have experience because I didn’t have knowledge.Mix of people is great.

            2. I’d say no one under 23 knows how to code.And that is not me being a cranky old man.If they think they can code it is because they don’t know what they don’t know. Ignorance is bliss until it kicks you in the ass.That is not saying I don’t think young people are great 1/3 of my programmers are under 30. BUT. It is like being a craftswoman, if you don’t think you learn from the masters, you are stupid.

            3. See my story to Matt. It is totally true.

   2. I’ve been working on trying to integrate more modern software practices at my work place. One of the things I started to try to do is build a business case for doing automated testing of software. After doing a ton of research I figured out the business justification is usually with automated testing you can do less human testing (or do it faster). So you save time/money on manual testing and can hire less manual testers. I then realized the reason making the case for automated testing was so challenging was we did not have any software testing beyond what the shipping developer might do.Anyways it turns out software quality is expensive and the business owners would like you to ship quality software for the same price as not quality software. With all the features. I bet you can guess which dimension ends up getting moved when quality and features win.

      1. If you don’t have testing……then you aren’t a company. As important as coding. Sure, they use automation. Just as important as programming, but more important they are just ask skilled as programming and bridge the gap with support, which is also just as important.

         1. Phil I think the thing you fail to understand is that we shouldn’t have to be spending money testing software because you shouldn’t be writing bugs into it in the first place. And we shouldn’t have to buy support because you should document everything about the software before you hand it over to us. We paid you for documentation and didn’t get it and you put the bugs in there and now we expect you to give us support and bug fixes for free.(Some of that is actual quotes. Not my personal position, but it has been heard…)

            1. This ^^ is my life.

            2. I could tell jokes about that but none are appropriate for this blog.

            3. we shouldn’t have to be spending money testing software because you shouldn’t be writing bugs into it in the first placeThis relates to what Fred said here:but there are always clean up items to be dealt with after the fact.Would like you to know (I think you are quite a bit younger than I am) that it wasn’t always like this. Back when there wasn’t a way to clean up the mess things absolutely did work better and had less issues. Because vendors had no simple way to fix things without major expense. Now it has shifted to what I noticed the sort time that I worked for a Silicon Valley company in the early 90’s. I said ‘oh I get it our customers are our beta testers’. And no it’s not just because things are more complicated today that is not the primary driver of this.Also if you want to know at the core why it’s like this it’s simple. First you can blame Microsoft and Bill Gates and the PC Clones. Everyone just trying to push out product without any regard to the user getting aggravated by things not working. Didn’t matter to them at all. Your problems are not their problems fuck you and to bad. Two, as I say ‘you can only be has honest as the competition’. So if your competitors were shipping buggy products at certain prices you sort of had to do the same. So it’s the collective group. Third computer users as a group are totally BOGU (bend over and grease up). They just will take so much abuse and think it’s them and not blame the company. This is kind of a ‘revenge of the nerds’ type thing. Fourth move away from actually accountability in companies (no receptionists phone trees all sorts of friction to complain in any meaningful way about issues). So the top management is isolated from the pain and suffering so it’s easy for them to say ‘ship the product and fix later’. Media won’t run stories unless they rise to a certain level of juicyness. Some feature being buggy doesn’t make the grade.This is not meant in any way as disrespect of Fred however let’s say hypothetically any buggy product that was shipped someone rang Fred’s phone and he had to get aggravated. He would probably work real hard to make sure the software shipped right if he could and not ‘fix later’. But not if someone else is getting the calls. This is what happens in small business everyday. You do something shitty and you immediately have to deal with the consequences. There is no hiding at all.Note that when CEO’s have an issue that they can’t dive they immediately cave to the pressure (example social media) out of fear.I recently was working with an attorney (you are an attorney, right?) and was amazed at how many mistakes he made in a contract. (He was the attorney for someone I was buying something from). It was like mistake after mistake I had to send back to him fix. Had to be a dozen times. At first I just figured he was a shitty attorney (and I still think that). Then it came to me what was going on. He normally deals with other attorneys. As such those other attorneys get to bill for each time they go back and forth. So it pays for them almost to be sloppy because the client doesn’t know they just see ‘contract revision’ and they pay for it. They don’t know it was for something sloppy or something real. How does that sound? Like that theory? I know there are other cases where someone tries to slip something in that I come in contact with but not in this case.

            4. You are mixing metaphors.Yes, the tech industry because people want stuff so cheap and so many features TODAY! has evolved to you are the beta tester. Remember the PS/2 and OS/2??? No kids that was not a game station. Failed. People wanted Gateway and DOS. Does anybody remember their logo? I’ll give a hint it was bovine.Lawyers get paid by the hour. Full employment which is taught at law schools explains the behavior.

            5. What I have heard is developers should be good enough not to write in bugs.Well this is moronic. I tell people what is it like to have no clue? First and foremost they are writing on top of so many other things that are constantly shifting. The processor kernel software, operating system, data base, languages, routers, switches, and most importantly their fellow developers code.None of that is static. None of that is like a 2×4 which never changes.Then you have interpretation. What many people call a bug is not a bug. For instance on a page you can’t hit the browser back button and it tells you that when you do it. BUG!!!! Nope working exactly as designed.Then mis-interpreting features etcThe support thing makes me laugh so hard. You don’t need support??? No your documentation should be so good.Ok so you are the only one that is going to be using…….well no actually I won’t be using, Susie, Jane, and Bob are going to actually do the work.

            6. I just wish I could have a dollar every time a client (or even co-workers) would claim that me not interpreting their vague language the same way they did was a “bug”.

            7. Matt I’m not sure (or need to know) when you were born, but this has been around forever. I don’t develop I just manage the business, not even the development.It drives you batty. The vague language I could deal with. It is the absolutely poorly/non thought out requests that drive me nuts.I want X!! But if we do X that breaks A,B, and C. Just give me X!!!I’ll end with a story from long ago:We had a client. They announced a promotion for Saturday and decided to get around to implementing on Thursday. Well of course they just made it up without looking at the product. It was a crazy promotion. Your software has a bug!!! It won’t do our crazy promotion!Sorry, too bad. Well my business partner stayed up literally night and day to do their promotion. It broke. He fixed it that day.Then I got the call from the C level execs. You are incompetent. We are going to fire you. I want to make sure that you fire the business partner. Top of lungs, loud incessant.Finally in exasperation I said look what do you want me to do? Tattoo “BAD CODER” on his forehead. Pause…..well… Guys that was a joke!!!They are still a customer, I still work with the business partner, and the joke at the office still is when you screw up: Phil is going to tattoo bad coder on your forehead.

      2. Yes, software quality is expensive, approximately 2X more expensive than going without it.Some people think QA and testing can be magically created or automated and often oversimplify the process, resulting in partial coverage. Effective software quality assurance is a parallel project that goes hand in hand with the software product project both iterating and cross feeding.The problem is that, in a startup, the same team that writes the product code often has to write the testing code and manage both processes.I agree with you on that under pressure the most likely to go or deteriorate is quality. • Write good product code. • Write good testing code with good coverage. • Don’t ship junk (Steve Jobs)

         1. Yes, yes, yes!!!! Every single point spot on.

         2. Or: Over the decades, enough multi-ten million dollar software development projects have flopped that by now there is a LOT of thinking, writing, etc. on software design, etc.E.g., can drown in terminology and acronyms at, say,https://en.wikipedia.org/wi…When I was in IBM’s Watson lab doing AI, etc., our group was also big on shipping products. So, I saw some of the IBM software design methodology. Since we were in Research, we got to shortcut some of the explicit steps. So, IIRC, roughly, just from memory, there were about seven steps with a big stack of documentation for each step. The steps covered requirements, program specifications, components, modules, etc.The process was too clumsy; too often by the time the documentation was done, the market opportunity had changed too much! So, that design process had trouble keeping up with the changes in the market. But, as at the Wikipedia page, there is no shortage of more methodology, terminology, and acronyms.To me, the basic points are simple:(A) People on the project need to understand the project. The basics of this understanding should be written down.(B) Strictly, the code itself doesn’t mean anything. For meaning, that, as usual, is in a natural language, e.g., English. So, that meaning can be in comments in the code, external notes referenced in the code, …, to whatever other design documentation there is.(C) Top to bottom, use the divide and conquer method. So, split the work along some natural lines into relatively independent pieces. These “pieces” can be at nearly any scale from a subroutine of less than 50 programming language statements to a main program, e.g., EXE file, to … a 2 million square foot server farm in Virginia, another in Munich, another in Singapore, another in Denver, etc. Have each such piece be relatively small with a relatively simple purpose easily documented and understood.E.g., the programming for my startup is 100,000 lines of typing with 24,000 programming language statements. So, only about 1/4th of the lines of typing have code, and the rest have comments. A lot of the comments are tree names of files on my development computer, and a simple editor macro I have will with one keystroke display the file — mostly the files are HTML files I downloaded (indexed, abstracted) from Microsoft’s MSDN library: So, for some use of some object or method in, e.g., ASP.NET, one keystroke gives me the fine details. Right, Microsoft has Visual Studio with Intellisense with some similar or better functionality. But did I mention I like the KISS principle — keep it simple, stupid. My little editor macro is short and just dirt simple. If anything breaks, then I can fix it right away. But some of the files have notes of various kinds up to the TeX documentation of the original applied math I derived. So, in the source code itself, 3/4ths of the lines of typing are for documentation with a lot of those lines files with much more documentation.Why the documentation? Without it, my code is not much of a long term asset for my startup. Or, without good documentationWhen the program is first written, only the programmer and God understand it. Six months later, only God.Then, for the code and getting the bugs out, when start with the code, the main program might be just some version ofInitializationSet up exceptional condition handling.Read inputs.Do the work.Write the outputs.Then for a single function or subroutine, the guy writing it has a clean, solid, precise specification of just what the heck will be the inputs, what the work is to be, and what the outputs are to be.Yup, there will be “corner cases”, that is, rare situations. E.g., if a program is to sort an array of length n, then the code should still work when n = 0, do a good job handling the case of n < 0, and do the right things, not get tricked, when the length of the array is at or close to the maximum for the data type of n, the programming language, the operating system, the hardware, etc. E.g., ifn*(n-1)/2might give a fixed overflow, then don’t do that.Uh, on things not to do, apparently the statementi = ++j+++++k++is legal in the C programming language. Some testing I did once showed that not all C compilers do the same thing with this statement. For super arrogantly absurd, counterproductive, shooting self in the gut, destructive, “ego driven”, seditious programming, don’t do that!If there is a good reason for some tricky code, then DOCUMENT it. Else, DON’T do it.All the cases in the input need to be considered explicitly in the code and the documentation. The situation is something like cases in a proof in math.The programmer should try to find exceptional cases that would cause trouble and handle those and DOCUMENT the problems and solutions.Hopefully the situation is simple enough that a lot of this checking can be done by just “desk checking” without running code or test cases. For many software bugs, desk checking can be much more powerful than testing the running code.Then maybe put some bucks on the table. The bucks go to the programmers except for bugs found by quality assurance and testing!Making this work needs the KISS principle of engineering — Keep it Simple, Stupid.For what is “simple”, usually there can be quite different approaches. But the main goal of simple is just having code easy to write, understand, test, and revise. So, if one approach to simple is a little better than another, fine, but the biggie point is that any good approach to simple stands to be much better than the alternatives.Being successful with KISS is often NOT in itself “simple” and, instead, MORE work!Then what holds at the level of a subroutine of less than 50 programming language statements, which might have 500 lines of comments at the beginning and 200 lines of comments in the code, is to be carried up to the higher level “pieces”. E.g., at one point my code uses the heap data structure from heap sort and implements an “object sort” with polymorphism via interfaces. Okay. That code has been more useful than I first guessed. But the code starts with documentation of the heap data structure, right in the code, the main discussion at the top of the source code and the rest with in-line comments. The importance of documentation continues all the way to the top of the design, architecture, and business asset.Does this divide and conquer and KISS methodology always work? Nope. But we TRY to make it work, to have the components, the divisions, …, everything so simple that it can work. If we write some big software and don’t try to make this work, then we might spend decades getting the bugs out and end up with a mountain of spaghetti code big enough to sink a major corporation, e.g., if only from security problems.

            1. I am not a fan of heavy methodologies. Back then I invested precious time learning the last methodology introduced by the last big consultant firm into the organizations I worked for, usually banks. Documentation was comprehensive and heavy but the truth is that the binder would end up locked somewhere and nobody really would read it. It was for compliance.I agree KISS helps. Also a good initial design. I don’t care if I have to rewrite a module or two which once implemented I don’t like. Sometimes the interfaces end up being ugly. I like to benchmark and iterate a bit, feel how it works, then retouch, adjust. Should look nice and clean at the end. “It has to work” is the most important feature or requirement :)Want to have fun with the latest compilers? Take a look at compiler explorer: https://godbolt.org . Compilers are better now, particularly at error reporting.I tested that horrible statement in C in compiler explorer, doesn’t compile with defaults in gcc.Another thing: I was playing with an Aho-Corasick string search implementation the other day and thought about you. Are you using it? or something similar?

            2. I’d guess if are working on the code for a bank, then are likely mostly stuck (or in a Groucho Marx movie, “stuck-o”) with what they have, however big the pile of spaghetti.I omitted, there’s a big advantage in doing a startup: If KISS is hopeless and there’s no hope of clean partitioning of functionality and code via divide and conquer, then pick another project or at least for the given project, before have written much code, in a quiet room lean back with a two quart jug of well iced soda pop, with caffeine and maybe sugar, a soft, sharp pencil, a big, soft eraser, and a big pad of empty paper and think again!!! Avoid sore fingers from too much angry typing, pulling hair, lost stomach lining, weight gained from too little exercise, ground teeth (once I cracked two molars from teeth grinding from a case of “DLL hell”). With a bad initial architecture and design, the fingers, hair, lining, …, lost will be yours!So, sure, in Ci = ++j;saysj = j + 1;i = j;andi = j++;saysi = j;j = j + 1;Soi = ++j++should sayj = j + 1;i = j;j = j + 1;then for the monsteri = ++j+++++k++that can look better withi = (++j++) + (++k++)When I was at IBM, I ran this monster through two C compilers. IIRC both compilers tried to compile the thing, but with just simple numerical values gave different results.If gcc has gotten rid of such nonsense, terrific. Supposedly the nonsense was stimulated by an early DEC computer that had a single instruction to increment by 1. So, the nonsense permitted saving a few cycles. Since Incrementing by 1 is very common in loops, maybe it was a good machine instruction to have, but promoting that instruction to C syntax and semantics was, uh, with a few decades of hindsight, pipelined processors, and cache memories, part of the C “idiosyncratic syntax” and not a good idea.There used to be essays on “ego-less” programming to argue against the practice of writing tricky code and omitting documentation to cause other people trying to read the code to strain to see what the function and intent of the code was. Since that nonsense is from humans and not really computers, I have to guess that we will continue to need essays on ego-less programming.

5. Far better to pull features vs cutting time for testing.

   1. Yes, yes, yes, if you are doing something that thousands of people will touch, a feature pull is much better than a broken feature.

6. The Final Rush.

   1. If you ship 6-8 times a year like we do 50 times in the last 7 years, you don’t want a final rush every time. Sometimes ok.

7. When I was a product mgr a long time back, every mrd and business contract would require the product mgr to rank-order 3 things – (1) Cost (2) Features and (3) Schedule.This might be different for some other category, but I cannot remember a case when Cost target was not #1. That would leave it between features and schedule. We’d try to be flexible between these 2 attributes…depending on how the market environment was shaping up in the time since the business contract was signed off. There was not a hard rule favoring one over the other.

   1. Of course the trite saying that you see in every store where I live is you can have it fast, cheap, good. Pick two.

8. A favorite among product managers:https://media.giphy.com/med…

9. I find that the last 10% is so much harder than the first 90% of any project.I think this also relates to the concept of work filling up to the time available for completion. So if you have X weeks to get something done there would be a natural tendency to not work as intensely during the initial phase ‘we have plenty of time’ and then the end phase the 10% left over is more intense and therefore feels much harder by contrast. That in itself though is not all that bad because that pressure actually adds a great deal to efficiency. Besides if you have X weeks to complete and you work intensely in the begging (and get 80% done in .4*X weeks) then it would be human nature to slow down and not take things as seriously.

10. We spent the last week getting a project we’ve been working on for two years over the finish line.I have found that the following ‘manipulation’ tends to work well at least with service personnel or contractors. What you do is try and turn an arbitrary date into an absolute date by which they know there is no missing that date period.So for example lets’ say you are renovating your shore home. What would work better with contractors ‘a’ or ‘b’?a) We want the house ready for Memorial Day so we can enjoy it please make sure that happens.b) Our daughter is getting married on Memorial Day and we need it donewell before that completely because there are other things that we need to dofor the wedding. So it has to be done Memorial Day – X.Now of course ‘b’ can be anything and in the above case it’s totally made up. However I use it to illustrate a point about how people will react differently to deadlines and prioritize. The contractor will absolutely (unless they are nuts) recognize that if the work is not done by the date of the wedding (even earlier) they are up shits creek because you are. And they will convey that to their workers. And at least from my experience they will work really hard to make sure the job is done. Is it wrong to do this? It’s up to you to decide. You have to fight fire with fire. And unfortunately being honest will often leave you in a lurch. Sure you can try to build things into a contract as well (but certain people there is not going to be a contract and you can’t do that…)I can tell you that in the printing business if we had something with what I would call a ‘hard deadline’ that it was absolutely prioritized above everything else. And not only that, the employees, the people who did the work, also understood that deadline and worked and always made it happen. (Examples might be materials for trade show either that have to get mailed or given out can’t miss those deadlines or, say, wedding place cards you get the picture).Look truth is people do act differently with hard deadlines. Ever take a cruise? Anyone who does that knows it’s a good idea to fly in the day before and stay overnight not the morning of the cruise. Because if you miss the boat you then have to get to the next port. Nobody wants to do that. So you prioritize it so much you think it makes sense to arrive the day before.

    1. Or you give a mother loving bonus and penalty. Note Delaware 301 Bypass. Contractor is going to make a $40mm bonus on a $100mm job.

       1. Well for sure but it depends on the situation in the following way.If you are dealing with people it’s very likely that the extra money or bonus will not work (as opposed to a large scale contractor). Why? Because that way they can quantify the loss and in a sense justify it in their mind. In the case of my example you are dealing with human emotion. And that is really the key to it (once again depending on the situation). Human emotion will work with people. But not with a corporation (unless there is a person and that person has full control and can pull something off).Unrelated but relevant example: Parking ticket vs. Paying for parking. A parking ticket causes a great deal more emotion than paying for parking does. I remember my ex wife, when she worked in the city, doing sales and she always got tickets. It really pissed me off. Until one day she said ‘the tickets are actually less than paying for parking and it makes sense because to avoid tickets I’d have to always pay for parking’. That made sense. It took the emotion out of it. Hence ‘cost of doing business’ vs. ‘you fucked up’.So let’s say you give a person a bonus (or even that they will lose money if they don’t complete your deck on time). You say $10,000 if you get it done on time or only $8000 if you get it done late. (So $2000 is the bonus). They can then quantify the loss and in a sense justify it. Otoh if you say ‘deck needed for wedding’ that is an entirely different story. That is going to create in many people an emotional need to avoid some kind of negative that they let someone down or that someone will ‘suffer’. So that is much harder to avoid.Now in the case of the 301 Bypass the dollar amounts are such and the contract gives you the ability to give that amount of money. So sure that is way way different. However most people are not in that type of situation and with numbers that hurt like that.Another related example. Why at places like Wawa or on the turnpike do they not tell you how many plastic spoons you can take or ketchup? Because (my theory) that if they said ‘you can take up to 10’ then people would feel justified in taking 10 even if they only needed 2. They’d think ‘oh ok it’s fine if I do that’. Ooth if they don’t give limits some people will abuse but most others will not. I go to the bank. There are no limits on how many lollypops you can take. So I literally stand there and take a great deal for the kids. With no guilt. [1] Guarantee nobody else is doing that. If they said ‘take up to 10’ what would happen? I’d still take more than 10 (I am a pig) but others would take 10. That is the theory anyway. I have no studies. However having manipulated situations for so long I can easily say what works and what does not with enough certainty for me.[1] Because like an idiot I don’t have time to transfer the large balances to a place where I actually get interest and they always hit me with fees randomly etc. So sure I will literally take lollipops. Used to grab Keurig back when I drank that. Not one but, say 5 or 6. Nobody ever said anything. And I didn’t care at all if they thought I was not doing the right thing either. It’s a bank not a person.

11. This reality presents itself most starkly in the yin and the yang of the orgranization, engineering and sales.

12. the final push definitely eluded me in 2008! In the moment it feels like you have all the time in the world to launch, even when feeling rushed and impatient day to day. What a paradox!

13. Warning: Fred’s comments do not apply to ones personal relationship and love’s heartbeat. Perfection is always the goal.

    1. True

14. I heard this quote some time ago…Best way to manage risk is to raise it!I think Elon Musk is using this approach at Tesla – enacts a 9% company-wide headcount reduction while focusing on meeting Model 3 production commitments of 5K per month. I’m sure Tesla would love to have more time but the risk of being unprofitable and losing customer confidence often alters your mindset. I see quite a good number of companies follow the MAYA Approach – Most Advanced, Yet Acceptable, to lead GTM decisions.

15. ” I find that the last 10% is so much harder than the first 90% of any project.”So true . So true.Sticking to the release date wins most of the customers satisfaction than the actual product. (sounds not right, but true).KasiP.S.BUT remember not to repeat a “miniScribe” of “shipping bricks” to meet the numbers!!!thanks to “Charlie Crystal” the wise man from Lancester who gave me this advice a decade ago.

16. Reading Seth Godin on “shipping” (here: https://99u.adobe.com/artic…, and in many places) was transformational for every project I do that involves getting things outside of my own head. It also made me realize that my heroes were just as unsatisfied with their own work as I was with mine – but they still shipped!

17. “Perfection is not just the enemy of the good, it is the enemy of the ship date.”Ad agencies are absolutely required to produce the best work on an exact date every time. They need to or die. There is a LOT a software company can learn from the ad business.

18. No. We are just not confident enough in some of the data we are working with so we are trying to get more

19. Thanks for the update @fredwilson:disqus.