Software Development Estimates: Where Do I Start? - <AUTHOR> http://diegobasch.com/software-development-estimates-where-do-i-start <comment><USER2> An analogy I like to use: "Here's a book of sudoku / crossword puzzles. How long would it take you to solve all of them?"

Estimating this is similar to estimating a software system. You've seen puzzles like them before, but you don't know the difficulty level of each or which ones have tricky clues that cause you to rack your brain trying to find the solution. It also nicely illustrates the 10x effect: some puzzle solvers breeze through them while others take forever.

If you could break a software system down into a rigorous formal specification that could be precisely estimated, it would be possible to use that specification to build it automatically. Then that shifts the estimation up the ladder of abstraction to one where you estimate the time to create the rigorous formal specification.

<comment><USER3> Suppose you're asked to estimate a single sudoku problem. That's basically impossible, because n=1. In small samples from a large population, variation is enormous.

But what if I ask you to estimate the time for 100 sudoku problems? For 1000? What if, after 2 years of solving sudoku problems full time I ask you for your estimate? What if I develop simple statistical models based on the number of squares that are already filled in?

Already it has become possible to _improve_ your estimate, to make it more _accurate_. The value of an estimate is balanced on the line between the cost of its uncertainty and the cost of its development. Over time, for any class of problem, the cost of developing estimates falls.

<comment><USER4> > What if I develop simple statistical models based on the number of squares > that are already filled in?

What if you were unable to? NP-hard problems are weird like that. What if the underlying statistical distribution had random variance or some other strange features that make traditional statistical models useless?

Maybe the issue is that we're trying to use intuitions developed with everyday problems that are essentially linear ("mow the lawn", "drive to the store") in places where they're not appropriate. Unlike usual everyday tasks, NP-hard problems (such as Sudoku or coding) have no known "royal road" \- sometimes you just have to try all possible solutions.

<comment><USER3> NP-hard problems often have "good enough" solutions that don't take heat-death time to solve. Consider the TSP. You can wait until the last proton decays and tie up all matter and energy in the universe.

Or you can use an ant colony optimiser and accept that you will probably only come to within a few percent of the best possible solution. Oh noes!

And so it is with estimation. We can build an ever-more-elaborate estimate that will consecutively shave fractions of a percentage point of precision and accuracy. Or we can accept that _they are estimates_ , that they are meant to be imprecise and that accuracy is a range, not a number.

</comment></comment></comment></comment><comment><USER5> Most people would agree that practice makes perfect, right? I think a big issue with software estimation is that it is hard to get practice. I'd done full project estimates for 4-6 projects in 3 years of working professionally. Compared to the amount of practice I have writing code, this is nothing. How can I ever hope to get good at something if I only do it once every 3-6 months and it might take 2 years to get feedback on if my final number was close to the actual cost? And unlike other skills, I can't practice on my own or take a course (I've never seen an open source project that did round-trip estimates, maybe that's something to try out...)

Another issue is when you have an "indirect estimate" \- basically I will estimate the work, but someone else is the one that ends up doing the project. If you aren't careful to consider who will be doing the work, you might estimate too low (if you are an expert and the work is done by a bunch of new hires).

And none of this even touches on misinterpreting client demands, scope creep, dev team turn-over, or often neglected timesinks like documentation and meetings.

<comment><USER3> Perhaps you could try scaling estimation down, instead of up.

For example, in the SEI's Personal Software Process you estimate very frequently. Like agile, it works by attacking big problems in lots of small pieces. So instead of just doing the 4-6 whole-of-project estimates, you can also do estimates for stories, estimates for modules and so on.

The other thing to consider is re-estimating as you go. The Cone of Uncertainty demonstrates that as a project progresses, uncertainty about the problem and solution domains diminishes and so estimates can be made with tighter ranges.

</comment></comment><comment><USER6> My main trick these days for this problem is to discourage estimation by pointing out the costs of it and putting the burden on the requesters.

One great way to do that is to release early and often, allowing stakeholders to change plans in response to what they've learned. Instead of doing the work of (re-)estimating a bunch of stuff every week, their focus on what's actually going on lets them stop obsessing about arbitrary dates and semi-fictional plans.

People very rarely need estimates. They want a sense of control. They want to manage risk. They want to convince people that money is being well spent. They want to avoid looking like fools. If you solve those problems without using estimates, people generally stop caring.

<comment><USER5> I agree with that estimates are largely about a [false] sense of control, but this is a tough sell when dealing any company with budgets and stakeholders that have to go ask their boss for a finite number of dollars to trade for software.

Often times, this is a one-time ask. You get money allocated once, so you better get enough to build the whole thing. You can't go back and say, "hey boss! look what we got with the first $10k, can I have $10k more?"

If you are a startup or dealing with a 4-figure project from a local business, then sure, you can probably skip estimates.

<comment><USER6> Sure, but that's an artifact of traditional budgeting. In the Lean world (as in Lean Manufacturing), traditional budgeting is considered a dangerous and misleading activity.

Another way to work it is to have a backlog of valuable things to do that get handed out to teams. When somebody needs something to do, you pick the highest-ROI project from the backlog and give it to them.

In that context, detailed specs and careful estimates generally turn out to be wasteful. If you're trying to pick projects by expected ROI, then making the software estimate more precise than the (generally handwavey) business value estimate is pointless.

<comment><USER7> > you pick the highest-ROI project from the backlog

How do you calculate the return on investment without estimating the investment?

<comment><USER8> You don't have to know the ROI value of each project, just compare their relative sizes to select the best from the set of projects with the highest profit ranking.

This assumes, though, that the best of the projects is worth building in the first place.

<comment><USER3> How do you know their relative size? Isn't that an estimate?

</comment></comment></comment></comment></comment></comment><comment><USER9> Not sure where I first heard this (and it applies more to single developers), but I find this very true: when estimating the time needed to perform something, try imagining how much time ANOTHER person would need. In general we underestimate the amount of work when thinking in first person; we are much more accurate when assessing the ability of others.

</comment><comment><USER10> Knowing a bit about estimating construction, and a bit more about the estimating of design which is more akin to software, there's more to the ability to execute according to a time table than the author gives credit...and the fact that the process can be separated between design and construction gives a clue.

Mature processes for delivering construction start with a budget and something called a program - an architectural program being a design and implementation independent description of the project's components and the relationships among and between those components.

Then there is the matter of age. Architects aren't worth a shit until they hit about sixty. Those running big designs have decades of experience. In the US the median age for initial licensure is 33. It's not twenty-something's freshly out of college, or even parents with grade schoolers organizing the process.

Then, in the US, there tend to be standard contracts which describe industry standard milestones and acknowledge that nobody really knows how things will change over what is often a multi-year cycle. Buildings are delivered reasonably on time and within budget because the process of contracting for the work doesn't require reinvention - even the plumber's subcontract is a standard form and tied to CSI format specifications which are tied to industry standards and to ANSI materials standards and the building codes.

Nobody roles their own using the coolest new fad. It's Java, not Haskell. If you read Hamurabi, you'll see the source of those traditions.

<comment><USER6> The software process can not actually be separated into design and construction. Software is a 100% design activity. Construction is what our compilers and installers do. Projects that appear otherwise have created artificial barriers to prevent certain kinds of design at certain times.

You're also missing that repeatability in software is a sign of waste. If developers are doing things that are truly well-understood and predictable, then they're doing something wrong. They should download a library or extract a framework, automate the predictable parts, and shift their attention to something worthwhile.

<comment><USER10> As an architect, my business is 100% based on estimating my design time. Within that design time I also estimate construction time.

What allows me to do both is not only my personal 20+ years of relevant experience, but also the collective experience of the industry and design methodologies that reflect that experience. I.e. architectural designs are delivered in moderately well understood stages of increasing concreteness and there is an established language for communicating designs to clients (plans, renderings, project manuals).

Furthermore, repeating the same operations in the design of a building is no less a waste than in the design of software. The same may be said for actually constructing a building. Programmers have no monopoly on the ideal qualities of laziness, impatience and hubris. It's just through experience that I have learned that at some point the nail gun has to come out if the plywood is to go up.

Or the pencil gets put to paper if there's going to be a design - and note that it is not uncommon for good designers in the software world to start on the drawing board not the computer.

And this, I think gets at some of why people have so much trouble estimating software. They start designing the building having already decided on its structural system and hvac layout and light switch locations.

Choosing Django over Rails over ASP.NET before diving into the problem means that the tool has to be made to fit the job rather than delaying that decision.

Now, I'm not suggesting that this is always the case. But to put the difference in collective and individual experience in perspective, one of my mentors [a formal mentor as part of the formal process of becoming licensed as an architect] was Ronn Ginn, an architect known locally but not somebody anyone has heard of. Anyway, Ronn is still practicing. He started practicing before there was FORTRAN.

Think about how many Ask HN's there have been based on the idea that 28 is too old.

Frank Gehry, who you probably have heard of, is about the same age. His first project to receive any sort of attention came when he was 42 in 1971. He was nearly 70 when Bilbao gave him international fame.

</comment></comment></comment><comment><USER11> One thing my Dad always told me about software estimates: "Take the estimate, double it, and increase the time unit by one. So if they tell you it's a couple of days effort, that's really four weeks..."

<comment><USER12> Use the pi rule. Multiply the estimated duration by pi. Works for many other things too, besides software.

<comment><USER13> Multiplying by a value between 3 to 4 seems pretty common - the explanation I've heard being:

\- One to work out what you should be building ("I have to tel you what I want? I might as well build it myself")

\- One to build it

\- One to get in working in the required way (allowing for "That may be what I asked for, but it's not what I want")

And a bit more for contingency...

NB The above approach is based on an assumption that the real difficulties come from working out what to build - technical risks are generally easier to address (prototypes etc.).

</comment></comment></comment><comment><USER14> A gret book on that is _Agile Estimating and Planning_ by Mike Cohn[1].

Having that said, there has been a lot of controversy on the value of estimates recently:

 _Estimation is Evil_ [2]

 _Purpose of Estimation_ [3]

I believe their TL;DR comes from the second one:

 _For me, estimation is valuable when it helps you make a significant decision_

[1] [http://www.amazon.com/Agile-Estimating-Planning-Mike- Cohn/dp...](http://www.amazon.com/Agile-Estimating-Planning-Mike- Cohn/dp/0131479415)

[2] [http://pragprog.com/magazines/2013-02/estimation-is- evil](http://pragprog.com/magazines/2013-02/estimation-is-evil)

[3] [http://martinfowler.com/bliki/PurposeOfEstimation.html](http://martinfowler.com/bliki/PurposeOfEstimation.html)

</comment><comment><USER3> > _The gist of why estimates are hard: every new piece of software is a > machine that has never been built before._

I am tired of the argument that we unique snowflakes amongst all professions and that consequently we deserve special treatment. We aren't. _All_ professions deal with uncertainty and most of them deal with it deliberately[1]. Throwing your hands in the air because a perfect prediction is impossible is just silly; an estimate is _by definition_ an _uncertain_ statement of an _unknown_ variable.

Estimating software can be difficult because there are many points at which complexity can be multiplied (McConnell's example of the requirement "validate phone numbers" shows a span of minutes to months)[2]. But when you see very wide ranges on an estimate, it's a signal that the problem is poorly understood.

Outside of _genuinely novel research_ , improving estimation accuracy is possible and valuable. And how often do we invent publishable new algorithms for graph traversal?

I have skin in the estimation game, as I am currently developing a tool for performing estimates[3]. I've also been researching the topic of estimations generally.

I'm mostly amazed at how people in my profession try it once, get an inaccurate result, and then decide -- "That's it! It's impossible! I tried it one time and it didn't work!". If you go into a gymnastics club and you can't do a backflip, that doesn't mean backflips are impossible in principle. It means _you_ can't do it. Estimation is a skill too.

[1] See Petroski's _To Engineer is Human_ , I reviewed it here: [http://chester.id.au/2013/07/07/review-to-engineer-is- human-...](http://chester.id.au/2013/07/07/review-to-engineer-is-human-the- role-of-failure-in-successful-design/)

[2] In _Software Estimation: Demystifying the Black Art_.

[3] [http://confidest.com/](http://confidest.com/)

<comment><USER6> _> I am tired of the argument that we unique snowflakes amongst all professions_

Aren't we, though? Zero marginal cost of production is at least very rare. It basically means that to the extent that our projects aren't novel, then we're wasting time duplicating something that ideally would have been copied from elsewhere.

And that not even getting into the very high rate of change in tools, techniques, and materials (e.g., [http://www.jcmit.com/mem2013.htm](http://www.jcmit.com/mem2013.htm)), which, if not completely unique, is certainly unusually high.

 _> But when you see very wide ranges on an estimate, it's a signal that the problem is poorly understood._

That is occasionally a sign of idiocy. But at least on the projects I see, it's much more often a sign that it's an interesting problem. Indeed, if you're delivering software in a competitive market, it's guaranteed the problem will remain poorly understood, because your competitors will be doing their best to create changes in the landscape.

<comment><USER3> > _Aren 't we, though? Zero marginal cost of production is at least very > rare._

Every profession can come up with a comparable point of uniqueness. Perhaps I should have said "special snowflakes" instead of "unique snowflakes".

> _It basically means that to the extent that our projects aren 't novel, then > we're wasting time duplicating something that ideally would have been copied > from elsewhere._

This is a good argument. It reminds me of DeMarco's argument that as time goes on, software engineering becomes less and less about process, because anything that is repeatable will be automated. All that's left is the hard bits that can't be automated.

There is, however, an enormous amount of duplication in our industry. And even when we are adapting an existing system, we're still only rarely performing acts of genuine novelty. Carpenters produce many items, none of them quite identical, but they aren't inventing new methods of carpentry or entirely different kinds of furniture on every job.

> _But at least on the projects I see, it 's much more often a sign that it's > an interesting problem._

I envy you.

<comment><USER6> _> Every profession can come up with a comparable point of uniqueness._

Not in ways that have such dramatic effects on predictability of costs.

 _> There is, however, an enormous amount of duplication in our industry._

Sure, but if we're going to put our attention somewhere, I'd rather we work on eliminating that waste, rather than standardizing the waste so that we can better estimate the cost of doing work we didn't really need to do.

<comment><USER3> Your last remark is true, but a bit falsely dichotomous. The choice isn't between perfect estimates and zero wastage. In practice all projects lie on a continuum between totally novel and pointless duplication. Within that continuum we can draft estimates of varying accuracy and I don't see a reason why we shouldn't.

<comment><USER6> The amount of time we get is fixed. Estimation is, from the Lean persepective, muda (normally translated as waste). If I can be spending that time instead on an activity that reduces the waste of duplication, I'd rather do that.

I should be clear that I'm not totally opposed to doing estimates. I've done a lot of them, I'm good at it, and there are circumstances where I would do it again. Some waste is temporarily necessary.

What I'm pushing back against here is the common assumption (which maybe you don't have) that estimates are generally a good thing to do, or, often, the only way to do things.

<comment><USER3> > _If I can be spending that time instead on an activity that reduces the > waste of duplication, I 'd rather do that._

Estimates can prevent waste by giving us a better of idea where to redirect effort. Time is, as you say, doled out at a constant rate.

The highest ROI possible for an estimate is to prevent wasteful effort from proceeding.

Timeboxed systems still perform estimation, you just hold different variables constant. In flow-based systems you can perform estimates by taking an integral of the current output.

My point is that estimation is _always_ present, even when we go out of our way to say that it isn't. They lie on a continuum from gut feel to supercomputers and conference papers. Estimates are always present because humans must always reason under conditions of uncertainty; the future is strictly unknowable.

Part of the confusion here is that I think there are two or three definitions of estimate in this thread. I am talking both about the universal case and the methodical estimate-with-an-E case. The universal case is that all decisions leading to action or inaction involve estimation. The methodical case is that estimation for software development is possible and tractable outside of genuine research.

</comment></comment></comment></comment></comment></comment></comment><comment><USER3> My favourite book on software estimation is McConnell's _Software Estimation: Demystifying the Black Art_.

As usual he takes a vast body of literature and boils it down into a chatty, usable book. The tables and checklists are worth the sticker price on their own.

<comment> do-it-good "As usual" for what - a book, the author, a book series called _Demystifying the Black Art_ ?

<comment><USER3> As is usual for McConnell. All his books are excellent.

</comment></comment></comment><comment><USER15> My key advice is to not pay attention to the minutia of the task, if you do you'll always underestimate. A better method is to forget the specifics and ask yourself 'If a buddy told me he was doing this, how long would I guess it would take?'. We have more experience hearing about projects and how long they took then we do really estimating the duration of creative tasks by reduction.

<comment><USER16> This is finger-in-the-air approach, which seems doomed to fail. For a start, it relies on your buddy having exactly the same career experience as you, and any new project being an almost exact match to previous projects you have worked on.

It doesn't take into account the unknowns, and doesn't break the task down into components that you could at least attempt to quantify.

Personally I go through a short mental breakdown of the project, trying to partition it in my mind into smaller jobs. Based on my years of experience I will then have a gut feeling for certain aspects of the project.

If any job is more than 3 days long, then I try to break it down further.

If I can't mentally break it down, then I need to spend some time researching why that is (investigate the unknowns).

Once everything has been broken down, and I have reduced the unknowns as much as possible I add contingency. Anything that I feel has the potential to be problematic I will add more contingency to, or add additional research time.

</comment></comment><comment><USER17> Completely agreed -- and I hit on the same themes on a talk on software engineering management (and its pathologies) at Surge on Friday[1]. The date fetishization so common in software engineering management is a direct result of non-technical management, who do not understand that every piece of software is solving a heretofore unsolved problem (even if a teensy tiny one) -- and that the unknowns often cause software to take much longer to build than one would anticipate. This gives a kind of CAP analogue for software: schedule, quality, features -- pick only two.

[1] [http://www.slideshare.net/bcantrill/surge2013](http://www.slideshare.net/bcantrill/surge2013)

</comment><comment><USER18> There is a way to get a perfect estimate - and that is to build it and see how long it takes.

Everything else is using an abridged model is short-cut the process. However, I think this is an important point. Estimating is somewhat akin to actually building the end-product.

The reason I find this important is that the most common spiral of death I see is re-estimation. You take on something unrealistic, plough on regardless, realise too late, then you re-estimate. The re-estimation causes a project stall and takes time. The end result being you have less time.. Few months later you're in the same boat again (repeat).. Big organisations are really prone to this.

<comment><USER3> > _There is a way to get a perfect estimate - and that is to build it and see > how long it takes._

The concept of a "perfect estimate" is tautological, isn't it? Estimates are by their definition uncertain statements.

<comment><USER6> I believe that's his point.

<comment><USER3> Then the larger point is that if estimates are always imperfect, we need to stop obsessing about their always being imperfect.

<comment><USER18> Yeah, more or less :) I think admitting/deciding upfront what you want to be imperfect is a good start.

</comment></comment></comment></comment></comment><comment><USER19> "The gist of why estimates are hard: every new piece of software is a machine that has never been built before."

This statement is simply not true. Every new piece of software can be broken down to pieces that are very similar to other software that had been done before. This is actually the secret to providing a good estimate.

What generally screws up estimates are complications that arise. Much of it actually has to do with pre-existing code as opposed to new code. If you were to build something from scratch and had a team of experienced engineers, I'd bet that you'd get a pretty damn accurate estimate.

<comment><USER20> Disagree entirely. If "Every new piece of software can be broken down to pieces that are very similar to other software that had been done before", you are talking about assembling library components, not programming (though as you say even that often comes with its own unforeseeable difficulties).

This is the fundamental paradox of software development estimation (and separate to the uncertainty of external forces): when you try to estimate development you are estimating design of something that has never been made before. If you aren't, you should probably be buying a product instead of building. It's a fool's errand basically.

</comment></comment><comment><USER21> "...The gist of why estimates are hard: every new piece of software is a machine that has never been built before..."

Yes, and that's why a lightweight, repeatable estimation process beats every other way of doing it. As you continue to estimate, you create and refine a mental model of the project's complexity. For some projects, you're able to create a mental model that has high fidelity quite easily. For others, it takes a bit of work. The entire article here was an exposition on this fact.

Some folks figure that out and want to just give up. Estimation is impossible! Other folks, however, are going to figure it out if it kills them. What happens in these cases is they start to list every possible variable that could be involved in such a model in every scenario, and then create one uber, ultimate, super model that works in all situations.

Over time and through lots of trial and error, both approaches have been found to be bullshit. Instead of giving up, or creating more and more complex models that take more and more time to work, with each project you're better off starting with the most ludicrously simple model you can and then adding complexity as needed. The trick is incremental complexity, repetition, and convergence. If you have that nailed, the details of your actual model, oddly enough, do not matter that much.

Obligatory link to previous comment: [https://news.ycombinator.com/item?id=6389227](https://news.ycombinator.com/item?id=6389227)

<comment><USER20> Interestingly, Thoughtworks have observed that over a project they get the same consistency simply counting number of tasks as counting effort estimates for those tasks. The key for project management is therefore to focus on maintaining a backlog of manageable tasks and throughput, not in estimating them individually.

<comment><USER21> We're finding this out in a lot of places. The key issue is variability. Larger sample sizes usually lead to less variability, which means flow-based systems will hold up better.

If you've broken your work out into tasks, instead of stories, presumably you have a lot of them, and they're mostly the same size over a large set. So sure, should work fine.

If, however, you have a small number of highly-variable chunks of work, then flow-based systems fail. It all depends on the nature of the item pool.

<comment><USER3> Summation can _apparently_ reduce error without, actually, reducing error. I wrote an article about different ways of measuring estimate accuracy[1] that explains the difference.

It's a question for each business as to whether that matters.

[1] [http://confidest.com/articles/how-accurate-was-that- estimate...](http://confidest.com/articles/how-accurate-was-that-estimate/)

</comment></comment></comment></comment><comment><USER22> I think the problem is that developers(including myself) tend to make estimates assuming that they're not going to find anything that makes them say WTF! Code is never perfect and it's extremely difficult to know how much time it's going to take to dissect and restructure code to accommodate your new feature.

<comment><USER3> This is called optimism bias -- when estimating, we forget the things that can go wrong.

</comment></comment><comment> alok-g >> "The gist of why estimates are hard: every new piece of software is a machine that has never been built before."

What is not explicitly said here is that a good developer needs to know what would be a "new" piece of software. He should be at least vaguely aware of what has been built already, what is within the reach of the state of the art, etc. And just like in the stock market, it is impossibly hard to know all the needed information to come up with wise judgement, complicating the estimation process even more. Yet, this is an essential piece in estimation anyways. Just for example, for some projects you may simply declare them to be beyond the state of the art.

</comment><comment><USER23> I address the problem by giving a range. Giving a single number is the real problem. For example I might estimate something as two weeks plus/minus six weeks, or a month plus/minus a week. That range is because of the usual factors (scope creep, things that have never been combined before, testing, meetings, holidays etc).

Sometimes the questioner picks up on the two weeks minus six weeks is a negative number. I then explain that existing functionality could be used, goals could be achieved in other ways, or maybe it just isn't really needed.

</comment><comment><USER24> [http://www.amazon.com/Software-Estimation-Demystifying- Pract...](http://www.amazon.com/Software-Estimation-Demystifying-Practices- Microsoft/dp/0735605351) is fantastic for giving many approaches to the topic, and counseling for non-technical stakeholders where it isn't a negotiation, but math.

</comment><comment><USER25> Always provide two quotes, the "shoot the moon" and the budget quote. The client will always cherry pick segments from the more expensive quote to arrive right at their budget. You can still loose to the next guy, but if you are in the ballpark, it won't be because you came in (a little) too high with this approach.

</comment><comment><USER26> Simple 5-step methodology: [http://blog.pmrobot.com/2011/09/5-steps-to- estimate-software...](http://blog.pmrobot.com/2011/09/5-steps-to-estimate- software.html)

</comment><comment><USER27> Good judgement comes from experience. Experience comes from bad judgement.

</comment><comment><USER28> Minimum of 2 weeks for anything you think might take more than 4 days, if it's a day then double it. etc.

</comment><comment><USER29> I really like this statement: "Every new piece of software is a machine that has never been built before. The process of describing how the machine works is the same as building the machine."

That's probably the best way of relating the problem to non-engineers that I've heard.

</comment><comment><USER30> I ALWAYS quote fixed price projects regardless of scope. Some software engineers would say that's highly risky. For me, it tends to be highly profitable because my estimates are usually accurate. If anything, I've learnt to over estimate and impress clients by delivering on promises.

I am amazed by the number of people who try to portray computer science as a pseudo science like voodoo, where estimates are impossible because the problems are unknown. Just because information is abstract doesn't make it any more difficult to estimate than something physical. Computer science IS a science and software engineering IS engineering. Good engineering involves breaking problems down into small manageable pieces that are easily understood then planning how to implement them. This practice is called design. On more complex projects it's architecture - a sexier form of design.

Let's get back to basics. Who has heard of "the software development life cycle"? Everyone, I hope. It's modeled off something from the early 19th century called the product development life cycle. It needs to be mentioned because IT people like to think they're special and mysteriously invented SDLC. Feasibility, analysis, design, development, testing, deployment, etc. Agile methods are simply a minimal version of this repeated fast and frequently. Release the minimum viable product then iterate. Unfortunately, so called "hacking culture" has led people to jump straight to development without considering analysis or design. Real hackers design their attacks first. Successful hacks are well thought out and executed in small brilliant steps.

The analogies of sudoku in defining a problem and construction in defining a project are perfect, so I'll borrow those.

If someone presents me with a 1000 sudoku puzzles of varying difficulty, the first step in estimating is to DESIGN a solution. Allocate time to categorize each puzzle by complexity. Then estimate times based on complexity based on past experience. Anyone who says they can't do this because they have no experience with the problem should be immediately fired. You've obviously misrepresented your experience and/or skills as an engineer of sudoku problem solving.

If a problem is truly unique and novel (and very few are nowadays), then simply factor in time during the analysis & design to perform a few experiments that will more accurately help with estimation. Or training. OR HIRE SOMEONE WHO HAS DONE IT BEFORE to help with design and estimations. Then find the most effective resource to implement (solve) each puzzle.

As for construction, any idiot can slap a few lines down on a piece of paper and call it a design for a house or a building. That's the way some people are building software. Real architects and engineers exist because construction can be broken down into hundreds of thousands of pieces and estimated accurately. They know exactly how many bolts it will take and what types of contingencies to allow for. Software, although abstract, is no different. The software industry has been around for 40+ years and it's modeled off past industries like construction and manufacturing. It can be accurately designed and estimated.

Once a clear design exists, estimation is easy.

My preferred estimation method is function point analysis. It's simple. Break each problem down into the smallest manageable piece. Any piece that takes longer than a couple of hours is too large and should be broken down further. That's an excellent rule of thumb. Anything longer than a couple of hours also suggests the design was poor.

Of course, in some organizations this fails due to a lack of clear process. An analyst will be tasked at collecting business requirements to write a specification. That is often full of nonsense written by someone with no design experience. That specification is given directly to a developer for estimation and development. Where was the design? The nonsense works it's way into the product. It becomes an estimation nightmare. Projects and budgets run over or worse, fail.

How do I know this works?

When I break a job down for a client into small manageable pieces I know the entire scope and can estimate accurately.

Clients love it because they can see every single piece of the puzzle in the design. The quantity and times for each piece look reasonable when broken down. The clients begin to appreciate the scope but ultimately don't care how it's built or what technology is used. They just want to know how much and when? If there is a deadline? Either add more resources or cut functionality. Let them make that choice. It's not my concern.

The cream, and why this industry is so much better than construction and manufacturing, is to look at all the pieces and see the re-usable patterns. Design optimization. Copy, paste and re-use as much as possible. Clients don't care about re-usability. I charge top of market rate and still manage to be cheaper than competitors because my estimates were realistic (as opposed to their crystal ball methodologies). Re-usability and working smarter then gives me 4-5x that hourly rate. Shh! Don't tell the clients :)

If you can't estimate software accurately, you're clearly in the wrong business!

<comment><USER31> > If you can't estimate software accurately, you're clearly in the wrong > business!

That was a terrible closing statement to a pretty helpful writeup. Software estimation isn't something you're going to be good at off the bat. So with your logic, nobody new should be getting into any software development were estimations are requested (most situations)?

</comment></comment><comment><USER32> Does the customer understand what they are asking for?

Can they afford it?

</comment><comment><USER33> Some additional notes/suggestions on estimation on Stackexchange: [http://freelancing.stackexchange.com/q/495/67](http://freelancing.stackexchange.com/q/495/67)</comment>


Does one have to be outside the USA to qualify for the Entrepreneur Visa? - <AUTHOR> Does one have to be outside the USA to qualify for the International Entrepreneur Rule (IER) status? How would IER work for someone inside the USA, like an F1 student? Would the student be able to -
1. register the company?
2. Build the product with a co-founder or alone without making any income for himself?
3. Raise funding from US investors?
4. Hire US citizens and pay through equity (but not paying himself)? <comment><USER2> Random internet advice: If immigration is important, hire a competent immigration attorney. Case law is complex and not logical. The little details often matter a lot.</comment>


Remind HN: Unicode hacks - <AUTHOR>

Just a friendly reminder that some Unicode characters[1] look like spaces and should be taken into account when writing filtering/trimming functions. Of course it's not a big deal but something to keep in mind to prevent stuff like usernames who are basically a bunch of spaces.<p>[1] http://www.cs.tut.fi/~jkorpela/chars/spaces.html <comment><USER2> This is a classic web security problem; most famously, WinAPI systems have a "flattening" function that would convert things like PRIME U+2032 into ASCII 0x27 (the tick that terminates SQL statements). Database engines can also interpret character sets differently than the rest of the app stack, leading to similar problems. UTF-7 cursed Wordpress for something like a year in which multiple preauth SQL injection flaws were discovered.

The answer to these problems is whitelist filtering and neutralization; if a character isn't known-safe, substitute its HTML entity alternative. If you're writing blacklist filters that need to know what spaces are, you're already playing to lose.

<comment><USER3> Sorry, whitelisting isn't the answer to SQL injection - bind parameters are.

With bind parameters you can pass data out of band, and the DB engine never tries to parse it as SQL.

<comment><USER2> I wasn't trying to be prescriptive about SQL injection. But, it always skeeves me out when people knee-jerk out "parameterized queries" as the answer to SQL injection. Yes, they're better and safer and you should use them wherever you can. But they don't "solve" SQL injection; for instance, there are query fragments that can't be parameterized (which is why you still find SQL injection in sortable table headers and in pagination and in custom query builders).

Be careful.

</comment></comment></comment><comment><AUTHOR> Seems like Twitter is "vulnerable" to U+00A0 tweets: <http://twitter.com/#!/olivierll/status/7852651047817216>

For those who are wondering, you can type Unicode codes directly from your keyboard (Ubuntu: Ctrl-Shift-u, other OS: <http://en.wikipedia.org/wiki/Unicode_input>)

<comment><USER4> A more innocent trick with unicode and twitter is squeezing extra characters in a tweet by using unicode ligatures:

[http://en.wikipedia.org/wiki/List_of_precomposed_Latin_chara...](http://en.wikipedia.org/wiki/List_of_precomposed_Latin_characters_in_Unicode#Ligatures)

Unfortunately the amount of ligatures is small but it might come in handy.

</comment></comment><comment><USER5> Interesting - just tested it in python and everything is removed with str.strip(), _except_ "\ufeff", which also has zero width.

        >>> print("\ufeff#")
        #
        >>> print(len("\ufeff#".strip()))
        2

</comment><comment><AUTHOR> For more details on the potential visual spoofs: <http://unicode.org/reports/tr36/#visual_spoofing>

</comment><comment><USER6> There are also other unicode hacks like changing  text direction (U+200F).

<comment><USER6> It used to have funny effects on websites (browser name in title bar spelled backwards), but it doesn't seem to work now. The above comment contains the unicode character three times.

</comment></comment><comment><USER7>

<comment><USER7> Seems ALT+0173 works here as a "blank" character. I'm not sure of its exact purpose, but I've never seen it dealt with and often use it as "nothing". The only solution I've seen to properly sanitising Unicode characters is just to disable them entirely and print their name.

<comment><USER8> If you break my "typographer's quotes" by overzealously sanitizing when you don't absolutely need to, you'll end up 6' under a † if you know what I mean. ;-)</comment></comment></comment>


Understanding id_token, access_token and refresh_token – ONCE and FOR ALL - <AUTHOR> https://mannharleen.github.io/2020-03-11-id-access-tokens/ <comment><AUTHOR> Is this post correct?</comment>


Colgate Total Ingredient Linked to Hormones, Cancer Spotlights FDA Process - <AUTHOR> http://www.bloomberg.com/news/2014-08-11/in-35-pages-buried-at-fda-worries-over-colgate-s-total.html

<comment><USER2> Just to save people the click, it is triclosan again. This story has been resurfacing for at least the last few YEARS but yet it is still on the market.

I for one have moved to a triclosan free liquid hand soap but a lot of toothpastes continue to contain it.

<comment><USER3> That's funny because the only reason I buy Colgate Total is because it's the only toothpaste with triclosan.

<comment><USER4> What is it about triclosan that earns your purchase? Genuine question.

<comment><USER5> [Note: I'm not the guy you're asking and this isn't meant to be any kind of advice -- dental or otherwise]

My dentist told me that Colgate Total was better at killing plaque-creating bacteria due to its use of Triclosan.

I just found a FAQ from Colgate about the use of Triclosan in Colgate Total [1] -- here's a short excerpt:

 _Colgate Total® toothpaste is uniquely formulated with 0.3% of the antibacterial ingredient triclosan to fight harmful plaque germs, which are the cause of most common dental problems. Colgate Total® is clinically proven to work better than other toothpastes to reduce these germs that can cause the gum disease gingivitis._

[1] [http://www.colgatetotal.com/triclosan- faq](http://www.colgatetotal.com/triclosan-faq)

</comment></comment></comment></comment><comment><USER6> I do appreciate knowing that this ingredient is in Colgate Total. That tube is getting thrown out!

Let be clear, this is really old news. Here are a couple HN threads on the topic:

[https://news.ycombinator.com/item?id=6917335](https://news.ycombinator.com/item?id=6917335)

[https://news.ycombinator.com/item?id=1251369](https://news.ycombinator.com/item?id=1251369).

<comment><USER7> Lets be clear, those old stories are in regards to soaps!

<comment><USER6> Soaps containing triclosan...

Toxicity is usually not contained to just one cell-type or organ. My point is that given the past toxicological evidence for this compound, this story should not come as a surprise to anyone.

<comment><USER7> > Soaps containing triclosan

I clearly know that. Look what I said.

> this story should not come as a surprise to anyone.

It's come as a surprise to you:

'I do appreciate knowing that this ingredient is in Colgate Total. That tube is getting thrown out!'

</comment></comment></comment></comment><comment><USER8> I didn't know it was in toothpaste. I do know that it's in hand soap, body soap, and even tissues now.

<comment><USER9> It's even in antimicrobial Q-tips... pretty much it's everywhere it could be used.

<comment><USER10> It's like the high-fructose corn syrup of the personal hygiene world.

</comment></comment></comment><comment><USER11> lol....and I was about to go buy Colgate toothpaste because the tv ads show that it's the only way to fight cavaties and germs efficiently.</comment>


Ask PG: Can We Have An Honest Discussion Around Abusive Flagging On HN? - <AUTHOR>

the below is a screengrab of http://news.ycombinator.com/news pages 1 - 3 (reformatted  for continuous viewing), as of 13:00 EDT on Thursday / 16 May 2013. (highlighting and related commentary added).
i put this together as a high-level and informal analysis of post rank as a function of: time since submission (hours), upvotes (points), and the volume of comments posted. comparisons made relate to the post Google to Microsoft: Remove your YouTube App from the Windows Phone Store https://news.ycombinator.com/item?id=5715168 (shown as highlighted in yellow; near the bottom..)
> http://i.imgur.com/ZCR2hun.jpg
without knowing exactly how rank is determined, the highlighted post's positioning appears to be significantly depressed relative to where it should be, based on examining similar posts (in terms of time since posting, points, and comments).
it has been mentioned that this irregularity is likely due to said post being atypically 'flagged' as spam. i have no data to back this up, but having seen similar behavior before, i believe this to be the case - and it appears to be a fairly common occurrence with posts that present a viewpoint counter to that of the majority. i believe this apparent abuse of the spam 'flagging' feature on HN is seriously detrimental to the community.
i think it would be beneficial if we could: (1) get a statement clarifying rules/good practices around 'flagging' posts, (2) some form of verification that abuse of this feature has been occurring, or evidence contradicting it, and (3) a discussion around potential changes to the system.. i personally believe keeping the feature in-place makes sense, to help deal with actual spam, but would recommend implementing some logic to help mitigate its abuse (such as a upvote/comment threshold that, if achieved, negates the effect of flags). <comment><USER2> For convenience, here's a link to the item in question:

<https://news.ycombinator.com/item?id=5715168>

And here's a history of its ranking, clearly showing flags or other penalizing behavior:

<http://hnrankings.info/5715168/>

I have no skin in this game, I didn't read the item in question, but I am interested in community dynamics.

Now I've had a brief look at it. Speaking purely for myself I find the ensuing thread a deeply unpleasant read. I don't care about the article in question, but I would flag the thread for its unpleasantness. I haven't, I won't, but I can see why others might feel that the entire argument is non-constructive, and that HN would be better off without it.

Just my opinion, of course, which is probably worth as much as you've paid for it.

 _Added in edit: We're recently learned that HN has a flame-war detector. I'd be unsurprised to learn that this tripped it._

<comment> simba-hiiipower ..i think one of the reasons the thread got so toxic was over the (apparently true) allegations that the post was being heavily flagged - and early on.

according to op (of original thread) it appears that the flagging occurred almost immediately, so the argument that some may be flagging due to the toxic nature of the thread doesn't make much sense to me.

<comment><USER2> According to the record of rankings provided above it was over an hour before it got flagged enough to affect its rank.

<comment><AUTHOR> its still odd behaviour.. look at any similar post (in terms of age/activity) and you can clearly see that one stands-out as odd. here's one that looks to follow a more typical progression - <http://hnrankings.info/5719667/>

also from making it near the top [rank 3 / 22:30-22:45] it rapidly fell close to the bottom of the front page [rank 22 / 23:10].. that's a pretty quick decline.

<comment><USER2> This is behavior I've seen before. A rapid rise, staying high in the rankings for a but, then getting a few flags to take it to the bottom of the front page, or the top of the second page. A few more upvotes to get it back on the front page, normal declining with age and/or upvotes intermingled with the occasional flag, then getting hammered.

It's usually on long, unpleasant and angry exchanges that I see this behavior on, and I'm not at all surprised.

</comment></comment></comment></comment></comment><comment><USER3> You say that flagging is only for spam. It isn't. Flagging is for things that don't belong on HN.

Some things are obviously not suitable for HN. Somethings are obviously suitable for HN.

The tricky area is things that start off being suitable for HN, but then quickly collapse into mindless bickering.

There are some words that act as triggers to poor discussion. I proudly flag threads full of bickering. You should too.

<comment><USER4> _"Flagging is for things that don't belong on HN."_

Flagging is for flagging. Things that don't belong on HN are part of it. Redundant articles and bad discussions are others.

Even bad moods are a relevant reason to flag an article. HN is better if flagging is used to express strong emotion than toxic posting.

<comment><USER3> Yes, I agree. I do flag when discussion is toxic.

</comment></comment></comment><comment><USER5> _i believe this apparent abuse of the spam 'flagging' feature on HN is seriously detrimental to the community._

Like DanBC said, flagging is just for spam. And really - "abuse" is just hyperbole, isn't it? And while we're talking about hyperbole, your whole title is just flag-worthy for the dramatics alone.

If, for example, a post gets 447 upvotes, how many flags constitute "flagging abuse" in your mind? For something to get 447 upvotes means that (a) a large portion of the community saw the headline, and (b) a large portion of the community read the article (or at least part). What makes you think that it is "abuse" if a portion of said Group B decided to flag it as "off topic" or "bad journalism" (or whatever - I didn't flag it but, like others have said, I can see how and why some people would)?

You're acting as though flagging should have no weight on ranking. Why not make your case and put up a poll in a new thread? I'd suggest leaving out a fair bit of the dramatics you've created this post with though...

<comment><AUTHOR> from: <http://ycombinator.com/newsguidelines.html>

_If you think something is spam or offtopic, flag it by going to its page and clicking on the "flag" link. (Not all users will see this; there is a karma threshold.) If you flag something, please don't also comment that you did._

..the guidelines clearly specify flagging is for spam or off-topic posts. i generally define 'abuse' as utilizing a feature for something that its not intended for, such as burying a story one does not agree with.

saying its 'off topic' is total bs. issues involving standards, ip, public access, etc.. (also, involving two of the largest tech companies, the mobile space, a popular web-based product, etc...), seem to be very relevant around here and frequently come-up.

so.. this wasn't spam or off-topic, yet shows heavy flag activity. that indicates abuse to me. would 'misuse' be better? - its petty of you to dismiss my point as being 'dramatic'. i attempted to frame the issue as i saw it, using the evidence i was able to scrape-together, and tried to avoid making generalizations or turning it into a 'hn hates microsoft' or whatever as i'm sure this happens often, but this case highlighted it most clearly, and most recently..

<comment><USER5> _its petty of you to dismiss my point as being 'dramatic'._

No, sorry, that's not true. I wasn't the one who judged your original post - the one that was killed (by flagging) within minutes. Those people judged your post as hyperbole/dramatic/whatever you want to call it as well. I'm judging this specific post, however, and it is dramatic both in it's content and certainly in it's language. The title is just silly - "Can we have an _honest_ discussion about _abusive_ flagging on HN?" (italics mine). What other discussion would we have other than an honest one?

"Abusive" is just a word chosen for effect; misuse, while definitely being less dramatic, still implies that the community is doing something wrong. I don't think most of us feel that way. I think most of us old timers flag for different reasons than the newbies. My suspicion is that a lot of the older members (who also have high karma) flagged your original post for the reasons I've mentioned. If I'd seen it, I would've flagged it (as I've flagged this one).

</comment></comment></comment><comment><USER4> HN is statefull. The software manages it with user input. Sometimes HN even gets managed at the REPL.

The system isn't designed to be perfectly fair. It's designed to work, not to be purely functional. Anyway, there is no objective measure of merit for any submission or comment.

As CollinWright says, he would have flagged the thread because of the tenor of the discussion. This is not flagging the article or killing the story. It's taking the discussion off the front page.

</comment><comment><USER6> Most things about Microsoft get flagged off (even a not-very-positive review of the Surface Pro tablet yesterday, which had lots of comments). Most every submission about the Marketplace Fairness Act ('internet sales tax') were also flagged numerous times despite no real bickering in the comments; some people really don't want it discussed at all for some reason.

</comment><comment><AUTHOR> ..i posted this yesterday under a diferent account but it was apparently removed, almost immediately. hopefully the same doesn't happen again.

edit: for convenience, clickable link to image above <http://i.imgur.com/ZCR2hun.jpg>

<comment><USER3> Do you have show dead turned on? Try turning it on and searching for the item. Maybe it got marked as dead. Maybe it just got flagged to death.

Meta stuff is often killed quickly.

<comment><AUTHOR> within a minute or two after posting it disappeared off the 'new' page. not sure what would have been the cause but i don't believe flagging would have caused that.</comment></comment></comment>


Toyota Shares their Manufacturing Secrets, and Why GM Failed to Benefit - <AUTHOR> http://www.thisamericanlife.org/radio-archives/episode/403/nummi

<comment><AUTHOR> What I found really interesting about this story is how it sounds very much like a case study in a failed agile adoption.</comment>


How to make a search engine with crawler? - <AUTHOR> <comment><USER2> You need just login on bubblehunt.com</comment>


Monitor your local network with Raspberry Pi - <AUTHOR> http://rigaspapas.com/blog/monitor-your-local-network-with-raspberry-pi/ <comment><USER2> Meh, this is crap.

1) You need a router that supports DHCP relay, which most home routers do not natively support.

2) It won't show you clients that are connected to the Wifi which is probably the majority of clients in most home networks.

3) It doesn't give you the ability to monitor anything beyond the DHCP lease table which all routers show.

So besides wasting 50$, losing a port on your router and having another thing that might break your network down you aren't getting anything.

<comment><USER3> I think you are being unnecessarily harsh.

There is a need for tools that people can use for monitoring the activity on their home networks. All of these IoT devices are going to create problems that need troubleshooting. Yes, the ideas outlined are simple, but this can evolve over time to solve a problem that is going to be increasingly important

<comment><USER2> The problem it's not a tool that actually monitor activity on the network at all, you are better off getting a router with 3rd party firmware support or a slightly better home router which many even come with SNMP these days.

</comment></comment></comment><comment><USER4> Somehow I expected this talk about real network monitoring like using Ntop, Nagios, arpwatch etc. Just creating another dhcpd for the lan/wifi feels cumbersome just to get dhcp leases.

So how about using RPI as a network bridge between the router and the client hosts and then using Ntop, arpwatch etc. Then you can actually monitor the traffic in detail.

<comment><USER5> I read some sources that Pi is not that fast to route traffic through it.

However, maybe at least setting up DNS server on Pi would get some "live" stats without sacrificing performance ?

<comment><USER4> I would expect that RPI could route normal home lan traffic well enough unless there's some big IO limitations regarding ethernet+usb ethernet. Linux has been used for routing with a lot lower spec HW than RPI or RPI2.

<comment><USER6> I ran a Pi router for awhile, and can confirm that the USB ports are the bottleneck. It was great when I was using it to split traffic between two crappy 3-6Mbit links, but once I finally got hooked up with a decent connection (90Mbit), I quickly hit a 30Mbit-ish ceiling.

<comment><USER4> Sounds plausible. Thanks for the info :)

</comment></comment></comment></comment></comment><comment><USER7> I guess it's interesting as an exercise, but openwrt gives you this and so much more on $30 routers. After years of experimenting with different router firmwares, I can't recommend openwrt enough. It's simply phenomenal.

<comment><USER8> [http://www.dx.com/p/346531](http://www.dx.com/p/346531) seems to be a rather nifty $25 openwrt router

<comment><USER7> I have three OpenWRT devices: a Linksys wrt1900ac (v2), and two TP-Link WDR3600s. Considering that you can pick up the WDR3600 on Amazon for roughly $50, it's a steal. I have multiple vlans configured across all three (which OpenWRT makes very easy to do) and certain SSIDs isolated to certain vlans, even on the same radio. I just set up WDS last night between the two WDR3600s, and it was such a simple process. I have the utmost respect for OpenWRT and what it lets you accomplish. Plus, it's far more professionally-run project than other firmwares like Tomato. If you haven't played with OpenWRT yet, I wholeheartedly suggest you do.

</comment></comment></comment><comment><USER9> "netmask 255.255.255.0"

"We chose to use the range 192.168.1.0/8 as our local network"

Minor typo, although it doesn't really matter in the big picture.

I like how it was written. In line commentary, like a tourist guide or a very informal runbook.

As a meta comment about the project goals it seems almost like a parody of taking something like logging into the CLI and running "arp" and turning it into the largest and most complicated system imaginable, I'm trying to figure out how to make it more complicated, maybe running it on https instead with a valid cert, or perhaps doing it all in Intercal or cobol instead of node.js.

</comment><comment><USER10> You could set up an promiscuous WiFi card and monitor all active WiFi- sessions, the radio signals are still there, readable even if the actual connection/data is encrypted.

We did this at my university to monitor who's in our social activity facilities at any given time (opt-in).

<comment><USER11> That's what I thought this was going to be. A relay DHCP server seems cumbersome.

</comment></comment><comment><USER12> >> Simply because WiFi is managed by the router and most of the routers out there don't provide you with such information or statistics.

I love Pi, and I have my own raspberry pi router project with 3d printed box and everything. But why spend money and an extra ethernet port for information that you can scrape off of your router's http page with something simple like a web testing tool?

<comment><AUTHOR> Just to save time and practice skills. It's faster, since it doesn't require passwords, and more responsive and beautiful, since it uses bootstrap.

</comment></comment><comment><USER13> It's a bit of fun, but you could probably do better with a Mikrotik board (eg: [http://routerboard.com/RB922UAGS-5HPacD](http://routerboard.com/RB922UAGS-5HPacD) list price $79), a low-end microATX board with a few network adaptors - or as others have suggested, a wireless router with something like OpenWrt etc.

</comment><comment><USER14> This is nice way of getting the live device data out from the router - I've made a few scripts in the past for logging into the router web interface and scraping connected device data as a "Who's in the house" display.

Pulling the DHCP functionality out into something more accessible is a great idea!

<comment><USER15> Not for me on FIOS (I have one year left on my contract UGH! but I was told NO Contract sign here I'm a Noob)

I use to have my own DNS on my server for these purposes and could get a text or email whenever my kids started pulling data on wifi (Teenagers who "can't sleep" than I pulled this trick and they were sleeping)

Fios TV must have the DNS going through their crappy router.

</comment></comment><comment><USER16> Would not using openwrt be a better solution I think that reports by client. And I am sure that Cisco Airnet and Ruckus kit does this.

And there are hacker distros for the PI designed for use as an ICE device - ideally you need to have a ethernet tap other wise you need two ports to monitor ethernet.

<comment><USER17> Do you know if this is somehow possible using OpenWRT? Would be great to have a life updating view of all connected Wifi devices including bandwith usage / limit and so on.

<comment><USER18> Of course. You can even send the dhcp logs remotely, to a syllogism server. OpenWRT can do a lot more than that...

</comment></comment></comment><comment><USER19> "By using only your current WiFi router that's surely impossible."

umm, what? I haven't seen a router for a long time that doesn't have that feature.

<comment><USER14> Right - but if you're bolting on a Raspberry Pi, there's no way for it to know "live usage of WiFi" \- only the router knows that

<comment><USER20> I think the point being, why even use the Raspberry Pi in the first place given that most routers (even a lot of consumer ones) maintain a list of currently connected users.

<comment><USER14> Do many routers make that data easily accessible for automated use? From my experience, it requires work to get at that data.

<comment><USER20> It depends on your definition of easily accessible. For example, on my TP-Link W8961N you can use Python's Requests library, Beautiful Soup and HTTP Basic Auth to retrieve and parse the client list.

</comment></comment></comment></comment></comment><comment><USER21> It'd be more interesting to dive into that nodejs snippet. The work to get the final result (a list of connected devices) has already been done and implemented in your home router.

And you swap a real router for a bandwidth constrained raspberry to get that list.

</comment><comment><USER22> Curious - if you click 'Home' you (I) get chucked onto port 2368; the page is also served on 80, but not others (at random) - why is that? Funky load- balancing?

<comment><AUTHOR> Just some rewrite rules to prettify the URL. It's a ghost blog, running in port 2368.

</comment></comment><comment><USER23> You could probably install something like pfsense or untangle and get a whole heck of a lot more tools. Or even dd-wrt. I'm assuming the drivers exist for this.

</comment><comment><USER24> Stopped reading after calling OnHub a game-changer.

</comment><comment><USER25> Just a nminor nitpick, it says you're using 192.168.1.0/8 but your netmask is 255.255.255.0 which would be /24 in CIDR

</comment><comment> jo-m this solution monitors the wifi by sniffing on it (RPi and cheap WiFi dongle):

[https://people.ee.ethz.ch/~muejonat/wifimon/](https://people.ee.ethz.ch/~muejonat/wifimon/)

</comment><comment><USER26> Or use the $15 orange pi clone.</comment>


Show HN: Docker for Mac Kubernetes ingress - <AUTHOR> https://webhookrelay.com/blog/2018/01/08/ingress-with-docker-for-mac/ <comment><AUTHOR> Hello, Webhook Relay founder here. Pretty much all different cloud providers offer different types of load balancers (probably due to their existing, pre- container infrastructure). I believe there is a need to have a simple, cloud- agnostic ingress controller that can be used both in local environment, self- hosted Kubernetes cluster or any existing managed k8s service. Currently I would recommend to use it mostly for development purposes as we sort out any arising problems and add TLS support into the ingress controller itself (so you can define HTTPS hosts in the ingress.yml), however you can already enable HTTPS for your ingresses via CLI or UI.</comment>


Ask HN: Can you review my startup auth2.com - <AUTHOR>

http://auth2.com/
This is about two factor authentication in short. I support voice call, mobile push, phone application for OTP, image id verification and hardware dongle.
The hardware dongle is currenty veru ugly- microcontroller dev board + realtime clock + 7 segment display + battery. I am not sure if I can produce a light weight and low power device cheaply.
I know there are players like google, secureid or smaller ones like duosecurity and few others which are much ahead of me. I am trying to operate at their blind spot like wordpress security for lifetime cost less than 5$ - you buy the app and you never pay again.
I think I have implemented all the basics for now. I think I am done implementing the minimum viable product and will invest time on customer development before writing any more features.
You may watch the demo for most important two features (voice call and mobile push) here http://auth2.com/demo/voice_call/ . I will need to create demo for other features.
Note1 :
If anyone here is seriously interested about two-cator authentication for your website/blog/server/vpn using the prerelease version please request for early access here -
https://auth2.com/reqbeta/
Please mention HN in the comment section.
Note 2: I asked my first ever question ON 43 days ago about the idea with only extremely limited features working.
Thank you for your time. <comment><USER2> First, nice idea. Good to cater to niche market. You could build landing pages for these niche markets. "Secure your Drupal install in 5 minutes."

* The website is a little light on content. Maybe add some example implementations, use cases (in text, not everyone watches movies + good for SEO), FAQ. * Go through your website with a comb for spelling. F.e. on the main page "Two factor" must be "Two-factor". Also fix "You tap to accpept " * The mobile phone icon can use some polish. It looks somewhat like clip-art now. (Hope I don't offend anyone's work!)

</comment><comment><USER3> In think two factor authentication is becoming increasingly important as more and more information is going to the cloud, I'm sure you're in the right way but you'll have to make it work really good if you want to be at the top

</comment><comment><USER4> Please link to your ToS and Privacy Policy on the sign-up page. I had to google to get to your ToS and couldn't find your PP at all.

<comment><AUTHOR> Thanks. I'll add privacy policy. I do not know how to write one, but a compile of a few sites should work initially I guess.</comment></comment>


Top Tech Companies by Talent Over Time - <AUTHOR> https://www.paysa.com/company-rank <comment><AUTHOR> a variant of google pagerank on employee flux and how it changes over time....Expectation Maximization. pretty rad</comment>


Show HN: Simple app to break up larger decisions into many pairwise comparisons - <AUTHOR> https://antgoldbloom.github.io/Pairwise <comment><AUTHOR> I wrote this app to as an excuse to learn React and to help pick a name for the baby we're expecting.

I've since found that I'm using it semi-regularly for other subjective decisions: most recently choosing a holiday destination.

Posting it here in the hope that others also find it useful.</comment>