Why Development Teams Struggle to Deliver on Time, on Budget, or at All - <AUTHOR> https://www.7pace.com/blog/software-development-planning-fallacy <comment><USER3> The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work).

To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of times. I know all the different things that can go wrong and account for them, because I've encountered them before. The elderly person who wants to pay cash and has a bag full of coins. The guy who finds a 10 cent discrepancy on his €92,30 receipt and has to argue for 5 minutes with the cashier (while the row behind him keeps growing). etc. etc.

Now imagine that today is your first time going to a supermarket. In fact, before today you had never heard of the concept of supermarkets, or milk for that matter. How good will your estimate be ?

The only time you can make a decent estimate is after you've finished. Or to put it differently: making an accurate estimate is possible, if you're going to accept that making the estimate is going to take a long time, but I can't tell you how long.

Development time estimation, and every methodology that attempts it (I'm looking at you, Scrum), are little more than desperate attempts by managers to feel in control and relevant.

<comment><USER4> _The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you 're always doing something you've never done before (because if you did you could just copy-paste your previous work)._

If you can plan and execute putting a person on the moon, you can plan and execute software development.

I think the problem is the overwhelming majority of software development is so low stakes, easy to replace, assumed that bugs are par for the course, etc... that most orgs have stopped putting real effort into planning AND executing on that planning, instead just cargo culting the planning phase.

<comment><USER5> You've missed the point. Nobody can (or did) accurately estimate how long the planning and development would take to get someone on the moon. Half the materials weren't even invented yet in 1962. Nobody knew that Velcro was flammable in pure oxygen.

Sure once all that expensive and unknowable planning and development is done, you can double-click that executable and put a man on the moon.

</comment></comment></comment><comment><USER6> In my experience talking to hundreds of software engineering managers, running a software project management business, and being involved on software dev teams for 20+ years, there are two reasons why teams don't ship or ship poor software.

1\. Poor engineering planning. The way to do this well is to break down a feature until they're at about half-day sizes tasks. Identify any obvious risks or ambiguities with the technical approach and communicate them to Product and figure out how to de-risk them. Communicate costs to Product so PMs can make cost/benefit trade offs (eg "if we built it the way you specced it it'll take two weeks. But if you make these trade offs it'll take two days." As a Product Manager I might not want the feature if it costs two weeks but do if it costs less than 5 days. Without costing the features in dev days I can't makr this trade off).

2\. Failure to make trade offs that drive towards shipping software. The way you ship is by declaring it's done, even when it's not really done. When code is being written unexpected issues always arise. It's Product's job to make hard trade offs that drive towards shipping. Eg "that's an edge case bug, let's punt it to v2" Or "let's cut that nice to have feature and squash the showstopper bugs and ship".

People bring up impossible deadlines set by management. In my experience most deadlines are movable and a strong PM/Eng team can convince management to push a deadline back. And if a deadline can't be moved, it's all the more important to know how much features will cost and make hard trade offs to get the product out the door.

<comment><USER7> > The way to do this well is to break down a feature until they're at about > half-day sizes tasks.

I have never seen that work in practice.

<comment><USER8> Breaking a task down into meaningful half day task is almost as hard is just implementing it, but usually this is attempted in a committee setting. This is not a recipe for success.

<comment><USER9> Agreed. Think of how ridiculous it would be to make a half-day task for figuring out X -- sometimes I've spent days, even weeks, trying to figure out how a module works.

In practice, being able to break things down meaningfully and accurately to such a minute level implies that a _lot_ of time was spent in grooming, which means we're just back to waterfall again. (Or the tasks at hand really are just that simple and/or the people involved have a lot of expertise.)

</comment></comment></comment></comment><comment><USER10> Development time estimates are too short because there's no penalty for management underestimation. If programmers were paid like the movie industry, estimation would be more reliable. Time and a half after 8 hours, or after 5 days. Pay for 4 hours if you're needed briefly during off hours. Double time on Sundays. It's not just telling people it's a "crunch".

Movie scheduling and estimation is organized enough that you can buy a completion bond. If the job isn't completed within an error margin over cost and schedule, the completion bond company pays. If there's a cost overrun, the completion bond company has the authority to send in their own people to monitor things and if necessary, to _fire the director_ or anybody else, and take over the production.[1][2]

Completion bond companies do project cost and schedule estimation independently of the production. They have the data for this, because they have the full accounting data for hundreds or thousands of films. They watch project progress carefully. "Our monitoring process requires the production to email us daily shooting progress reports and a weekly cost report in order to properly evaluate the progress of the film. FFI also makes periodic visits to the shooting area."

This prevents directors and producers from low-balling their estimates. Underestimation leads to unemployment.

A completion bond typically costs about 4% of the film budget.

[1] [https://www.eqgroup.com/completion_bond/](https://www.eqgroup.com/completion_bond/) [2] [http://www.filmfinances.com/services/evaluation](http://www.filmfinances.com/services/evaluation)

</comment><comment><USER11> Do you really want to know why _some_ development teams struggle to deliver on time, budget or at all? Because the majority of software projects out there are utter useless crap, commissioned by people who have no idea what the heck they are doing and focus on the smallest stupidest details, before even getting a decent amount of users or even _wondering_ whether users would like those changes (before implementing them). People who, once the money runs out, will make the project crumble, frustrate developers who have to reimplement the same stupid piece of logic 20 times because "that button looks too big" or "this would be a really cool animation to have" while everything else goes to shit.

We get into software development because we expect it to be a creative, challenging and fun profession that creates value and yet most of us answer to clients or employers who expect us to spend 80-90% of our time working on boring, senseless stuff. You want us to do that? Great! But don't expect high quality and on time delivery.

The real reason behind delays is that we just don't give a crap about your "social network for cows" and we can't wait to save enough money to get the fuck out and either start a business, work for a decent company or start investing.

Apologies but it feels good to rant every once in a while.

</comment><comment><USER12> So the author of this has a vested interest in their "solution" being the correct one, but I fundamentally disagree with it.

I agree with their hypothesis that we are bad at planning/estimating, but the solution is not spending more time on it, but rather less.

Firstly I really like this humorous look at the problem: [https://www.quora.com/Why-are-software-development-task- esti...](https://www.quora.com/Why-are-software-development-task-estimations- regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe)

You cannot estimate what you don't know, and you don't know what you don't know and no amount of upfront planning will surface those. In their own example, you can't know upfront that there is a road closed or an accident or that only one cashier is working until you get to that point.

In my opinion the most reliable solution is to break the work down into small pieces that deliver value (ideally less than a week's work). Prioritise and then deliver the first piece. Have regular reviews/checkpoints with stakeholders to decide whether any value was delivered, are there new learnings that we need to apply to the rest of the project, or indeed new 'pieces' that we've discovered now need doing, what is the next piece we need to do and is it worth continuing.

<comment><USER13> > You cannot estimate what you don't know

Exactly! It tried to express that and a strategy for handling unknowns here - [https://medium.com/@hfuecks/what-donald-rumsfeld-can- teach-u...](https://medium.com/@hfuecks/what-donald-rumsfeld-can-teach-us- about-software-estimates-1be22864e509)

My theory is the reason why we're not getting any better at estimating software projects rests on a flawed assumption; because computers are binary and deterministic, we assume that the process of creating software must also be deterministic and quantifiable.

Example: when Apple opened the App Store to 3rd party developers, would it be realistic to expert an accurate estimate from one of those developers, building their first app? There were so many unknowns; how does the build / publish process work? what will pass the review process? what about all these new APIs?

<comment><USER14> Agile has a concept called the cone of uncertainty.

The way we use this concept in practice is by doing small chunks and delivering fast, and the more chunks we have done with a project/feature/whatever the more likely our estimates get better over time because there is less work left and we are more familiar with the work now.

[http://www.agilenutshell.com/cone_of_uncertainty](http://www.agilenutshell.com/cone_of_uncertainty)

<comment><USER15> Sometimes there are no "small chunks" and this is where all agile approaches fail.

If a thing does not work it is not a deliverable. Bonus points if the thing is not really testable because it is tied to platform/OS. (And you'd either have to implement it in full our spend weeks implementing a test harness.)

<comment><USER16> > _Sometimes there are no "small chunks" and this is where all agile > approaches fail._

I work at Pivotal. Cloud Foundry is a successful application of agile (XP + Lean trimmings) to a large, complex distributed system.

</comment></comment></comment></comment></comment><comment><USER17> In my experience, deadlines set by higher-ups long removed from (or never having) the technical chops to be determining the deadlines in the first place. VP's and Directors are often the ones dictating the direction, which is great, but then also introducing deadlines, with helpful input from Directors who ALSO haven't touched code in many years.

Generally that results in one of two things:

* Product delivered on-time with massive technical debt.

* Product delivered late with massive technical debt.

Frankly I don't know if adding front-line engineers to the deadline decisions is going to make the issue better or worse, but fundamentally having non- technical or formerly-technical people defining deadlines definitely doesn't work.

<comment><USER18> Having worked in the trenches as a software engineer and also as a CEO has given me respect for the VP level as well as the engineers. When the VP sets a deadline, it's driven by the survival of the company - aka release by June or we can't make our numbers and have to do layoffs. When the engineers push back, they often do so without an appreciation of the business reality, aka those numbers pay their salaries.

Engineers hate releasing poor quality products, but the reality is that customers often will buy and use something laden with defects rather than nothing at all. And in any case, after the initial botched release, you can always fix stuff. See Apple.

<comment><USER17> That's a fine argument for a bootstrapped startup with one product, but isn't meaningful when talking about the tech titans that suffer from the exact same problems.

This is the same type of argument that makes short-term profit take precedence over long-term success. Why in the world are we getting a deadline of 4 months? You, as an executive, had to know burn rate was blowing through cash a lot earlier than that.

Engineers hate releasing poor quality products because we know we'll eventually have to fix them and we will likely be given almost no leeway time- wise to fix the actual debt, as time will always favor ugly hacks that "work" over well-written code that prevents the problem in the future.

<comment><USER19> > _the tech titans that suffer from the exact same problems_

The tech titans aren't monoliths with a collective hive-mind. Each business unit and team is responsible for projecting revenue targets and then hitting them, same as any other kind of business. And, yes, if the business unit managers fail to hit their financial goals too many times, their project will be cut and the team reassigned or laid off, same as a startup running out of financial runway.

</comment></comment></comment></comment><comment><USER20> Having been involved professionally in software development for about 14 years now, I have to say I respectfully disagree. More planning does not result in better predictions. In fact, it often results in worse ones. That is just my empirical observation.

My best guess as to why, is that there are managers involved that attempt to negotiate the planned delivery time down. They do this, in part, because it's hard to get devs to work late or on the weekend when the project is on schedule, but easier to do when there is obvious risk of falling behind schedule. So, from their point of view, the best way to get the product delivered early is to get the schedule made too optimistically.

Not saying they SHOULD do this, or even that they are consciously thinking this way, but it's what the situation incentivizes them to do, and it's what normally happens. The gut level immediate answer is based on past experience, and the long drawn out meeting produced, System 2 answer, is based on management bargaining the developers down to a shorter timeline.

</comment><comment><USER21> I think software gets a bad wrap when it comes to budget and time overruns. I think we see a lot more software projects go over budget, over time, or fail mainly because they're more common than any other type of complex project.

You don't have to look far for a failed project of another type. While not necessarily a "project", 50% of all businesses completely fail within 5 years [1]. How many Kickstarters have you seen deliver on time? Even if you limit the criteria just to experienced people working in their field? One I've been following [2] is just a book that was supposedly already complete before it was funded was supposed to start in June 2017, and ship in Aug 2017. It's now June 2018 and it still hasn't shipped, that's 600% over time and counting.

I'm not claiming that's scientific proof software estimation isn't worse than anything else. But most of all project's estimation is done behind closed doors, so we'll never get a good feel for how bad/good things really are.

[1] [https://fitsmallbusiness.com/small-business- statistics/](https://fitsmallbusiness.com/small-business-statistics/) [2] [https://www.kickstarter.com/projects/pighixxx/abc-basic- conn...](https://www.kickstarter.com/projects/pighixxx/abc-basic-connections- the-essential-book-for-maker/description)

</comment><comment><USER22> The thought occurs to me that no matter how much planning you do or how good at estimating you are, the development is going to take however long it's going to take.

You can plan your trip to the store to buy milk and figure out exactly how long it will take, but the only thing that actually matters is that you arrive back home, with milk.

If that milk is absolutely necessary, whether it takes 30 minutes or ten minutes to get it is really a secondary concern. If you spend five minutes getting a better estimate you've delayed the milk by five minutes regardless of how long it takes or how right you were about the timing.

I think we spend too much time thinking about time estimation when the planning we should be doing is figuring out what is so important that the time it takes to build is worth it even if the time estimates are off.

<comment><USER23> > the development is going to take however long it's going to take

Hofstatder's law: It always takes longer than you expect, even after accounting for Hofstatder's law.

</comment></comment><comment><USER24> Higher up manager here. I fully accepted the #noestimates movement and it is a complete blessing for all the teams and organizations I've implemented it in. Roast me.

<comment><USER25> Did you do that in an agency as well? I mean it's one thing if you are developing a product, but telling your clients "the project is finished when it's finished and we won't be able to tell you how much it will cost you until it's finished" doesn't really fly in my experience.

<comment><USER26> Seems like charging a specific fee might help alleviate some of the concerns about that. Though I suppose you still need to know how much money you should charge.

I really hate estimates and have always hated estimating projects. I do appreciate the need/desire for them by some in management. I've tried to figure out how other people do it and have yet to find anything satisfactory. It doesn't have to be an extremely simple process, but I don't really know how one gets better at estimating. The only way to get better is to just understand the domain more clearly but estimating doesn't really help with that.

Kanban does have a cool idea of just attempting to break down work into equal parts and measuring the throughput of these roughly equally sized components. The only problem is actually sizing stories to be equally sized. Some changes don't have any kind of real stopping point of functionality without large changes. It seems kind of arbitrary to chunk it out just because your project management system wants you to.

</comment></comment></comment><comment><USER27> Another reason I'd like to add regarding why so many software projects fail is a really basic one, but is ultimately the reason why most software projects fail.

The budget isn't there.

For many, building software is a race to the bottom. I've worked at countless places, from "Wagile" places that run spiral methodologies mixed with agile, to fully agile agencies that deliver well but crumble the second a client gets pissy about something taking longer/costing more than it should.

In my view, the most basic problem in software is that we're committing to too much for too little, which is why I see development to be similar to working in a skilled trade. If you pay good money for a renderer, you'll get the outside of your house rendered nicely with good advice on what to use, what looks good. They'll also tell you how long it'll take, and if you say you want it sooner they'll tell you it'll either cost a lot more to get more manpower, or they'll decline the job. If you are cheap about it, you'll probably get someone that'll take longer than expected, will make a mess of the job, and you'll be left with something you're not entirely happy with.

A solid methodology will probably help with delivering software on time and on budget, but if you are unrealistic with either metric then it doesn't matter what methodology you use. You'll take liberties with it, decide that it's bullshit, and continue to cowboy your way towards a duct-taped mess of a solution.

It's something few want to talk about, probably because there isn't really a solution to it outside of:

* Paying a premium for a development team with a track record of recent success

* Having people that know the full software lifecycle be involved in all parts of the process

* Actually embracing the fact that when requirements change, to the point where budgets and timescales are flexible.

* Not joining the race to the bottom.

</comment><comment><USER28> There are ways to deliver on time & budget but most developers are not going to like it neither are their "clients".

Use the frameworks exactly as they are intended, don't try to invent new solutions that aren't native to the framework.

Anything that takes you outside the beaten path in development is going to be a potentially infinite black box.

In other words, a lot of software engineering can't be put in timeboxes because it's actually R&D more than it's development and where each little step forward can add a potentially infinite amount of new tasks to be done or problems to be solved. Add to that the constant need to update, upgrade, improve, re-design and you know it's just not doable.

So the primary problem IMO is that we think about a lot of development as if it's something that can be put in boxes. Some can of course and the better and more solid the team becomes to better they are but the teams who struggle are mostly struggling because the expectations for what they are actually doing (inventing problem-solving) isn't matching up with what they are being paid to do (build)

</comment><comment><USER29> Site is down, cached version: [http://webcache.googleusercontent.com/search?q=cache:https:/...](http://webcache.googleusercontent.com/search?q=cache:https://www.7pace.com/blog/software- development-planning-fallacy&num=1&strip=1&vwsrc=0)

<comment><USER30> Next article: Why web servers struggle to deliver before timeout or at all.

</comment></comment><comment> UK-Al05 Having been through multiple month long planning "phases", that were eventually shown to be wildly inaccurate I disagree.

This is exactly what we used to do in the waterfall days. It didn't work.

The only way that's been compatible with me is to build something really small but valuable. So small that its hard to be disastrously wrong. Once you've released that value, build upon it.

Stakeholders tend be much happier as they at least have something they can use really early on.

<comment><USER31> This for the win! Always be wary when they ask for single sign on in the first sprint!

</comment></comment><comment><USER32> Software is design, not construction. This is why it's hard to estimate.

You ask an architect to design a _new_ skyscraper in a fixed three-month timeframe, good luck. It won't be what you want, or it'll have severe problems discovered during construction.

Software developers are creative workers, we have to accept this. Unless you're doing the nth iteration of basic CRUD/RESTful web app, or a trivial "display data from a database" app (note: the DB design may take more time, some of the controls on interaction will take more time, but the core of it will be the same) you can't reasonably estimate your time.

Once you know Ruby on Rails, making a prototype of a webapp is a rote task. You can knock it out in a known (from experience) time. Then you try to improve it, add new features, customize the backend (first time you've written a DB connector), things start going off schedule.

The only other way to have reasonable estimates of the _development_ , is to spend a ton of time upfront (unestimable) designing the system before we touch the code. Ok, now the coding tasks are well understood, but you also just spent 2 years designing it. And, like the architect, if you rush this design part, problems will crop up during coding that will blow your schedule.

<comment><USER33> Architects regularly design new skyscrapers on fixed schedules. Look at some of the major developments going up in China.

<comment><USER32> How many of those fixed schedule projects are based on old and proven designs? I specifically emphasized _new_ in that sentence. Perhaps I should have said to produce _novel_ designs. Which is what many programmers are asked to do and estimate.

</comment></comment></comment><comment><USER34> Upon reading the first couple of paragraphs I decided to test it on myself. I had to buy X, which is available in convenience stores (comvini, Japan). I estimated it'd take 5-7 minutes, but I was very surprised when it actually took 4 minutes! To be fair, this has to do a lot more with Japan than with myself. The same test in my home country (Spain) I would have had to guess 15+-5 min during day time. Sidenote: I was very surprised about the concept of "driving for milk", which I'm assuming is a very American thing.

I'm fairly realistic about software estimation which only came after a LOT of retrospection. It normally takes what I estimate, both personally and professionally. The hardest factor I've learned to include is the level of detail. For instance with my personal website [1] I gave myself a full Saturday because I knew I wanted high detail level but I had in mind the overall design. It took the Saturday +1h of a couple of improvements/bugfixes (under 10% error). With my current job I'm also under 10% error.

In the past I have been bitten a LOT about my unrealistic estimations, so the only solution I had to move forward was to learn from those and so I did. So now, from the article, I know that _my_ "quick thinking" is around 50% of the project. I force myself to think a bit more and the details trickle down.

Another thing I've learned is that projects tend to fill as much time as possible (Parkinson's law [2]). So if you are told a deadline, half it! Put the half as your internal deadline, then the project will be just on time.

Finally, complexities are exponential, so learn to say no to unnecessary cruft. "A small change" might seem like a 1% change for business and for you initially, but it will more likely than not grow into a 10-20% change in the end. FFS that is why _the duck_ was added in the first place, to avoid wasting time [3].

[1] [https://francisco.io](https://francisco.io)

[2] [https://en.wikipedia.org/wiki/Parkinson%27s_law](https://en.wikipedia.org/wiki/Parkinson%27s_law)

[3] [https://rachelbythebay.com/w/2013/06/05/duck/](https://rachelbythebay.com/w/2013/06/05/duck/)

</comment><comment><USER35> This is literally what agile is for. Step 1 (and this is the hardest part) is to negotiate the need for either a flexible scope or deadline. Accept that you're estimate for a fixed scope will just never be accurate and just make room to adjust. Putting "buffer" into your estimate is also not the right approach because it's planning for failure. Flexible scope means you have work to fill up what would go into your buffer that you can launch without if you need to, but would be very nice to have.

Create your high-level backlog and do MoSCoW prioritization. Figure out your "musts", "shoulds", "coulds", "wonts". Now apply some estimates to your features and add 10% for unforeseen growth. Estimate velocity based on team size and now you've got a date when you could conceivably hit your musts, shoulds, coulds. Set your "deadline" if you must somewhere deep in the coulds. If your musts go over, you are still able to launch an MVP. If things go well, you can start delivering non-musts.

Adjust your plan every sprint based on actual velocity.

</comment><comment><USER36> I hate it when PMs ask me for an estimate of effort on a task I have never done before and I get this question all the time. I get asked to get a new process through a deployment system I've never worked with before and that's fine. How long will it take? That depends on how complex the deployment system is and I haven't worked with it yet.

</comment><comment><USER37> There's a lot of snake oil for sale if you are looking to spend money on solving this problem; this probably is more of that.

The reality is that mostly we've gotten better at avoiding things that clearly don't work or are historically obviously misguided/inappropriately expensive (waterfall, CMM level 5, etc); and instead emphasizing things that don't work slightly better: managing risk by doing iterations, not attempting to plan the unplannable eventualities too far ahead of time, etc.

Some people refer to this as Agile. Other people as common sense. Either way, not wasting time on things that clearly don't add value tends to free people up to do something productive (duh). There's a pattern with agile with mostly non technical people higher up the management chain getting overly excited about things like estimates, velocity, burn charts, etc. I usually call stuff like that the illusion of progress and waterfall in disguise. Scrum particularly seems to have devolved to decorating offices with post its and employing busy looking people with moving those around and manually tracking them in convoluted tools like Jira.

But undeniably, we've gotten better over the past decades at building stuff with huge groups of people. Any idiot can probably gobble together some lines of code that does something vaguely useful. But committing to building stuff with hundreds or thousands of people is a different game. It requires lots of money and focus and there are quite a few companies that are doing this successfully.

A bigger pattern in our industry is that people seem to have shifted to calendar driven roadmaps for the most important bits of software where they ship whatever is ready on a fixed dates instead of committing to a long list of stuff shipping whenever it is ready. E.g. Apple ships OS versions once a year, Mozilla, Linux, Chrome, etc. ship every few months, typically with massive amounts of code changes.

<comment><USER33> CMM level 5 does work, if you actually do it instead of just treating it as a paperwork exercise to satisfy an auditor. There's nothing in CMM that's contrary to or incompatible with Scrum or other agile methodologies. The major emphasis in CMM is on documenting your process (whatever that process is), training people properly, and continuously improving.

<comment><USER37> Yeah it works. It's just not very appropriate in a lot of situations because it is insanely expensive because it adds a lot of non functional bureaucracy and time consuming activities to the critical path of delivering software.

</comment></comment></comment><comment><USER38> I really wish people would put more effort into making sure people don't waste time instead of endlessly trying to make development more predictable. In my company there are a ton of inefficient processes and other things limiting productivity (noise, teams spread out over entire building, developers having to do work that would better be done by qualified tech writers, lack of adequate onboarding, lack of decision making constant changes). Instead of addressing theae management keeps on doing status meetings and planning.

I think they would be much better off if they made sure that their people have optimal productivity and then see how quickly things can be done. I guess that is exactly what scrum originally tried to address...

</comment><comment><USER39> When I first started working as a web developer, my boss would ask me how long it would take to finish a project. I would give him an estimate time, and he would always double it. As it turns out he was always right. But because of it, I learned to provide better time estimates. Overtime I became more accurate and started to provide more realistic time frames. Depending where you work or who you work with there's a lot more that goes into your day to day tasks than just coding.

</comment><comment><USER40> The fact that there are so many reasons for the failure itself tell why the failures are so frequent. I strongly believe that it should be more than just the development teams which should be attributed for failures. Projects rarely get delayed or fail cause of developers only, the more responsible parties are management and the company culture. Even the strongest of the developers would learn over period of time that sticking to a more realistic schedule would not earn them praises. Unfortunately the path to promotion is to keep the bosses happy in most places. Most people do not have motivation about the end results, its more about looking good on day to day basis. Keeping the failures aside what has worked for me in the past is to add little padding (10%-20%) to all the tasks which no one would question and then we have enough padding to cover for any task in which the team really spent around 1000% percent more time than estimated. Again it really depends on how much the product people understand the efforts involved in development. Its hard to make some one believe that one line change took 3-4 days and another 1000 lines were added in half a day if they have not been there themselves.

</comment><comment><USER41> I think neither solution is the correct one.

I find that in the case of the second solution: "thorough planning" you get a bunch of people fabricating estimates of estimates with padding or not padding or trying to estimate a bunch of unforeseen events that are too far ahead to get an accurate handle on. Sure, the second is likely to be much more accurate just because the second is likely to be much, much longer but I have never given one of these estimates without it being followed up by immense disappointment by business with a desire to strong arm me into something shorter. This demonstrates a fundamental issue with the topic. Its not about the estimate at all.

I think the problem with estimates is their finality and assumption of correctness. I figure once you're in the developer-years category you might as well iterate the estimate a bit to get a better sense of it. Error bars should be translated into risk for the business decision.

Too often I see people claim to be making "rational, facts based" decisions on estimates (beyond 1 year+) are complete codshit. This is not rational decision making. These decisions should be about risk management assuming failure as opposed to thinking you can slot year+ development estimates together.

I think very often the desire to lock down development estimates into "rational fact" are business decisions of risk masquerading as technical developer decisions of fact. I have yet to see a situation where we deliver an estimate that blows a business decision out of the water where the business just backs down. It just learns to ask a different question and gets the answer it wants out of that.

</comment><comment><USER42> I thought this was a decent article, with decent advice if you're in a situation where you have to make estimates under conditions of uncertainty.

An example I've tried to use to explain software deadlines is the college term paper vs the mathematical proof. I can commit to writing a college term paper by a set date. I may do a good job or a bad job, but I know I can produce 20 pages on a topic with citations and references. It's really just a matter of will and follow through.

Many people experience deadlines this way, which is why they get a bit outraged when software developers fail to hit deadlines or warn properly that they won't. They don't understand that software can be more like a mathematical proof. You can tackle it, try things, but you only might crack it. You might be no closer than when you started. You might be moments away from cracking it and not knowing it.

My career advice to people is to seek out situations where software development deadlines have more in common with term papers than mathematical proof. These jobs do exist, though they are elusive. It's just another desirable aspect of a job, like better pay, nicer working conditions, telecommuting. There are jobs that define the goals of a software project more vaguely, to the point where you can deliver something great, or something merely ok, but there's really no chance you can't deliver something at all.

Some jobs go extinct because they are just so unpleasant that the people with the talent to work them simply find other options for employment. I personally find the stress or working under strict deadlines with very little certainty unpleasant enough that I'll accept lower pay or other tradeoffs to avoid them.

</comment><comment><USER43> I can name exactly two reasons:

First is they commit to unclear expectations and requirements and no one has the backbone to call it out. This is a leadership failure or a top-down problem, when a division is lead by weak management with poor communication skills. The fix for an organization is to hold the top accountable first for the results, which rarely happens.

The second is a bottom-up problem: where a team has convinced themselves the only way they can solve a problem is to use this one framework that they haven't used yet. In music, there's a mental block students get where they look at the student violin or guitar and are convinced the reason they don't 'sound good' is because they're using a cheap instrument. This is categorically false: they need to put years of practice into the instrument. In much the same way, developers are obsessed with the framework they haven't used yet. They should be obsessed with discerning the business requirements. If we went to the moon on slide rules, the stack you already have is likely more than sufficient to implement whatever challenge is front of you.

</comment><comment><USER44> As a long time engineer, and occasional pm. I steer teams to think about the worst case, and then triple that time estimate.

I know this sounds like setting up a team for failure, but I've seen it work again and again. It sets clear expectations for quality and delivery upwards and downwards which everyone can agree on.

Once this is done, the easier part is keeping everyone focused, and using all the leftover time well to raise quality.

<comment><USER38> I often ask people when they think it will be done and then multiply that number by five. It works pretty well :)

</comment></comment><comment><USER45> I kind of like the XP approach to this.

First, estimates longer than two (or was it three?) weeks need to be split into smaller pieces. (Because it seems that when the estimates exceed two weeks, the accuracy of the estimates goes down. We're just not good at estimating things longer than that.)

Second, if you don't know enough to make the estimate - if the task is something that you don't know how to do - the first task is to find out. In XP, this is called a "spike" \- a task where the purpose is to nail something down, rather than to produce a usable artifact. Often you don't know how to do something, but you can say that after two weeks of research, you'd have a better idea. So take the two weeks of research, and then you can give a decent estimate. (Hopefully - there are some tasks that you'll know you're done when you're done.)

</comment><comment><USER46> As someone that does this every day across all industries and project types, I agree 100%, but proper/effective planning is not a panacea for project success.

Identifying and managing Risk is as equally as important. As is Interface (the people to people / team kind) management and correct Quality Assurance.

On top of all of that you need good Project Governance to handle change properly, with clear limits and bounds for changing durations of activities, budgets, scope and acceptable quality, defining responsibility and accountability, delegating authority, setting regular reporting requirements and cadence.

Managing (non-trivial) Projects well is difficult, it takes hard work and careful thought. That is why we struggle. We revert to System 1 for all aspects of project management, not just planning.

</comment><comment><USER47> If you __really__ don't get to set the deadline, is it still reasonable to held accountable for that miss? Even if you give worst case and best case the only one anyone else focuses on it best case.

Personally, I prefer the 80/20 rule. That is most of the work will go fair quickly, or at least uneventful. It's the last bit that's always the killer. The devil is in the details, as they say.

When asked for an estimate we quickly identify the 80. The key is to pause and not write off the remaining 20.

p.s. Early in my career I read somewhere (I wish I couple remember where) something along the lines of:

Alomst everything takes twice as long and costs twice as much as your original estimate.

If I had $20 for every time I found that to he true, I wouldn't have time for HN. I'd be too busy counting my money.

<comment><USER48> I also like the 90/90 rule:

The first 90% of the work takes 90% of the time. The remaining 10% of the work takes the other 90% of the time.

[https://en.wikipedia.org/wiki/Ninety- ninety_rule](https://en.wikipedia.org/wiki/Ninety-ninety_rule)

<comment><USER47> Let's no forget the new feature requests after the first 90, once they see it. And, of course, don't allow the deadline to be adjusted.

Fast. Cheap. Right. Pick two :)

</comment></comment></comment><comment><USER49> Utterly awful article.

If I know that I've gone and gotten the milk a dozen times or more recently, I have a pretty good idea of the minimum and maximum amount of time it'll take me to go get that milk. It's 4km, about a seven minute drive, and the quickest I've done it is 20 minutes round trip, and the longest about 40 minutes (probably browsed the store a bit for other stuff), then I can give a fairly confident range quite quickly without having to over-plan.

It's after you've gotten the milk that the client remembers they're lactose intolerant and can you please go get some almond milk. That's when you get over-time over-budget. Although in hindsight, perhaps I should have asked what sort of milk they prefer.

</comment><comment><USER50> Complexity is not as democratizable as the industry likes to believe.

\- an org-chart team of 100 will perform worse than a tightly knit team of 10

\- a tightly knit team of 10 will perform worse if tangible results are expected on regular intervals of the choosing of managers (e.g., weekly, monthly, take your pick) as opposed to treating the software project as a computer science research project spanning a year or more.

\- a tightly knit team of 10 working on a software research project spanning a year or more will perform worse if expected to succeed in their first attempt as opposed to allowing them to fail one or more times and change directions, maybe even starting from scratch every time.

</comment><comment><USER51> > This is where System 2 comes in—if we performed a more thorough analysis, > these factors would have been considered in our answer. Then it would be > clear that it's much more likely to take 20 or 30 minutes to run to the > store instead of 10.

I have encountered an article (can't find the link now, sadly) that claimed that when developers gave estimations, breaking down tasks to sub-tasks actually had a __reverse __correlation to their accuracy. In other words, their first gut reactions were actually better than estimations given after going in-depth through all the details and sub-tasks.

<comment><USER52> > I have encountered an article (can't find the link now, sadly) that claimed > that when developers gave estimations, breaking down tasks to sub-tasks > actually had a reverse correlation to their accuracy. In other words, their > first gut reactions were actually better than estimations given after going > in-depth through all the details and sub-tasks.

I've noticed this as well. The last few years my 'gut' estimates have tended to be more accurate (and larger) - but since I can't support them with anything other than "Trust me, I've been writing software for over a decade", they're never taken seriously.

My guess would be that breaking down a complex software system into sub-tasks (esp. when you are breaking things down within modules) that are too fine grained fails to capture the inter-dependencies between sections of the code- base. So, you complete task A and move onto to task B, then realize you have to revisit the code you wrote during task A because task B is dependent on it and some of your early assumptions were imperfect. And then you need to fix the unit tests you wrote for task A.

And so on, and so forth.

<comment><USER53> Bottom-up estimation is probably more accurate for the _work_ to be done, but not for other project overhead. Using data from an analogous project to forecast the delivery date would include that overhead.

</comment></comment></comment><comment><USER54> One statistic that has stuck with me is that 80% of software projects fail. It's the default that your software will not succeed, or do well.

One small reason for that is poor time estimation, but having good time estimation won't make your software succeed. I think having good planning, makes for a good working environment, but it doesn't mean the project as a whole will succeed. It might mean the developers will be happier to be with you and pivot to the next idea.

I would like to look at the percentage of successful projects and see what proportion of these had good estimation attributes.

<comment><USER33> That's a meaningless statistic. The vast majority of large software projects do eventually deliver something of value, even if it's late, missing features, and full of defects. Is that a failure? Depends on the circumstances.

</comment></comment><comment><USER55> The simple fact is that individuals or companies following System 1 have a much greater chance of survival in the competition. The consulting individuals or companies will simply find it hard to survive without System 1 - <USER2> they already had a lot of capacity and capability built up. Unfortunately many get comfortable using System 1

System 2 works for Products (includes SaaS) and chances are that it mostly works for Products that have been slightly successful in the first place. This is where you also find consulting companies that may have obnoxious rates.

</comment><comment><USER56> I thought it was because people seem to like changing their product plans midway through development. Seen an awful lot of scope and feature creep in project management, usually either because of a 'client' who keeps wanting more or design by committee.

Though I guess that often ties into project management and planning failures too. Seen a few projects where no one seemingly asked what the client/customer/business needed or how they actually worked, which then meant a ton of refactoring further down the line.

</comment><comment><USER57> I think there are few main reasons why this happens. I understand this will not appeal to many developers and understandably so. Learning new frameworks and having freedom of choosing your technology is definitely nice when you are developer, but you also need to recognize that if you are changing your stack every year you can be experienced developer and yet are effectively beginner at your new stack.

1\. Managers (and developers, too) don't strive for repeatability and predictability of the process. Sticking to frameworks, reducing variability, forcing an exact development pipeline. It is not appealing to developers and managers are afraid to push this.

2\. Lack of feedback loop. At the end of every project/deliverable/iteration, ask what could have been done to prevent the problem (what could have helped to estimate this more reliably). Implement mercilessly as if bad estimate was on par with deployment failure.

3\. Move unplanned work to planned work. Prioritize delivering sound and good 100% of code over delivering quickly "the first" 80% of your solution. Develop code as if it was controlling Solid Rocket Boosters. Follow good practices like MISRA. Don't allow exceptions. Do PROPER code reviews. Most code reviews I have seen is a colleague spending minimum possible time so that he does not feel he did bad job. In my opinion good code review requires going throug evereything top down from requirements and then bottom up through each statement to understand everything is implemented correctly. This takes about as much time as implementing it in the first place. Make sure managers understand this typically takes more time to do correctly and they should expect payout later, not this iteration.

4\. Hire carpenters and make them your senior staff. Make sure you have clear understanding who is senior/junior developer. Senior developer is a person that understands broader context and can be left to supervise a small project with understanding he/she will be able to uphold standards and provide correct solution and guidance for the junior staff. Make sure your senior developers are carpenters -- most projects don't require exceptional skills and rock star developers. They require people who don't get bored once they see something working but instead have the drive to finish the second 80% of your functionality and do it with the same amount of focus as when they have started.

</comment><comment><USER58> When I was just starting out as a wet-behind-the-ears developer, an older, grizzled dev gave me invaluable advice for estimating: take your best guess of how long something will take and double it, that's what you tell the users. That advice has stood me in good stead, though I've found as I've gotten older and more experienced, I could probably reduce the factor from 2 to about 1.5.

</comment><comment><USER59> "Delivery dates have often irrelevant but very simple to understand impacts. Good and bad solutions have dramatic but very difficult to understand impacts."

[https://minnenratta.wordpress.com/2017/01/25/things-i- have-l...](https://minnenratta.wordpress.com/2017/01/25/things-i-have-learnt- as-the-software-engineering-lead-of-a-multinational/)

</comment><comment><USER60> One missing element is the failure to allow teams or their members to stay on the project. It is very common to see people pulled off to must haves, support needs, and even many projects totally skip out on accounting for staff vacations which can be costly with long term employees who have four to six weeks out.

It is so easy to come across the frustrated developer, frustrated that they just cannot be allowed to do the work.

</comment><comment><USER61> Conway's Law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

And most organization -- or collections of three or more people -- have dysfunctions. There are rarely process problems where technology is the main problem; it's the wet-ware between the keyboards and the chairs that make or break projects.

</comment><comment><USER62> Yes, plan, the more planning the better. But set the deadline _first_ , and plan and design around meeting the deadline. Ask yourself, "I have two weeks to deliver this, but if I had to deliver _something_ tomorrow afternoon, what would I do?" \-- and do that first.

<comment> house9-2 A.K.A. deadline driven development

this can work really well if you pare down the list of features and build the simplest version of these features

</comment></comment><comment><USER63> For me, not designing the product as a platform is no. 1 root cause of all the delays and confusions. People then to deliver for speed, make compromises. Over a period we end up in mud pile and slows down all future developments. This makes the speed slower & slower with age.

</comment><comment><USER64> The eternal conversation, apparently.

I agree with making fine-grained plans as a way to uncover issues. Just remember, no plan survives contact with the enemy. On the other hand, fortune favors the prepared. (I actually think those are both Eisenhower quotes, aren't they?)

</comment><comment><USER65> And then you make a good plan with buffers and it fails too.

Cause you forgot so many things that cost time: you'll catch a cold, the warm weather distracts, ignored the existance of family & friends, computer breaks down, ...

</comment><comment><USER66> OT: I like the "thinking systems" infographic but the fact that the green areas are few pixels off is annoying me to no end. I hope it's not a new trend.

<comment><USER67> "to no end" means: uselessly. "no end" means: endlessly.

<comment><USER66> Thanks, wasn't aware of that.

<comment><USER67> Welcome :-)

</comment></comment></comment></comment><comment> xyz-x Let's try another comparison: that to a skilled surgeon. 4+4 years to get GP status, then at least 4 years more to become surgeon; another 2-10 to lead in an operating theatre.

Diseases vary just like reasons for misbehaviour in code. While coding also has a bit of construction, that surgery doesn't, a lot of coding time is spent on extending or fixing existing behaviour. As such, the simile is better than the bridge-construction one.

It would also allow discussing leadership; a strong lead handles the 1-12 hours the surgery takes. He/She's expected to know the human body as a system, by being able to diagnose adverse conditions that occur during the operation, instructing the people around her as she goes.

Operations can't take too long, or fatigue gets you; the corollary being that you don't have slippage like you do in s/w dev. You can't be too unskilled, or else you can't perform the work. You have to have lots of training before you're the one leading.

Contrasting education; a lot of physicians go through much rote memorisation when they start their education. Then they continue with laborations; this could be useful for software engineers and operations folk, by letting them try their hand at diagnosing production systems having problems. Such training could be done by a 20-questions approach, with each question being answered a metric of a category of log entries. In the end you should know what the problem was. Labs at uni are much more constrained; they don't teach how large production systems behave and don't teach mental tools to debug them, they only teach the basics of programming. Furthermore, what they teach of programming is never geared towards what real systems look like, because most teachers have never been close to one.

There's no-place in the world that you can be education like what a surgeon would get; comp-sci is more like training everyone to be a psychologist (because we want to get the full picture!). Apprenticeship programs are more like training to be a nurse.

\- The formal education people receive is not applied towards bettering industry performance, it's geared towards inventing and academia \- Shorter education people receive is not about understanding the system and how to construct and fix it; it's about working next to it \- Similar hard rote- memorisation tests could be coupled with in depth debugging/operations sessions and experienced teachers active in large production systems, like understudies preparing to be expert surgeons \- In the light of this; we need a career ladder that doesn't end with the same title you start with "engineer"/"senior engineer". One that is structured.

</comment><comment><USER68> Software development is much more like R&D than it is engineering</comment>


Toybox is a 3D printer for kids - <AUTHOR> https://www.indiegogo.com/projects/toybox-the-3d-printer-just-for-kids-toys-technology/x/17194791#/ <comment><USER2> The bitmoji-style builder for 3D printed action figures is such a cool idea.</comment>


Publii – Open Source CMS for Static Websites - <AUTHOR> https://getpublii.com <comment><USER2> The license is GPL but I can't find the code repository anywhere.

We'd love do ditch WordPress but our users demand a web-ish interface to work with static sites. This could be it.

Also, what's the strategy for plugins?

<comment><USER3> Shameless plug:

\- We built [https://forestry.io](https://forestry.io) to get away from WordPress. We support Jekyll & Hugo and a Git-based workflow :)

<comment><USER4> I set up forestry on my father's bed and breakfast website. I am very pleased.

<comment><USER3> Glad to hear! I'd love to know how we could improv the experience if you have sky feedback

<comment><USER5> I'm using forestry for my company site now to give my non-tech cofounder an easy way to write blog posts.

Two suggestions that would really improve my life:

1\. A better wysiwyg editor. I've taught her some markdown but every time you switch to wysiwyg and back and make a change I get loads of spans injected into my md.

2\. A better media manager with: \- folders \- image resizing (maybe integrate filestack.io as they have some image manipulation)

I love the simplicity of forestry and it's really close to perfect for my use case. Github -> s3 is seamless and having edits committed back is great.

<comment><USER3> Thanks for the suggestion! #1 is in the works and #2 is in early planning stages.

</comment></comment></comment></comment></comment></comment><comment><USER6> Here is a link to an interaction between a user and developer from June 23rd 2017 RE: publii source code:

[https://publii.ticksy.com/ticket/1216232/](https://publii.ticksy.com/ticket/1216232/)

From Bob:

"We still preparing the dev documentation and I think it will be ready this holiday. Right now you can browse the themes packages and see how they are built. Below you can download the .pdf with handlebars tags used in Publii themes.

[https://drive.google.com/file/d/0B92PpHk85ShpZk50NVFVQlZjX3c...](https://drive.google.com/file/d/0B92PpHk85ShpZk50NVFVQlZjX3c/view?usp=sharing)

Referring to repository question, we will need to reflect further on this matter, but probably the GitHub is the best solution for that."

<comment><USER6> UPDATE (I can't edit my original comment):

Apparently the source code comes with the app:

From Bob:

"Hi Guys,

Publii is built with Electron, so the source code is available, you can read it directly after installing the app. Here is where the files are located: ;[https://getpublii.com/docs/install- publii.html](https://getpublii.com/docs/install-publii.html)

We know that there is no source code repository, we will publish it soon, but before that we have to finish work on the implementation some key features and polish the code.

The next release will bring a dev documentation with the Starter theme, I hope this will help you to better understand app and find out how the themes are built."

[https://publii.ticksy.com/ticket/1265759](https://publii.ticksy.com/ticket/1265759)

<comment><USER7> Apparently it doesn't. When I click to download - it's .exe and .dmg files. That this application is build with electron is beside the point.

<comment><USER8> After installing, go to the app folder, there are stored all files/data [https://getpublii.com/docs/install- publii.html](https://getpublii.com/docs/install-publii.html)

</comment></comment></comment></comment><comment><USER9> I definitely think there's demand for solutions like this. I probably would like this even better if it worked on top of an existing static-site generator platform like Jekyll or Gatsby.

I just wrote about immutable deployments with Ghost 1.0, which is also open source (MIT licensed), and how that can be a nice compromise between static sites and hosted CMSes: [https://ryanashcraft.me/ghost-and- now/](https://ryanashcraft.me/ghost-and-now/)

I might've tried Publii out if I had heard about it beforehand, but right now I'm really happy with the entire Ghost editing and consumption experience I've set up (thanks to the Ghost and Zeit teams).

<comment><AUTHOR> Awesome post Ryan, I really like your approach! I just found out about now.sh the other day, and found its features and capabilities to be very exciting, and pretty unique for the most part. Does Ghost still have the capacity to output static html (thought it did pre 1.0; not sure with latest) ? If so, can I ask why you didn't go with using that feature, and then push the html via now or to any other service, since you're composing/editing locally anyway? Also, I looked for the ability to make this comment on your blog post itself, but didn't see any facility to do so, and then realized that this was because it's a read-only Ghost instance as you described. Is there any way to get comments with this approach. I'm thinking with the an Ghost-to-html approach (if available still in 1.0), you might be able to script something up to also embed Disqus into the outputted HTML, but as far as comments with your read- only Ghost on now.sh approach, no way to incorporate comments, correct? Anyway your blog theme was pretty attractive on Chrome mobile BTW. Enjoyable read all the way around.

<comment><USER9> Thanks! Great questions. I'm not 100% confident about supporting static generation and Discus integration with Ghost 1.0, although I imagine it's feasible. That said, I'm personally not interested in pursuing either for my own blog at this time. Maybe in the future.

</comment></comment></comment><comment><USER10> Can't seem to find a link to the repo on their site.

<comment><USER11> No Linux option planned, and no public access to the source-code. That doesn't feel very "open source" to me.

<comment><USER12> how can they possibly call it open source without providing the source code. Also on the website it says it is licensed under GPL, doesn't that entitle users to source code access?

<comment><USER13> > Also on the website it says it is licensed under GPL, doesn't that entitle > users to source code access?

What ? Why entitled ? I have some WIP and production ready code in some git repo on my company's network and it's MIT licensed but there is absolutely zero obligation to upload it on the internet.

Of course I don't go around making website about it so there's that.

Pretty sure those guys will upload the source code when they feel like it's the time to do it.

<comment><USER14> the GPL requires that you make the code available WHEN you distribute it. they have distributed it, thus yes, we are entitled to it as of the time of distribution, not whenever they feel like it in the future.

<comment><USER15> The GPL applies to other users. There's no such thing as a license that applies to the person that wrote the code (that would imply that you could sue yourself for violations). They'd only be required to make the source available if they were using someone else's GPL code.

<comment><USER16> That is incorrect. If a company gives you a copy of the program under the GPL, then they must obey by that license because they made an implicit agreement with you to obey that license. And you can't call any other license the GPL (modifications are not permitted by the FSF).

Ultimately it does become a matter of "suing the copyright holder for a license granted by that copyright holder", but it's definitely still not okay. By that logic, no copyright license can ever be expected to be honoured by the original author -- because "they own the copyright and thus cannot be sued for breach of license".

Not to mention that you don't know why they went with the GPL. Maybe they used some GPL code and thus have no choice in the license terms. So it would be a matter of the original copyright holders suing them for breach of license.

<comment><USER15> > If a company gives you a copy of the program under the GPL, then they must > obey by that license because they made an implicit agreement with you to > obey that license.

The GPL is a set of conditions that others have to obey if they want to use your code. How can you going to sue someone for violating the copyright on code that's not yours? If you see someone selling copied Tom Clancy novels on the street, you can't sue them. Only Tom Clancy and anyone else to whom he grants the copyright.

> because they made an implicit agreement with you to obey that license

So Microsoft is bound by the license on MS Word?

<comment><USER16> > The GPL is a set of conditions that others have to obey if they want to use > your code.

Or distribute it. If someone distributes something to you under a license that _explicitly states_ that it gives you certain permissions, they can't arbitrarily decide to retract that license. That's sort of like saying "if I write a song, and give you a license that allows you to get the sheet music from me, I can refuse to give you sheet music if you ask". If you didn't want to give me sheet music, why did you explicitly give me the right to do it? On some level it sounds like a breach of contract, though of course licenses aren't contracts.

Also you've forgotten that maybe Publii is based on some GPL source code, so they might not be the sole author and thus are infringing on someone else's copyright by not obeying the GPL.

> So Microsoft is bound by the license on MS Word?

Yes, of course they are! That's the whole point! If you read Section B of the Microsoft Word 2013 License[1], it states quite explicitly that:

* In §B4, all disagreements outside of small claims or negotiations will be handled in a binding arbitration. This applies to both parties.

* In §B5, neither party can engage in a class-action suit (they must all be done on an individual basis).

* In §B7, it states that claims have to be filed within one year. That also will apply to both parties.

They also give you a limited warranty for non-trial software in the last section, which obviously they are also bound by. Obviously terms in the license that don't limit Microsoft don't affect them. But with the GPL, it explicitly states that distributors must provide the corresponding source code.

I think I know what you're trying to say, "are you saying that Microsoft employees are bound to the single-seat terms of the license". But that's missing the point -- Microsoft employees aren't given software under the license I just discussed, they're given software under a different license (implicitly) because they work for Microsoft.

[1]: [https://www.microsoft.com/en-us/useterms](https://www.microsoft.com/en- us/useterms)

<comment><USER15> > Also you've forgotten that maybe Publii is based on some GPL source code, so > they might not be the sole author and thus are infringing on someone else's > copyright by not obeying the GPL.

My comment was three sentences and I said exactly that in the third sentence.

> that's missing the point -- Microsoft employees aren't given software under > the license I just discussed, they're given software under a different > license (implicitly) because they work for Microsoft

Okay. That's exactly what I said. The entity releasing code under the GPL is not bound by the conditions of the GPL, and does not need to distribute the source.

<comment><USER16> > My comment was three sentences and I said exactly that in the third > sentence.

You didn't say exactly that, you said:

> How can you going to sue someone for violating the copyright on code that's > not yours? If you see someone selling copied Tom Clancy novels on the > street, you can't sue them. Only Tom Clancy and anyone else to whom he > grants the copyright.

While I understand your point, the fact that you cannot personally sue them does not change the fact that they're infringing on someone's copyright (so _someone_ could sue them). The point of this discussion is not whether you or I could sue them, but rather are they breaching the GPL by not releasing source.

> That's exactly what I said. The entity releasing code under the GPL is not > bound by the conditions of the GPL,

Odd, because that's not what I said. At all. What I said was that a Microsoft employee is bound by a different license than a random consumer. This was immediately after I _explicitly outlined_ several cases where Microsoft's EULA _clearly places restrictions on Microsoft_.

Microsoft distributes software under a EULA, and they have to act in accordance with what that EULA says (just like you do as the recipient of said software). The EULA is not symmetric in its restrictions (unlike the GPL) so I recognise the cause of confusion, but just because Microsoft isn't bound by the no-redistribution policy of the EULA (because that's explicitly only required of people who are receiving the software) doesn't mean the EULA doesn't apply to them...

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Just downloaded and tried it out. But selecting the SFTP key doesn't seem to work and there is no local filesystem option that I can see so I have no way to test at the moment.

</comment><comment><USER18> It is not the CMS, it is also the site generator which comes with its own themes.

<comment><USER19> How is it different from a cms?

<comment><USER18> A CMS is supposed to manage the content, not the presentation.

<comment><USER19> Wordpress has themes

</comment></comment></comment></comment><comment><USER20> Finally an alternative to Netscape Composer.

</comment><comment><AUTHOR> I posted this article, but have no affiliation at all, just thought it looked quite excellent and fairly unique, and was surprised it hadn't been posted to HN before this.

A feature that may be lacking that I don't see would be to get a local sync option in play if you are using multiple instances of the app (say you are using it sometimes on MacBook and also on Windows here or there). They do support pushing/syncing TO github pages, but I'd like to see perhaps a Git functionality used also to always keep any Publii instance synced locally with each other, and with Github, etc. I think that would really put this app over the top.

</comment><comment><USER21> Where is the repo? I can't seem to find any info on the site or Google.

</comment><comment><USER22> Looks very cool. If I hadn't already settled on a Hugo/Git/Netlify setup, I'd be investigating this for sure.

Also, congrats on writing website copy to appeal to non-techie audiences. It's well written, benefit-focused, and generally good stuff. I could actually see myself introducing this to non-techie entrepreneur friends and having them likely to use it.

P.S. - even more impressed that your docs seem to be written for non-technical users in mind too! Nice one.

</comment><comment><USER13> They actually support many languages out of the box (Ghost doesn't). I'll be exploring it this evening, looks nice and tidy.

</comment><comment><USER23> All I read is SEO.

All I see is a Mac app not feeling and behaving like a Mac app.

If I wanted these modern-Windows-style UIs, I'd use Windows. But I don't like them, so why does everyone try to explain to me how cross-platform, which is really pushing a windowsy UI and UX down the throats of all others, is so much better?

<comment><USER24> You can build an Electron app that looks and feel like Native app on both Windows and MacOS. And this app doesn't look like Windows 10 to me

<comment><USER23> > You can build an Electron app that looks and feel like Native app on both > Windows and MacOS

Show me one. Just one..

Most "cross-platform-apps" I used seemed to think moving the window frame buttons to the left and making the interface the same grey is integration enough.</slight_exaggeration>

> this app doesn't look like Windows 10 to me

Maybe my picture of windows is skewed, I haven't used it for many years now, I apologize. But isn't it even worse then? If it feels at home neither on Windows nor on OSX, but foreign to both?

<comment><USER2> I've had a similar experience with Electron apps. Quality (in terms of "nativeness") varies a lot.

This article lists many things Electron developers have to be careful about: [https://blog.avocode.com/blog/4-must-know-tips-for- building-...](https://blog.avocode.com/blog/4-must-know-tips-for-building- cross-platform-electron-apps)

</comment></comment></comment></comment><comment><USER25> > It's a desktop app, so you can manage your pages anywhere. Take a laptop to > the beach, write in comfort, then sync with one click once you're back > online.

Really? Wouldn't a web app be better for this?

<comment><USER26> If it was a web app, you'd need to install it, probably with a database for settings, etc., which would invalidate their security claims.

</comment></comment><comment><USER27> Aaaand no linux version. Pleae, people, cross-platform is not just win and mac. Especially with electron apps this should be a simple to include.

<comment><USER28> They've said a Linux version is coming.

Aaaand chill your entitlement, they don't owe you jack, no matter how simple you think it is.

</comment></comment><comment><USER29> The concept is not bad, but how do I change the actual looks of my site? Can't I edit the frontend somehow?

</comment><comment><USER30> The themes are absolutely incredible... for once I'm actually impressed!

</comment><comment><USER31> Xara web designer going popular again?

<comment><USER32> xara! that's some fringe memories right there.</comment></comment>


Ask HN: Do you care about grades from the Better Business Bureau? - <AUTHOR> From searching HN it seems this hasn't been discussed for some time.<p>- How much do you trust the Better Business Bureau?<p>- Do you think the grades are an accurate representation of a company?<p>- If a company has a very low score, do you automatically discredit them, or do you take it with a grain of salt?<p>- Do you hold their rating system in high regard? <comment><USER2> > How much do you trust the Better Business Bureau?

Not at all.

> Do you think the grades are an accurate representation of a company?

I don't even know what grades they give out.

> If a company has a very low score, do you automatically discredit them, or > do you take it with a grain of salt?

I've never looked at a BBB score.

> Do you hold their rating system in high regard?

Not at all.

</comment><comment><USER3> I think the BBB used to have much better reputation for their business ratings.

In my (admittedly limited) experience, must complaints leveraged against a company through the BBB are exaggerated claims that would be better suited for a poo Yelp review.

The only time I personally check out a businesses BBB score is if I am currently having issues, and am trying to find out of it is a common issue with the company (which would mean it will likely be a reoccurring issue in the future) or if it is a one off issue.

But then again, I take all only based ratings/reviews with a metric ton of salt.

</comment><comment><USER4> do people check that still?

<comment><AUTHOR> I've had clients speak along the lines of "Well they have a low grade on the BBB, so I'm not sure if I want to use them..." Or something along those lines. So I was just curious if anyone else had similar experiences or thoughts on the BBB

<comment><USER4> I know there was a big thing in like 2010 that tried to discredit them. They were forcing people to pay for good ratings and giving lower ones to people who wouldn't. Honestly thought they died out after that.</comment></comment></comment>


Pricing your consulting: You're doing it wrong - <AUTHOR> http://www.slash7.com/articles/2009/1/7/pricing-your-consulting-you-re-doing-it-wrong

<comment><USER2> Hard to say if the article has anything useful to say. I think it says that you should examine the opportunity cost of the things that you could do if you weren't consulting. Well that's true of an ordinary job.

What it doesn't say is that you need to factor in the cost of insurance, vacations, down time and the like when setting a rate or even if consulting is a good deal. If you are making $120K as an employee, is $70/hour a good rate? Probably not, likely you will be losing money.</comment>


Superspeed USB 3.1 Announced, Could Bring the End of Thunderbolt - <AUTHOR> http://www.maclife.com/article/news/superspeed_usb_31_announced_could_bring_end_thunderbolt

<comment><USER2> Mmmmm the warm smell of link bait in the evening. This reply will probably be longer than it needs to be but I find this stuff silly and want to vent.

TL/DR: The media loves writing "Apple v.s. the World" pieces and TB isn't really meant to compete with USB.

I, as well as many others based on comments I've seen elsewhere, think there are a lot of parallels between USB and Firewire and USB and Thunderbolt (TB). USB is a flexible interface you can use to connect to a camera, keyboard, printer, video adapter, hard drive, etc. It does a lot of this in software which means there's some overhead and various versions of the spec have had their own funky issues (like USB 1 & 2 being half duplex[1]). In the end it's "good enough" and no one except device implementors will have to deal with those problems. Firewire and TB are "better" technologies, designed to do some fairly interesting things. Firewire being essentially hot pluggable daisy chain-able SCSI and TB being an external PCI Express interface that can run over fiber optic cabling (whenever that shows up). As a device maker, unless your customers need any of those cool capabilities there's no reason to to use it. Same deal as with Firewire.

My take on articles like this is they're another case of some relatively boring technical enhancement being turned into the usual "My side must win" sort of religious war by the media (and parts of the general tech public) loves to turn these things into. Clicks are clicks after all. Partly this is because TB has been labeled an "Apple technology" because they helped with some trademark paperwork[2] and embraced it at launch. Unlike Firewire, Apple didn't do anything with the spec except say "Hey lets use this type of cable/connector." But honestly, that doesn't really matter because if it's related to Apple, they MUST be in some sort of battle against some force. In this case, the evils of USB...

Honestly, Thunderbolt seems great for Apple as their design aesthetic mandates (annoyingly IMO) a minimal complement of ports and TB doubles as a display connector and a data port. They won't see a cent by it becoming popular[2] aside from the sales of Apple branded accessories, but regardless TB makes it a lot easier for their customers to plug in an Ethernet adapter, keyboard/mouse, and a couple monitors without the need for a docking station (which is what I do with my MBPr) or a USB HUB/assorted mess (which is what I did with my MacBook Air).

Intel, as the creator of Thunderbolt, stands to make the most by it becoming popular (they make all the controller chips). That said, Intel is part of the USB consortium as well and it's hard to see how they can "loose" either way this goes.

[1][http://en.wikipedia.org/wiki/USB](http://en.wikipedia.org/wiki/USB) [2][http://www.anandtech.com/show/5425/why-thunderbolt-wont- come...](http://www.anandtech.com/show/5425/why-thunderbolt-wont-come-to-the- iphone-anytime-soon)

<comment><USER3> Exactly. As far as I can tell, you cannot connect an external monitor to a USB port and have a GPU drive it. Thunderbolt serves a different purpose than USB: it is an interface between a small number of external devices and a small number of hardware components. The fact is that it can only at this point be useful for three things: displays, drives, and Ethernet. USB is what you use when you do not have another option. It is nice since it can support almost any kind of device because the protocol is not burnt into hardware, but of course the downside is that it has to implement the host side of things in software. Anyone trying to use a "USB video card" to play an HD video will notice how much of a toll it takes on the CPU. And when the CPU is fast enough not to be bothered by a 1080p video, we will instead be talking about 3D 8k video.

Basically, it is nice that USB just got faster, but IMHO direct access to the specific hardware (disk controller, video card, etc.) will always win.

<comment><USER2> Agreed. I used a USB 2.0 video adapter on my Air and while it was fine for a terminal, it probably managed 25FPS at best (Youtube is choppy). It also has to be by itself on its own USB controller (well KB & Mouse are fine) due to the Half duplex nature of USB 2.0. Using it on the same bus as a HD makes the display lag badly. Still cool that it can be done.

The new USB 3.0 ones probably fix all/most these problems but I just use monitors 1 & 2 for that ;).

</comment></comment></comment><comment><USER4> I'm not knowledgeable in this area, but isn't Thunderbolt a more direct interface (since it's basically external PCI-E) with less overhead than USB, making it a better choice for devices requiring low latency (audio interfaces, graphics cards, SSDs, etc.)?

Regardless, I believe _Intel 's_ Thunderbolt is here to stay, along with USB 3.x...

<comment><USER5> Having never tried to program a thunderbolt bus driver, but knowing that writing USB packet control code as being the biggest pain in the ass because the entire standard is a hodge podge mess, I wonder if Thunderbolt is easy to implement connectors for.

Really though, the problem is like most licensed Intel tech they charge out the ass for licenses. They heavily jack up Intel CPUs and Thunderbolt to subsidize their huge R&D budget.

<comment><USER6> Greg Kroah Hartman wrote about implementing Thunderbolt for Linux: [http://www.kroah.com/log/linux/hardware.html](http://www.kroah.com/log/linux/hardware.html) (not a pretty story)

I suspect Intel has realised that people who need Thunderbolt have no practical alternative. May as well charge what that market will bear for a while.

AMD does have a low cost alternative - Lightening Bolt [http://en.wikipedia.org/wiki/Lightning_Bolt_(interface)](http://en.wikipedia.org/wiki/Lightning_Bolt_\(interface\)) \- and I will admit that if it takes off and beats Intel/Thunderbolt I will smile a bit. It will be AMD64 all over again.

<comment><USER5> I'm curious as to how the hell Intel can charge huge license fees on a pci express passthrough port. Though, it doesn't sound like Lightning Bolt is similar - the Displayport part, maybe, but USB is serial and has high latency compared to the pcie bridge.

<comment><USER6> > I'm curious as to how the hell Intel can charge huge license fees on a pci > express passthrough port.

They aren't - they charge the fees for Thunderbolt. You can't claim something supports Thunderbolt without paying licensing fees.

> it doesn't sound like Lightning Bolt is similar

You can draw a venn diagram and find that all three have an overlap. A desire for fewer cables, to be able to connect lots of stuff, and bang for the buck. Display, storage, peripherals etc. Outside of the venn diagram, Thunderbolt does have low latency, but most don't need or want to pay for it. If Thunderbolt support was as pervasive and cheap as USB, it would be a different conversation.

</comment></comment></comment></comment></comment><comment><USER7> Thunderbolt having direct memory access makes me slightly uneasy. I'm more inclined to fill the ports with superglue than actually find a use for them (I won't mind you). If the price of the accessories comes down, then it'll certainly be an incredible boost for some applications.

If anybody is interested in learning about them, there's direct key stealing attacks for both TB and FireWire if you look around.

<comment><USER8> Thunderbolt devices are currently a joke. The use case would be being able to push a laptop's GPU out to an external display card, so when you're docked you can run whatever desktop GPU you want.

But the cheapest connectors for that sort of thing can't to x16, and cost $800. Which, for the price, would let you buy an entire desktop.

<comment><USER9> The use case would be to connect to the dock with 1 cable rather than a huge port on the bottom. Or connect to an external drive bay for fast and low overhead access.

The external GPU thing has always been the most fanciful use case.

</comment></comment></comment><comment><USER10> Is anyone doing anything interesting and consumer-friendly with Thunderbolt? All I've seen it used for is DisplayPort, a slimmer DVI connector.

<comment><USER11> Apogee has at least one interface that's Thunderbolt ready and I'm sure a few other audio companies are working with it as well. Edit: Universal Audio. Others have plans/announcements.

Other products: external drives, external GPU (demoed by Lucid).

While trying to refresh my memory I came across this: [https://en.wikipedia.org/wiki/List_of_Thunderbolt- compatible...](https://en.wikipedia.org/wiki/List_of_Thunderbolt- compatible_devices)

<comment><USER12> The Apogee Symphony can be connected to Thunderbolt via the $1000 "ThunderBridge" ([http://www.apogeedigital.com/products/symphony-64-thunderbri...](http://www.apogeedigital.com/products/symphony-64-thunderbridge.php)), but it feels more clunky than using USB which can connect directly to the Symphony without the intermediate hardware.

The ThunderBridge gives extra benefits (the Symphony with USB alone can't go above 96kHz or 16 channels).

</comment></comment></comment><comment><USER13> Any idea what is driving these advancement? Why USB was slow in past and suddenly it is possible to get 10X more speed?

<comment><USER14> USB 1 was slow because it was designed to be a cost-effective way to connect keyboards, mice, etc. result: it did not require high-quality cabling, had the PC poll all devices for data, etc.

USB 2 stretched the USB 1 interface to its limits (for the technology of the day, and for a desired cost level). Devices could indicate that they could handle higher-frequency signalling and if so, they would be sent such signals, Backward compatibility meant that low speed devices kept using the slower timing, even if they shared the bus with higher speed devices. So, low-speed devices still use the same fraction of the total bandwidth. For example, a mouse will want to be polled a hundred times per second. It also will want be cheap, so it will use the slowest USB speed. Result: if it took 1% of USB 1 bandwidth, it still takes 1% of USB 2 bandwidth, while USB 2 is a lot faster. And because devices have to be polled, that is regardless of whether you use your mouse (yes, your mouse can take 4Mbps of your USB 2 bandwidth)

If USB 3 went along this line, things would have gotten ludicrous. Because of that, USB 3 uses different cabling. That allowed the, to also fix some issues that USB had. For instance, devices can now signal that they have data to deliver, whereas they had to be polled before.

Summary: USB 3 is a totally new protocol that uses different (higher quality) cabling and only shares some terminology with USB 2.

<comment><USER8> But are usb plugs now a noticeably different width to ethernet ports?

</comment></comment></comment><comment><USER5> I'm really interested in the 100 watt power bandwidth. That borders on making usb laptop chargers, saving a port on the side. Really expensive ones to support 3.1, though.

</comment><comment><USER15> The new Mac Pro coming out this year and its slim design is only possible by Thunderbolt. Apple expects you to use your huge Raid Arrays and other 3rd party hardware through a thunderbolt connection. USB can do this too of course, but not as fast.

If size matters at all in a workstation class device is a different question entirely, but in case you need a portable workstation (for mobile audio/video work for example), Apple is now the way to go.

</comment><comment><USER16> Is USB 3.1 going to get faster charging for mobile devices, too? That should be one of their priorities.

<comment><USER17> I fail to see how charging would be a priority of a protocol essentially designed for data transfer. I mean, it's a nice idea and there's enough consumers that would benefit from it but imo they'd better focus on the communication part of things instead of cranking up the amount of mA it should be able to deliver.

<comment><USER16> USB is also a standard for chargers now, so why wouldn't it be?

</comment></comment></comment><comment><USER18> Good. Thunderbolt is another lame Intel scam.

</comment><comment><USER19> Thunderbolt is a back door. Generally, physical access to any machine and "all bets are off", but still, I'd rather not have an orifice on my machine that says "fuck me here please" no matter what my business. USB can be implemented in ways that are more secure, but they are often not.

<comment><USER20> Yeah, I won't have an enabled 1394 connector on my PCs; USB is highly filtered and won't give you the bus-level keys to the kingdom.

That said, USB is a huge pain in the rear to deal with, especially isochronous traffic.</comment></comment>


Reductive - <AUTHOR> https://www.forbes.com/sites/startswithabang/2020/05/13/3-simple-reasons-why-wolframs-new-fundamental-theory-is-not-yet-science/ <comment><AUTHOR> Is Wolfram in a sense rejecting reductive thinking? According to his principle of computational irreducibility.</comment>


Byte-saving techniques in JavaScript - <AUTHOR> https://github.com/jed/140bytes/wiki/Byte-saving-techniques

<comment><USER2> "Byte-saving" made me think more of memory management than source file size.

Since version 1.5, JavaScript accepts Unicode characters as identifiers. Shouldn't this be "character-saving"?

</comment><comment><USER3> I hope everyone is upvoting this just for science. DON'T use these all the time, leave this job for a minifier and focus on maintainable code.

<comment><USER4> I think this is meant to be a fun project that gets people to learn some of the quirks in the Javascript language. It reminds me a little bit of code obfuscation contests: the more deeply you understand the language, the better you will do. The advantage here is that it's not intentionally misleading and actually could be useful.

<comment><AUTHOR> This is a good point. If you're going to write minified code like this, you should at least annotate it liberally like this example:

<https://gist.github.com/962814>

</comment></comment></comment><comment><USER5> This is aimed at people writing tweet-sized JavaScript for <http://140byt.es/> . This is a great resource for learning JavaScript and has some very impressive code behind it. Generally for production sites, though, I'd much rather go with jQuery due to its extensive test suite and bowser support. Between tweet-sized and jQuery-sized JavaScript, there's a whole lot of micro JS scripts / frameworks on <http://microjs.com/>

I'm currently writing a mobile web app that needs to work over GPRS connections with 30kb/s bandwidth and up to 1s latency. In these cases, shaving off a few bytes to get a page in 1 fewer TCP/IP packets really does make a difference.

<comment><USER6> Good lord, I'm pretty sure no-one is suggesting you use these in production. In fact it says at the top you shouldn't.

If you are writing mobile apps you should check out XUI instead of jQuery. jQuery (even jQ Mobile) is super heavy. XUI is jQ like, but it is by the Nitobi guys (of PhoneGap fame) and they really get mobile and did it right.

<comment><AUTHOR> A lot of these tricks _are_ used in production, the result of uglifyjs/closure minification of otherwise sane code. This is just a guide for hand-tuning.

</comment></comment></comment><comment><USER7> I love doing stuff like this for fun. Sometimes I try to get nice algorithms into tweets. Here is one of my favorites so far, returns the powerset for array 'a':

                function P(a){for(p=[],i=Math.pow(2,l=a.length);i;)for(b=i.toString(2),j=k=b.length,p[--i]=[];j;)if(b[--j]==1)p[i].push(a[j+l-k]);return p}

I know that there are some big gotchas here, such as b and p being declared globally due to lack of var...but I gave up trying to gain an extra 4 bytes for function(a,b,p). Also the subset arrays are in reverse order.

<comment><AUTHOR> There's a lot of room in there:

        Math.pow(2,l=a.length)
        1<<(l=a.length)

are the same, as are these:

        if(b[--j]==1)
        ~-b[--j]||

<comment><USER7> Thanks! This is an amazing guide. I forsee many more lost hours shaving and shaving with this in hand.

<comment><AUTHOR> Just remember to fork the master gist (<https://gist.github.com/962807>) when you're done, and add an annotation so that the rest of us can learn from it!

</comment></comment></comment></comment><comment><USER8>
      rand10=Math.floor(Math.random())*10 // before
      rand10=0|Math.random()*10           // after

The first is not random, it will always return zero (this error is _very_ common). The second happens to be ok because * binds tighter than |. However, this is order-dependent.

<comment><AUTHOR> Oops, that was an error (the multiplication should be within the .floor call). It's fixed now.

This style of code, while not for everyone, exploits the "happens to be okay" operator precedence. For this, Mozilla's MDC is a great resource:

[https://developer.mozilla.org/en/JavaScript/Reference/Operat...](https://developer.mozilla.org/en/JavaScript/Reference/Operators/Operator_Precedence)

</comment></comment><comment><USER9> Hah. Wish I'd thought of some of these for last year's <http://10k.aneventapart.com> .

I tried to write most of my JS for 10k 'pre-minified', using tricks akin to (but not as awesome as) these. Echoing other commenters, it was largely as an intellectual exercise (to see if I could meet the 10k limit by hand) but it did make me think of a few things in a different light, and some of the 'optimizations' are things that minifiers wouldn't have done for me.

It's also a good way to get under the skin of a language, get a feel for the nuances of how the runtime behaves, and give you hints for other (more generally useful) optimisations.

<comment><AUTHOR> It's also interesting to see how the approaches differ at each order of magnitude from 140byt.es to JS1K to 10K Apart.

At the smallest end you really have to work with what you're given and triage fast, whereas with JS1K you see people writing decompressors _in_ their code to get around JavaScript's occasional verbosity.

</comment></comment><comment><USER10> Shouldn't minifiers worry about all this stuff?

<comment><USER11> Generally yes, but sometimes it's a fun intellectual challenge to squeeze a piece of code as small as possible. Humans can also make assumptions that a "safe" minifier can't.

</comment></comment><comment><USER12> They should also add:

        Math.floor(someNumber) // 2.6 becomes 2
        someNumber | 0         // 2.6 becomes 2

Not only because it saves characters, but because it might actually be used in the real world (Whereas most of the ones in the article should really be left to a minifier)

<comment><USER13> The problem with this technique is that it will not work for large numbers (in my build of node, for example, the largest number it will work with is 2^31 - 1:

      (Math.pow(2, 31) - 0.1) // base number
        2147483647.9
      ~~(Math.pow(2, 31) - 0.1) // works!
        2147483647
      (Math.pow(2, 31) + 0.1) // base number
        2147483648.1
      ~~(Math.pow(2, 31) + 0.1) // doesn't work!
        -2147483648</comment></comment>