Hard deadlines are not user-first - <AUTHOR> http://jatins.gitlab.io/me/why-deadline/ <comment><USER2> In my experience when people focus too much on sprint deadlines, they miss the purpose of sprints.

Timed sprints exist not for the benefits of managers, but for the benefit of developers. They exist so that the development team has a shield against managers making last-minute decisions and changing priorities without notice.

If the focus and discussion is regularly on short term deadlines, then the developers are not driving the process, the managers are. It means that sprints are seen as a management methodology and not a development methodology. And then everyone has a hard time.

Managers who think this way know they're not "allowed" to make mid-sprint changes so instead they focus on the end/deadline.

The managers should be spending their energy supporting the team and figuring out what the priorities are for the next sprint(s). If they're spending their mental energy on deadlines then they're doing everyone involved a disservice.

<comment><USER3> Sprints exist so that both management and devs can realize that there is more work than there is time. It forces devs to be focused and scope their work. It forces management to prioritize and scope down as well.

Keeping the deadline of the sprints is supposed to force management and devs to agree on reasonable scopes, such that the output of the dev team becomes predictable with time.

This enables devs to get trusted by management, breaking the poisonous relationship.

<comment><USER4> > This enables devs to get trusted by management

I am curious about that "trust" part. In your model what happens when management doesn't trust devs ? do devs trust management ?

<comment><USER5> Define "trust". As an industry I think we often talk about the wrong things here. People look at this from the point of view of controlling IT & developers (controlling costs, deadlines, functionality, etc.) when really everyone should be looking at it instead from the point of view of maximising value to the business. That's what Agile is really all about - it should really be about trusting that people will make good decisions based on the currently available info (which will likely be different than when you started the project), do good experiments, and find good compromises. This is especially true if unforeseen delays to a team's work has a knock-on effect on other people (which a good manager will try hard to decouple and avoid, deliver incrementally to lower the risk, or at least include healthy contingency for).

IMO, you should only really care about imposing deadlines as an answer to the question "how much time is it worth investing in solving this problem?" If the scope of the solution becomes larger than expected, and it starts to look like it won't pay off, abandon it and start doing something else instead. You had a good experiment which was entered into in good faith based on the data available at the time. That's the nature of experiments. Learn your lessons and try the next one.

Trusting that your teams have good plans that fail early and incorporate fast feedback loops is generally the only real way to make sure that they have realistic scheduling/deadlines for those plans and that they are likely to generate real value. It amazes me how many people in management seem to put their efforts and emphasis mostly on scheduling the plans, rather than the plans themselves. I guess it's easier to come up with estimates for things, than it is to come up with good strategy and business value propositions/justification.

I really recommend reading "A Seat at the Table" by Mark Schwartz (ISBN 9781942788119) for a good exploration of how agile meets management trust issues, budgeting and longer term planning, and how to try to break down the barriers between "IT" and "the business" (when in most modern companies, IT _is_ the business).

<comment><USER4> Very good points.

Reading the comments, I think what I was bugging is the notion that would give a task not trusting it would be done.

People point at micro-management as an effect, because it basically means providing more limited tasks with limited risks.

But I think in the long term the direction we tend to take for people we don't trust is to set penalties (bad evaluations, demoting, firing included).

In that sense, in average there should only be people you trust at the appropriate levels of an org, so I am not sure it is important to focus on gaining trust as it builds up just by doing ones job.

That's where I like your idea of management trusting a plan, more than focusing on the team.

</comment></comment></comment></comment></comment><comment><USER6> >An ideal solution to this would have been to just go talk to the stakeholders - product/sales team - ask them if the delay could be potentially customer losing. And if it is, by all means put in the extra hours, work those weekends.

Strongly disagree, it's not on the shoulders of developers to ensure faulty promises can be kept. I will for sure not sacrifice weekends, this is far from ideal

<comment><USER7> Definitely. That's phase 2 of the world's worst game. Phase 1 being "Please give us an unbiased estimate, but we will yell at you until it's the number we like." Under those conditions, working weekends is just feeding the beast.

I do think it can be ok to work extra hours to seize an unusual opportunity or deal with some truly unexpected problem. (E.g., the destruction of the World Trade Center in 2001 required a lot of tech people to scramble.) But that has to be balanced by something good for the workers and painful for the business, like an equivalent amount time off or significant overtime pay.

But workers shouldn't have to spend their spare time making up for managerial incompetence and malpractice.

<comment><USER8> I like bringing up this barometer the next time I'm asked to work weekends:

"Did a bomb go off in our datacenter? No? It can wait then."

<comment><USER9> I was lucky enough to see management get caught in their bullshit during one of these "hard deadlines" when I was just out of school. They said that December 1st was the deadline and that if we didn't get the release out we would lose millions in revenue. People run around like crazy until the end of November when we realize the EULA document is just a place holder and that Legal has not given us the new EULA. All of a sudden the deadline is mid January when we expect to get the new EULA.

<comment><USER10> What drives me crazy about this is how it shows that some employees are expected to bust their asses to meet deadlines, but others (legal) are not -- oh, if legal won't be done in time, we'll just move the deadline, no problem.

While some people -- healthily or not -- are willing to bust their butts (with or without extra compensation) when they think everyone is in it together, it will generally kill morale and willingness to do such when you realize when _someone else_ 'doesn't have time', the deadline is moved, it's only _you_ expected to work evenings and weekends and extra hours to meet the deadline. Why is your work-life balance less important than theirs exactly? (Only because they can get away with it...)

And while not always as stark as your example, people are often shown this _all the time_ , that not everyone's inconvenience is in fact treated equally, that the "deadline that can't be missed" really only applies to some people, and is moved for others.

</comment></comment></comment></comment></comment><comment><USER11> One thing I've noticed on a lot of teams is that sales/product believes their own hype and overestimates the importance of their software in people's lives. There's this belief that customers/users are waiting impatiently for features when 99% of the time, they're just not. Yes, features _affect_ users, but often users don't know what features are coming, because they just don't care enough to know.

Software I use every day: Firefox, Slack, Vim, MacOS, Python, Bash, GCC, Android, StrongLifts 5x5 App, Gmail, Google Docs, Google Maps, Simple (Banking) App, VLC.

All of these (except maybe Vim?) have released some significant features in the past year. Of these features, I only knew about a few Python features that were coming before they came, and none of them were ones where I was thinking "I can't wait for this to come out! If this doesn't come out soon I'm switching languages!"

On the contrary, features take a long time after they come out for me to learn how to use them and for them to affect my decision making. In fact, my initial reactions to new features are much more likely to be _a liability_ than to be an asset to the software company. I'm considering switching away from Simple because their expenses update doesn't really fit my needs, since as a freelancer I'm not paid on a regular schedule. And I'm _definitely_ switching away from MacOS since their deprecations have broken some tools that are key for me. If they had taken more time, maybe someone would have noticed the problems and avoided them.

Sure, early on things are different: first-to-market advantage is real. But for _most_ of the lifetime of a project, you aren't releasing killer features. You're releasing incremental changes that have a much higher chance of _losing_ you users than of _gaining_ you users (in the short run, at least). Never releasing isn't an option--death by stagnation is a thing--but releases should be done with painstaking attention to detail rather than urgency.

<comment><USER12> This is fairly controversial. Is there any example of a startup that actually made it by employing this strategy?

One of the truisms I've heard and have always followed is you need to release something you're embarrassed about, because that's the quickest way of getting user feedback, and understand if a user actually _wants_ that feature, and if it's actually worth spending time improving that feature.

It's easy to waste valuable capital paying attention to details that the user does not really care about.

EDIT: I've noticed that most of the software you posted here is very well established, most > 10 years. I'd be surprised if any of them follow "agile" by the books.

<comment><USER11> > Is there any example of a startup that actually made it by employing this > strategy?

Is there any example of a startup that actually made it by releasing features that were broken or poorly thought out?

Is there any example of a startup that actually failed because they released features a week or a month after an internal deadline?

Do we have enough insight into the internal strategy of enough companies to make any claims about this at all?

Your argument is basically looking at existing startup culture, but realize that most startups that use a fail fast strategy do exactly that: fail. I'm not saying that's causal: I think success is hard and there's a myriad of reasons why startups fail. But I don't think we can look at the fraction of startups that have succeeded and point to this one element of their strategy and say, "This was a necessary component of their success."

I'm not looking at the whole industry because I don't think there's enough representative data there. I'm looking at my own experience as a user and noticing, "Hey, I actually don't even know what features are planned for _any_ of the software I use, yet I'm still using it. So maybe future features don't have anything to do with why I use software. And maybe other users are similar."

Let me ask you: can you name 5 features that you're looking forward to in the software you use? If those features take a year longer than expected to materialize, do you think you'd switch to a competitor? That's rhetorical: I am sure some HN people can answer those in the affirmative, but I'm also sure that's not the norm.

> One of the truisms I've heard and have always followed is you need to > release something you're embarrassed about, because that's the quickest way > of getting user feedback, and understand if a user actually _wants_ that > feature, and if it's actually worth spending time improving that feature.

Sure, but then you don't know if the user doesn't want the feature because it's not useful, or because it's badly implemented since you didn't spend time to get it right. You're collecting data faster, but you're also confounding the data so that you don't know what it means.

> It's easy to waste valuable capital paying attention to details that the > user does not really care about.

Agreed. One of the details I'm saying the user does not really care about is whether your feature is released today or three months from now.

> EDIT: I've noticed that most of the software you posted here is very well > established, most > 10 years. I'd be surprised if any of them follow "agile" > by the books.

...which is a pretty damning statement about '"agile" by the books'.

I'll say what I've said before many times: the entirety of agile is contained on this page: [https://agilemanifesto.org/](https://agilemanifesto.org/) . "Agile by the books" is an attempt to make money off a successful strategy, but you can't sell six lines of text, so people write books on how they implemented agile, which if you understand agile, is fairly useless for understanding how YOU should implement agile. If you really grok those principles, then it's really clear that releasing early to get user feedback doesn't follow the principles:

 _Individuals and interactions over processes and tools_ The deadline is a process rule that you're prioritizing over literally every individual in this situation.

 _Working software over comprehensive documentation_ Releasing broken software so you can document user response doesn't follow this principle.

 _Customer collaboration over contract negotiation_ Customers should be involved _long_ before you're releasing features.

 _Responding to change over following a plan_ The deadline is the plan. The fact that the feature isn't ready by the deadline is the change that you need to respond to.

<comment><USER13> In my last job we were sufficiently sophisticated users of AWS that we routinely had conversations with product managers to learn if specific features were on the roadmap, and if so, if there was an ETA. We had these conversations because we were debating whether we wanted to write a solution of our own, or if we wanted to wait for a generalized one to be released.

That said, the product managers generally left us with information such as "this is actively being worked on", "this is planned work in the upcoming quarter, but it could change", "this is on the roadmap without a date", and "this is not on the roadmap". No specific dates promised, but it was still good enough for our purposes.

I hope they weren't using our requests to push for specific dates, internally.

</comment></comment></comment></comment><comment><USER14> There are 2 normal ways to do things: work until you achieve the functionality you want and release it when that happens or work until an arbitrary date and release whatever you have at that point. Surprisingly, as a developer I always prefer the latter. As a coworker of mine if fond of saying, the time you know the most about the project is when you are finished. The time when you know the least is when you are starting.

By choosing to release "whatever we can do" at a certain time it encourages you to make difficult prioritisation decisions as the "deadline" approaches. Are we _really_ OK with releasing with just this functionality? Maybe we should axe X and replace it with Y since we don't look like we are going to get both. Maybe Z is an even better compromise that we didn't realise was an option at the beginning of the project.

If you try to hit functionality, it allows the organisation to avoid rethinking its planning decisions. We aren't releasing until the ideas we had 6 months ago are _all_ implemented exactly as we envisioned it back then. By the way, why is it taking so long?

Of course trying to hit both at the same time is just a recipe for disaster.

<comment><USER15> Exactly this, and what a lot of less senior developers don't understand is that the fixed timeline is actually a defensive mechanism for the development team. If the date is fixed the functionality has to be variable and the best people to assess what fits or not is the development team who thus can be in control of their own planning.

<comment><USER16> No, for many managers the fact that the deadline is fixed means they can death march you for all the functionality they decide needs to be complete at that date.

The idea that adding additional process to manage your managers is laughable at best.

<comment><USER17> Manager can't hold your fingers and force you to type code. Agile's short sprints mean that managers learn in 4 weeks instead 16 that death marches don't work. Managers can be managed as much or little as reports are.

<comment><USER16> I know currently of several companies being managed into the dirt by people who dont learn no matter the scheduling mechanism or level of machiavellian maneuvering by their employees.

So no, you cant manage your boss, you can inform them, maneuver them, help them, cajole them; but at the end of the day you cant get them to change their behavior if they truly don't want to(and they can just fire you for being too annoying.)

<comment><USER18> In the current environment one can get away with a lot of push-back because managers with any fraction of a clue know if they piss you off too much you'll be giving them your notice, new job in hand, in a few weeks, if not days. That won't last—which is why if we're going to organize for better leverage against abuse in bad times, now'd be the time to do it, but I guess enough people've been convinced unions will impoverish them that we're not gonna, maybe next boom, see y'all then—but for now it's pretty nice.

</comment></comment></comment></comment></comment></comment><comment><USER19> At Pivotal, I learned that having sprints is silly. They have the concept of one week iterations instead. The PM just keeps a rolling backlog of stories and devs just pick the next one off the top. Dev's are responsible for pointing the stories and the sum of those points averaged over time (usually 2-3 weeks) become velocity.

Just keep the velocity as consistent as possible and things work out for the best. If the PM wants a story moved up the list, then they can see how much work will fit into an iteration and how it will affect schedules.

All of this is managed in their homegrown, but publicly available tool called Pivotal Tracker. You can read the website documentation for a more thorough explanation. Once I learned this methodology and started practicing it like a religion, deadlines went away and PM's could estimate due dates many weeks in advance. It was a life changing experience that I highly recommend at least giving a shot at your own workplace.

<comment><USER20> Hi, PM here. I ditched scrum long time ago with the team and setup 1 week cycles. We meet on monday, to kick off and see results at friday. We managed to keep executable development cycles, so from my part, i tend to ask for less every single weekend because that's how I get most of the results, and keep moving. In the end, it's better than seeing results every 2 weeks and some major results in a month or so. I preffer to move quickly, and iterate those "mini-sprints" in case one went wrong.

<comment><USER21> This sounds like Scrum with one week sprints.

<comment><USER20> we don't do retrospectives, groomings, estimation of stories, etc.

</comment></comment></comment></comment><comment><USER22> I find being transparent with my team makes it a lot easier. There are internal deadlines and external deadlines. Former are internal ones which have no real consequence if missed and just keep a development rhythm (e.g. weekly iteration, monthly release, quarterly roadmap update catchup etc...).

The other type comes from third parties, generally, such as clients or the board. Once you separate these two types of deadlines, I find my engineers more understanding about having to meet external ones whereas blurring internal and external into one "deadline" simply causes people to either burnout or lose faith in management because everything is marked as urgent.

<comment><USER23> I've found most deadlines I've worked with to be internal. The only exceptions to that however was legislation dates; Cookie walls and GDPR, new laws for stock trading on an European level (forgot the name), things like that. These are things for which your company can be fined heavily for. Other deadlines are likely to be of the "we'll start earning money later" variety.

<comment><USER24> Those are BS as well. No one is going to fine company on day 1 of a new law. GDPR was effective 25 may 2018 but companies still had half of a year to implement it.

Basically if you prove you are working on it I bet they will let you off the hook.

</comment></comment></comment><comment><USER25> I think Agile is the heart of the problem. It is a cargo cult that brings predictability to software projects by ensuring that it's always a dumpster fire, that everyone's stressed, and that everything takes longer than estimated. Eating up "tickets" and crapping out code is not how you quickly deliver software to customers and iterate in the face of changing needs. It's so sad there are generations of developers being raised thinking "Agile" and playing absurd, time-wasting games with "issues" is how to build software. Agile is to the 2020s what the Bobs in "Office Space" was to 2000: "Trendy" corporate management absurdity and fury signifying nothing.

The alternative to Agile is Software Engineering, where you do important things like assess your requirements and capabilities, identify how to validate those requirements are functioning properly and support your business requirements, promote testing and QA to a first-class citizen. Most importantly to always have functioning software that is reasonably demonstrated to be correct. That way you release with confidence, people take pride in their work, and the product, team, and schedule all become quite pleasant.

<comment><USER26> Engineering-first culture is almost always the wrong idea. It's product-first or nothing. The entire point of agile is prioritization based on business value. Everything always takes longer than estimated regardless of how you manage your project. That's actually a core tenet of agile and one that stakeholders (and budget holders) have the hardest time accepting. Having worked in this industry before agile was prevalent, I can assure you it was never better than this in the past. QA as first-class is a pretty core principle as well. The point of things like Scrum is meant to be visibility and alignment rather than prediction, but impatient people are guaranteed to ruin your life no matter what.

<comment><USER27> I'm sure I don't have the wealth of experience you fine people have. But I've been in enough teams and companies to see that whatever methodology is being embraced, it seemed like the X factor was always what kind of people are practicing it. If someone likes always being in meetings, you're going to be in a lot of meetings. If you're on a team with smart people you enjoy working with, with open lines of communication, then the rest just seems to fall into place as long as everyone is doing their job.

Then again I never worked for Hooli.

<comment><USER26> Yeah, this is actually my same observation. High-functioning teams were naturally agile even before it was called that. Defining and formalizing agile practices is a way for people who've never experienced it to know what success looks like.

</comment></comment></comment></comment><comment><USER28> > So the developer, being a developer, pulls a couple all nighters, maybe > works over the weekend and does get it done.

And does minimal testing, skips documentation, adds some tech debt, copies- and-pastes code rather than doing proper code reuse - because the deadline is the only thing thing being measured.

</comment><comment><USER29> At the company I work for, our yearly performance reviews are based partially on the metric "Complete 90% of uninterrupted development sprints with no carry over." What I see most of the time, is developers hurrying towards the end of the sprint to meet this arbitrary deadline, choosing the easiest path A instead of the correct path B. Now the project has been run like this for years, you can imagine how much tech debt has accumulated.

<comment><USER30> This is a good example of Godhart's Law ("When a measure becomes a target, it ceases to be a good measure") in action.

There are better ways, but it requires enlightened management.

<comment><USER30> Sorry for the typo: it's _Goodhart 's_ Law, not Godhart.

</comment></comment></comment><comment><USER31> I think pretty much everybody is missing an important point of deadlines: money. If you are not done by the deadline you are dead. Management (with marketing) has a good idea of what will sell, fail to make the deadline and the product won't make money in the market and should be canceled early. This is the point of estimates: to decide early if the project is worth paying anyone to work on. (or course once you are part way in the project sunk costs become an issue)

Note a result of this is deadlines are not something you should come close to: a break-even project isn't worth your time to develop, so there should be plenty of slack in the schedule to cut into before hitting the point of no profit.

<comment><USER28> > to decide early if the project is worth paying anyone to work on.

Yes, we know that's what you think. We keep trying to explain to you that you're living in a fantasy world where software development can be predicted accurately in significantly less time than it takes to just do the work. I understand why you WANT that to be true, but wanting something to be true doesn't make it true, to the frustration of MBAs all over the world.

<comment><USER18> I do think well-functioning development processes & teams, with good integration with business is something every company wants, but very few companies are willing to pay for, and most just _cannot accept_ that they're opting out of what they claim they want by not paying enough, so they try to get it anyway.

Why's it expensive? I think people who are capable of building and managing such teams, and dragging organizations into a set of processes that truly work, exist at a rate of about 1/1000 the demand for them. Meanwhile the people who can discern useful practices from useless ones or good implementation from bad are similarly rare and overlap largely with that same group, leading to an ecosystem of development practices that's almost entirely snake oil and wishful thinking, and where almost no-one can tell when they're looking at one of those 1/1000 folks who've got the knowledge and skills to make it work if you give them the authority, or some delusional schmuck or huckster.

The best most companies can do is to learn to live with a ton of uncertainty and work humanely and effectively with that, and few achieve even this lesser outcome, which tends to come with its own (lower) costs in hours and less- than-ideal predictability that many orgs just _can 't_ accept they _have to_ pay to keep things running even sort-of smoothly.

</comment></comment></comment><comment><USER32> > just go talk to the stakeholders - product/sales team - ask them if the > delay could be potentially customer losing

In my experience, sales team rarely have any incentive to help out here. They almost always say that delay will create problems and they quantify in terms of dollars e.g. If X is not done by this date we will lose Y dollars. That Y number is almost made up to make things more urgent.

Actually, I have seen sales blaming lack of sales numbers on engineering because the delivery was "too" late.

<comment><USER33> Agile works well when you're working in a win win kinda relationship. What you describe happens more often than I am willing to admit.

What helps here is if you hold Business Value meetings with real people involved and try to reason relative priorities of stories. This is the fuzzy, social aspect of Agile development but I suspect it's really the core idea behind the whole thing: it forces people to talk in person and empathize more, hopefully building up cooperative relationships rather than extractive ones.

If the stakeholders continue to be sociopaths though, you can either chose to give in and do whatever they say or lie. Both options break the spirit of the thing. Frequently there's a 3rd invisible option where you use back channels to pull some influence. Which also defeats the purpose of Agile...

</comment></comment><comment><USER34> There is a fundamental relationship between schedule duration, amount of work and quality.

If estimates were all accurate, then the amount of work and the sprint duration would be the same. It inevitably takes more work than estimated, so something has to give.

If you constrain the duration and the scope of work, then quality will vary. If you constrain the duration and allow overtime, then you get a mini crunch time every two weeks. Some bosses think that people will slack off unless they are given pressure, so they like this situation.

A better way is Kanban. It's more or less Scrum where quality is the thing that's fixed. If the task is going to make more time than originally estimated, either you let it take more time or reduce the size of the feature, i.e. implement a simpler version of it.

<comment><USER28> > If estimates were all accurate

then every level of management between the devs up to the CEO could be replaced with a spreadsheet.

</comment></comment><comment><USER35> This is what Steve Jobs has to say about project managers: [https://youtu.be/rQKis2Cfpeo?t=116](https://youtu.be/rQKis2Cfpeo?t=116)

<comment><USER36> Well that hits home pretty hard. I didn't know Steve Jobs did these kinds of interviews, thanks.

<comment><USER35> Another gem: Steve Jobs on sales and marketing, [https://youtu.be/-AxZofbMGpM?t=21](https://youtu.be/-AxZofbMGpM?t=21)

</comment></comment></comment><comment><USER37> Talking to "product managers", managers and various stakeholders everyday, the problem is at the times when these otherwise good people are disconnected to the rest of the organization and have no operational clue. Then they will demand deadlines, push dates backwards, do all sort of non-intentional self- sabotage to the org. They might get their thing done, badly, while hurting the rest of the organization and creating unhealthy competition. When goals are accomplished, they often are unable to even get the value out of the thing they wanted in the first place. These same people won't be able to prioritize when given the choice, and basically just want it all now, again like little toddlers, with checklists!

So what do you do? Only healthy thing is to push back, give explanations for what is required before work can begin and have good relationships with all parts of the org yourself. Insulate the toddlers. If they need a PM, they gotta provide a budget.

</comment><comment><USER38> > We'd still be doing MVC in frontend apps if someone at Facebook didn't miss > a deadline.

After working with React for some tine I'm not so sure the good old Mvc is a bad thing, not always at least.

<comment><USER39> That line stuck out for me too.

Is MVC as a pattern really all that bad for the majority of web apps?

<comment><USER38> I think it depends on what kind of code mess you prefer - client side or backend. I personally prefer to mess up on the backend, feels much more comfortable to me to fix it up and write tests.

</comment></comment></comment><comment><USER40> deadlines exists because managers believe that the team will focus to accomplish the goal. the reality is that _most_ managers are lousy at estimating the amount of time a given task takes and _most_ developers are cowards to stand up to a manager and tell them this. _everyone_ sucks when it comes for planning for the unexpected. in the end, all deadlines do is cause unnecessary stress and disappointment for _everyone_ involved.

i'm no different and have been caught up in this game more times than i can count, yes, i suck too. later in life i've come to determine, that whatever deadline i have in my head, i just extended by a factor of 2.5. if i think it will take a month, i say two and half months. that is more than enough time to not only get the project done, but also deal with anything that crops up unexpectedly. my serenity is worth more to me than looking good or being a hero.

<comment><USER5> IME, if the manager is primarily coming up with the estimates, rather than the team, you're doing it wrong. (And are doomed to an eternal cycle of blame, stress and lack of trust.)

<comment><USER28> You don't know how this game works. Of course the devs come up with the _initial_ estimates - they have to, or else it wouldn't be possible to blame them when they end up delivering "late". But those initial estimates are always "negotiated down" to whatever looks best on the manager's quarterly bonus review - they might not be brilliant at designing products or scheduling, but they're geniuses when it comes to re-stating things so that they sound different but are actually the same until you finally get tired of arguing with them (I mean, it's tricky to argue with somebody who decides whether you get paid or not) and agree to whatever they say and just disappoint them later.

<comment><USER5> We tend to try to do any vaguely longer term/important estimation as a team exercise, which ends up with people talking each other's estimates up, not down - you explore the problem space more effectively as a team and a lot of "but what about X" stuff comes out of the woodwork then.

If you have a manager who sets your team up for pressure and failure by artificially revising your estimates down, without cutting the scope of the work, then personally, I would find a new manager. Source: Am a manager.

</comment></comment></comment></comment><comment><USER41> I have been struggling with scope creep for deadlines at my work, I am a junior dev and I have a product owner that means well but changes requirements several times and increases scope mid sprint. How do you push back against this in a nice and reasonable manner?

<comment><USER28> There's an old saying: "people will forget what you said, people will forget what you did, but people will never forget how you made them feel." It's supposed to be inspirational, but it's actually depressing because it's so accurate. How do you put it into action as a dev? Never argue. Ever. If you argue, you'll lose the argument anyway (you have no power), and they'll just remember you as the person who was argumentative. If they say, "can you add AI to this product by Friday?" You say, "yeah, sure, let me look into that." In a sane, rational, just world, everybody would be working together on a shared, common vision, and they'd realize that by giving you herculean tasks with impossible deadlines that nobody could achieve they're actually hurting themselves as much as (if not more) than they're hurting you, but the grim reality is that that isn't the world we live in. If they add scope, just shrug and accept it. Don't kill yourself with nights and weekends trying to meet their deadlines either - just say, unapologetically, "I was able to do ___ and I'm still working on ___".

</comment></comment><comment><USER42> > " There is another problem with locking your sprints. Say you get a new > customer ask, it's a potentially trivial but low priority bug. The developer > could fix it in a day. But you follow The Process TM, the task gets added to > your team's backlog, maybe gets picked couple sprints down the line and does > get fixed. But you lost the opportunity to delight the user!"

Nope. That context switching will cost you more on average than sticking to the process. And most often you'll be wrong about the time estimate, or the customer will be wrong about actually wanting that feature, etc., making the context switch even worse and more costly.

</comment><comment><USER43> I tend to take a fairly dynamic approach to design.

In many cases; especially where you have heterogenous projects, done by multi- disciplinary teams, dated milestones are pretty much required. You have to have some thing, by some time. I worked like that for many years, as part of massive, multi-national teams.

But these days, I have the "luxury" of generally working alone, or as a member of a casual open-source team that doesn't have any specific deliverable deadlines.

What I do, is define what "done" looks like, and set some very fuzzy milestones. At each of these inflection points, I reexamine the work I'm doing. In some cases, I decide to bin the whole effort, and either rewrite it, or simply scrag it, and move on to the next in the FIFO. In other cases (less often than I'd like), I am ahead of expected schedule, or the functionality of my work is better than expected. Boo-Ya. Go Me.

The important thing for me, is that I have a solid idea of a deliverable. It may not be associated with a date, and may be subject to revision, but it exists. At some point, the project needs to be released.

That may require some compromises, and it will require some tedium, like signing and provisioning, as well as producing marketing copy and graphic assets. That's part of what you need to do to have shrink-wrapped releases.

A lot of times, I can put off some of the sexier stuff for a 1.1 release.

</comment><comment><USER44> The essay is just a long winded way of saying the quote from Eisenhower: "Plans are worthless, but planning is essential"

Which is of course a short winded way of saying that the article makes a lot of sense. We for example have sprint goals - these are things that the team commits to actually getting done during the sprint. Then there are tasks in the sprint which may or may not overlap with the sprint goals and may or may not get done during the sprint.

It's always about trade-offs.

</comment><comment><USER45> Reading HN comments makes it sound like engineers think they're the only ones in a company who have to deal with deadlines. It's kind of hilarious. Go ask your sales team how they cope with hard deadlines of closing a specific dollar amount every quarter based on the presupposition that 1. the product delivers what it says without major issues, 2. competitors don't come out with feature or pricing changes that blindside you, 3. other departments (marketing) delivering them enough interested contacts to talk to... and 100 other things. Not to mention the main "stakeholder" in play for them -- the customer -- is ACTIVELY trying to deceive the salesperson in order to get the best deal for themselves. Like, they will literally lie and say they intend to sign a contract with you by end of quarter to get the salesperson to go the extra mile for them. With zero intention of actually following through... Yet the sales team gets it done every quarter. And if they don't? 2 bad quarters in a row = expectation is you're out of a job.

<comment><USER46> I don't think the main point being made is that deadlines are a PITA, I think it's that the trade-off is unmeasured. Successfully meeting a sales deadline looks the same as signing the same contract after the deadline (other than the deadline), but the argument for deadlines in software being bad is that they materially erode quality and long term viability (shortcuts, tech debt, bugs, usability). The product delivered within the deadline is materially worse than the one delivered after. The problem is that it's hard to attribute these issues to "deadlines" although the intuition is that they are a major cause.

<comment><USER45> > Successfully meeting a sales deadline looks the same as signing the same > contract after the deadline (other than the deadline)

This is so far from the truth. I encourage you to spend more time with your sales team and even your stakeholders who are buying $100k+ software from vendors. There are so many parameters of a deal that go beyond contract signature date. Deliverables, SLAs, roadmap commitments, length of contract, legal definitions, opt-out conditions, payment terms, pricing, and more. Deals aren't just "on time" or not, they vary greatly in terms of quality. And that quality largely determines your company's ability to hire more engineers. Or fire them. ;-)

Bad deals happen when you're down to the wire and have to get it done on time or people will lose their jobs. Not unlike bad software. Work in the real world has deadlines. The people doing the work will always advocate for the loosest deadlines (or none at all, as is often the case with engineers). The people who need the work done will always advocate for the fastest turnaround. Without these checks and balances, the work just does not get done fast enough or well enough to stay competitive.

</comment></comment></comment><comment><USER47> The post is solid on criticising sprint deadlines, but doesn't give many suggestions on what works better. Except for this:

> Another idea is to experiment with more elaborate probabilistic ways of > setting shipping estimates rather than gut based estimates.

In my experience, teams setting estimates and holding _themselves_ accountable is a great way to go with multiple benefits. This is why I'm a big fan on estimating software projects with a few ground rules [1].

Sprints and deadlines could be a tool to get here - as with a bunch of things, context, people and culture matter just as much as processes do.

Iterating and learning from iterations is how good software is produced, with a team that is motivated and continuously growing.

[1] [https://blog.pragmaticengineer.com/yes-you-should- estimate/](https://blog.pragmaticengineer.com/yes-you-should-estimate/)

<comment><USER48> One estimation method I found good and worked at a risky project in my job (involved a regulator, they love deadlines) was:

1\. Do the usual breakdown of tasks and point game to get relative difficulty estimates

2\. Calculate the std dev points for each task instead of just averaging. The assumption is that this is valuable information about how uncertain developers are about the task, so we don't want to throw it away.

3\. Create happy-path and worst-case scenarios considering +-1sigma and +-2sigma

4\. Prioritize tasks by deviation, to remove the most uncertainties at the beginning of the project

With this you start w/ a more realistic view of the uncertainty of the project, and it's supposed to converge to the avg as the project goes.

</comment></comment><comment><USER49> Deadlines are for managers. If developers need to be aware of the deadlines then the managers are not doing their job.

<comment><USER22> I don't quite agree here, developers need to have an idea of what they're working to so they can manage their own implementation time. If you don't make developers aware, you put too much control in the manager's hand which isn't a good thing here (unless you're referring to a developer lead but even then, individual developers should have an idea of when they need to complete by).

</comment></comment><comment><USER50> Out of all of the factors that could potentially cause poor software (along with the "software disenchantment" as discussed in another recent thread), deadlines stand out as the most concrete and immediate driver of the decisions I take that may result in poor software quality. At least it's the one I can consciously acknowledge as influencing me more than once.

I'll have to improve my efficiency at developing software anyway, but this article has given me more confidence that I can pace the promises I give to my clients as to when features will be delivered.

</comment><comment><USER51> This article has beef with artificially imposed internal deadlines, not deadlines in general.

A deadline can be for a ton of legitimate reasons, like delivering a signed contract by the agreed upon date.

</comment><comment><USER52> The only deadline I set are for customers. That is either internal customer because they asked can it be done by x day and I either answered yes or no. Or an external customer because I got on a phone call or someone in sales/support indicated an opportunity or at risk customer.

Ok fine and sometimes I set deadlines because I'm like OMFG how have we not done this yet. Let's get it done by x day. For example upgrading framework x to latest version y

</comment><comment><USER53> What was so wrong with the author's chosen article title that it had to be manually sanitized? I get that HN admins may not like the snark, but it's the author's title, it's his snark, his tone, his article, and by sanitizing the title, you are basically making an editorial decision on his article.

<comment><USER54> The HN guidelines call for changing titles that are misleading or baity. That one was baity, so we replaced it with representative language from the article body.

Generally we err on the side of preserving articles' original titles and favoring authors above everyone else! But not when the title breaks that guideline.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment><comment><USER55> If it weren't for deadlines I would never do anything, pretty sure I'm not the only one.

</comment><comment><USER56> This goes for external (outgoing deadlines) as well as for internal. When you don't tell the world to expect exactly this on THIS day, they won't be unhappy. They'll simply be happy when it happens - and happens correctly!

</comment><comment><USER33> This is a very well written article. TLDR: don't be too steadfast with sprint deadlines, keep them fuzzy and understand how missing them will impact stakeholders before committing to working over the weekend to meet them.

Many Scrum Fanatics, especially the ones holding various Certifications, will scream bloody murder at the idea of tampering with their precious sprint. But the sprint is a fucking artificial construct that was meant to be fuzzy. If it isn't good at representing how software is delivered you can either change the sprint or try to force your team to sync with it.

Unfortunately I've seen the agile processes be misused in many ways because it's inherently so fuzzy and ill defined. It doesn't really make much sense to bikeshed over minutiae but to focus on the outcomes and tinker liberally with the process to suit your teams style. Just keep your stakeholders informed of the changes.

</comment><comment><USER57> Well, they are user-first... _if_ you look at humans as resources and managers as users.

</comment><comment><USER58> Part of me wonders if the Author works for Amazon, because that sounds totally like Amazon.

</comment><comment><USER59> I don't want to criticize but you spell critic wrong on the first period: "crtitic"

Pun intented.

</comment><comment><USER60> I've done a lot of scrum like projects in the past 15 years. I say scrum like, because absolutely nobody does it "by the book". And if you do, you are doing it wrong because you are being rigid and dogmatic. Every agile manifesto signee will tell you that (I've heard several of them talk about this). I meet a lot of "you are doing it wrong" types. You know the type. Self styled agilists that throw the book at you and seem to love having lots of post its stuck on their walls that provide the illusion of progress in the absence of exactly that.

These days, I prefer Kanban style processes for several reasons. Most importantly, the practice of ignoring new requirements for two weeks (aka. doing a sprint) is not sustainable in most projects I'm on. It's just not a thing. Stuff changes all the time, deal with it now instead of in two weeks. Another reason is that I prefer continuous deployment and automating PM reviews away so we don't block shipping stuff over somebody's opinion. Sprint deadlines are utterly meaningless from a release point of view if you release multiple times per day. If it's better than what we have then merge and ship it ASAP. If it's obviously broken, obviously fix it now ASAP and don't wait to have a meeting about it in 2 weeks. Do that multiple times per day. Have responsible processes to ensure bad stuff gets caught before it is merged. It works. Shipping early means you catch stuff early and get feedback from real users rather than opinionated PMs and managers detached from reality. Also people stop throwing things over the fence when they are confronted with the consequences of what they did right away. It forces them to think end to end, a quality that I find is often missing with engineers because they are being shielded by layers of management.

Finally, I work with remote developers a lot these days. Anything involving telcos or meetings is downright painful; especially if you add language and cultural barriers. Having full day scrum ceremonial crap is just not something I have a lot of patience for. Doing that over a hangouts meeting is just an exercise in futility.

Kanban of course does not stop you from having regular planning meetings, estimation sessions, retrospectives, etc. All that can still work and if it adds value to your team, by all means keep on doing that. IMHO it makes less sense in distributed teams and those require more asynchronous approaches. I find decoupling what we do from when we do it in a Kanban style to be helpful. If the backlog is getting too short, add more stuff and add it in the priority you want things fixed. Don't allow your team to lose focus (aka. multi task) and set concrete goals. Have breakout meetings when things need clarification. Don't pile on too much work in too much detail until it is ready to get done. Doing CD means you can specify changes in terms of what you have in production and how you want things changed. I find that injects a sense of reality that just stops a lot of BS. from ever happening.

</comment><comment><USER61> More 4 year to make Mickey Mouse public domain or the law extent the period again.</comment>


Profit Sharing - <AUTHOR>

If you were given the following options for remuneration - which would you pick?<p>(1) Hourly Rate $70; no profit sharing<p>(2) Hourly Rate $60; 1% of net revenue; capped at $20,000 per year<p>(3) Hourly Rate $50; 2.25% of net revenue; capped at $50,000 per year<p>(4) Hourly Rate $40; 5% of net revenue; capped at $80,000 per year<p>Also, the hourly rate bumps up to $70 automatically once there is $1.5M of cumulative revenues. <comment><USER2> Honestly this depends on the company because its a question of confidence. Do you have confidence that the company will be generating real revenues and how bad to you need the money.

If you have a family and need to have guaranteed income at set levels, then you should be conservative and pick option 1.

But, to put it in perspective. To see what the back-of-the-napkin calc is for the maximun annual total income.

1\. 140k no matter what 2\. 140k Max (60 x 2 = 120k plus the max 20K) This option sucks balls. 3\. 150k Max (50 x 2 = 100k plus the max 50k) 4\. 160k</comment>


Flappy Bird Clone Code Injected into Super Mario World for SNES by Hand - <AUTHOR> https://www.youtube.com/watch?v=hB6eY73sLV0&feature=youtu.be&a <comment><USER2> This really deserves more attention. Insanely cool hack - the "by Hand" means using the Nintendo game controller to move sprites in such a to inject processor instructions into Super Mario World via glitches in the game</comment>


Design better databases - <AUTHOR> https://web.archive.org/web/20160408103107/http://dbpatterns.com/ <comment><USER2> The original URL was [http://dbpatterns.com/](http://dbpatterns.com/), which no longer points to the right content, so we replaced it with the closest archive.org copy of the original.

</comment><comment><USER3> Tip for SQL users:

If you give all your ID fields unique names, e.g. by calling your field "reservation_id" instead of "id", even in the reservation table, you can do stuff like:

SELECT * FROM reservation JOIN guest USING (reservation_id);

By doing "USING (reservation_id)" instead of "ON reservation.id = guest.reservation_id", the field will be automatically deduplicated, so you don't have to qualify it elsewhere in the query, and "SELECT *" will return only one copy.

<comment><USER4> It's long bothered me that SQL doesn't have a way of saying "join these two tables based on the key relationships I've already defined in my schema". (Or maybe some variants do?)

The database already knows that guest.reservation_id is a foreign key referencing reservation.id. Why should you have to repeat yourself?

<comment><USER5> And when there are multiple foreign keys between two tables?

<comment><USER6> Genuinely curious, what's the use-case for this?

<comment><USER7> Some examples:

In project management, tasks might have an assigner_id and assignee_id

In transaction management, transactions might have a sender_id and receiver_id

In sports, matches might have a team1_id and team2_id

<comment><USER8> > In transaction management, transactions might have a sender_id and > receiver_id

in normal form, shouldn't you have "transactions", "transaction_senders", and "transaction_receivers" anyway? similarly for the other cases?

i know sometimes the simplicity of a single table is a valid choice, so your point still stands, but it does feel like the examples are cases of "well, if you're were doing _the right way_ (TM), that wouldn't happen"

<comment><USER9> _shouldn 't you have "transactions", "transaction_senders", and "transaction_receivers"_

 _were doing the right way(TM), that wouldn 't happen_

Having a separate transaction_senders and transaction_receivers wouldn't be _the right way(TM)_ unless it's possible to have multiple senders/receivers. If a transaction can only have 1 sender/receiver then normalization is complete when the sender/receiver data is removed from 'transactions' table and replaced with the sender_id and receiver_id columns.

When introducing transaction_senders/transaction_receivers tables without further constraints, it would be immediately possible to have multiple transaction senders and multiple transaction receivers for a single transaction, which is likely an error.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> It's an old-looking website, but I've found this site has some really cool data models: [http://www.databaseanswers.org/data_models/index.htm](http://www.databaseanswers.org/data_models/index.htm)

As someone in the healthcare space, looking at some of these models gives me a better idea of how various aspects of the healthcare industry work, and the things they interact with. Ex) [http://www.databaseanswers.org/data_models/patient_data_ware...](http://www.databaseanswers.org/data_models/patient_data_warehouse/index.htm)

<comment><USER11> those models are actually pretty bad

the ones in these books are better:

[https://dba.stackexchange.com/questions/12991/ready-to- use-d...](https://dba.stackexchange.com/questions/12991/ready-to-use-database- models-example/23831#23831)

<comment><USER12> This strikes me as a very unhelpful comment. Why are they bad? Why are the ones in these books better?

<comment><USER13> The site (databaseanswers) is neat and I've gotten some good ideas from it in the past, but most of the models (that I've looked at anyway) are pretty simple and you almost really wouldn't need to look at a diagram drawn by somebody else to intuitively put something like that together. It seems almost more for someone creating MS Access level applications. Granted there may be some more complex schemas that I didn't see.

There might be an argument about excessive normalization in some cases also. Take some of those layouts too far and try to extend them and you might wind up with tons of little tables. Normalization was I think more important back in those days (not that it's not still important... but some of the downsides of going overboard on normalization have become apparent I think.... at least to me).

</comment></comment></comment></comment><comment><USER14> I just clicked on the second "featured" pattern and found this hot mess:

[http://dbpatterns.com/documents/5091f74289cbad03bc958bc0/](http://dbpatterns.com/documents/5091f74289cbad03bc958bc0/)

It has the "let's put a UUID on every row" disease common to designers who have never really learned anything other than object oriented design. Price is a string (I guess so you can put "market price" on the fish?), and there's a currency symbol on every "delivery". The whole thing just makes no sense. 18 stars. Unbelievable.

<comment><USER15> I'm daft. What's wrong with using uuids as primary keys everywhere? I'd appreciate it if you could elaborate :)

<comment><USER16> The problem is that most uuids are generated in a way that, when sorted alphabetically as strings, would have a random order.

Example: t0: 7458e3a9-716b-4352-b2e4-b5b67d0c089b t1: 4d8d753c-1777-439d-8725-b093b1bd8430

Using this as a PK in any relational database will mean the rows are stored in the clustered index order, which causes extreme fragmentation because the db engine constantly has to find "holes" in the data pages to insert more recent records instead of adding those at the bottom of the table as would happen with any continuously increasing key.

<comment><USER17> This is a non-issue. Most db engines just append new data rows at the end of the data table and assign an internal row ID for it. The keys (UUID in this case) are stored in the separate index pages using B+ tree, which searches random key (UUID) or sequentially incremented key equally well.

UUID key is a problem only if your main query is a range query on the PK of a clustered indexed table. If your main query is a range query, you should pick something that can be sorted in the range anyway.

<comment><USER18> Actually only postgresql does it this way (by storing data in the heap and not in the primary index). Mysql(innodb),mssql,oracle uses the store the row in the primary-key.

Edit: I'm ~wrong, see below.

<comment><USER17> Only Innodb does it by default. The others use heap table by default.

MSSQL allows clustered indexed table as an option to order the physical storage of rows. Oracle has index-organized table as an option.

Edit: They don't use clustered indexed table by default because record insertion is very expensive since clustered index forces the table to store the records contiguously in the index's order. Also Innodb is not truely clustered indexed. It only stores records contiguously for one page at the B+ Tree leaf level. Records in different pages are scattered all over even if the index values are sequential.

</comment></comment></comment></comment></comment></comment><comment><USER19> Kinda misleading title. Doesn't really have anything to do with database design. It has to do with sharing Entity-Relationship diagrams. Maybe "Design better relational models".

</comment><comment><USER20> If anyone is interested, there is a 2-volume set of books called "The Data Model Resource Book". They've been around for a while, so for more traditional businesses, but very thorough and broken out by industry:

[http://www.wiley.com/WileyCDA/WileyTitle/productCd-047138023...](http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471380237.html)

[http://www.wiley.com/WileyCDA/WileyTitle/productCd-047135348...](http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471353485.html)

<comment><USER21> +1. Definitely worth reading, I have Vols 1 & 2 (Vol 3 came out later). I found it useful because the author explained the decisions about the models and traps to avoid.

<comment><USER22> > because the author explained the decisions

By far one of the most useful things a resource can do.

It doesn't just broaden your understanding of a domain, but it _can teach you how to think_ about design problems.

</comment></comment></comment><comment><USER23> More of an ER modeler than a database designer. The interface is pretty slick/simple. Here's a sample I just cooked up: [http://dbpatterns.com/documents/570699101514b428de8893a1](http://dbpatterns.com/documents/570699101514b428de8893a1)

I can't imagine using it for anything real but it was fun to play with.

If the creator is reading this, here's a bug report: If the user hasn't hit "Save" when they export the schema, they get an empty text file and they'll think the app is broken. It should either auto-save or prompt the user " _You have unsaved content, do you want to save before exporting?_ "

UPDATE: One more bug report, the export doesn't escape the columns names at all. It just naively adds double quotes around them. This breaks with double quotes in field names ( _yeah yeah which is stupid but still.._ ):

        CREATE TABLE "foo" (
    	"id" int,
    	"baz" varchar(255),
    	"bar" varchar(255),
    	""test"" varchar(255)
        );

<comment><USER24> I found the interface very off-putting. If this is a site about exploring data models, a "public feed" and "search" is not a great way to interact with those. In fact, a timeline chronology of when these things were made seems a great way to expose mostly irrelevant information to a large number of users.

How do I browse these models? Is there a taxonomy of organization? How many models are in the system? Are there models relevant to general domains of interest to me? None of this is made apparent.

<comment><USER25> I think they're aiming at the "jsfiddle" field. I.e. Sharing ERDs and such over SO and other social sites. As opposed to them trying to be some sort of comprehensive database of standardized DB patterns.

</comment></comment></comment><comment><USER26> Y'know I really miss designing relational schemas. As much as I hate SQL the language I love the relational model that it is a (butchered and ugly and compromised) implementation of. But working where I do on the systems I do now this is something I never have to deal with anymore.

There's something very therapeutic about organizing data using a system of rules, and the relational data model is a powerful one.

<comment><USER27> Completely agree with you. I have always hoped that some of the GUI modelers would allow you to add notes/explanations on tables & relations, explaining the motivation behind design decisions. Example, "M2M relation here allows us to 'tag' objects with multiple attributes".

</comment></comment><comment><USER28> Looking around I see lots of people just blindly using UUIDs for everything. At a prior job, I had a boss who forced me to use UUIDs for everything, before we had even collected a single row of data.

It hurts my pragmatism to solve a distributed systems problem before we even had a distributed system! Don't be a sheep and use UUIDs, rather than a simple integer primary key or composite key that is natural to the table. People say it's just an id, who cares? But I say people making these kinds of decisions are probably making other poor choices backed by something they read and don't understand.

Here's a great article on locality and the need for uniqueness and why UUIDs should only be introduced when needed and to solve very specific distributed systems problems. The reality is almost all applications will never need to have multiple concurrent writers.

[https://eager.io/blog/how-long-does-an-id-need-to- be/?hn](https://eager.io/blog/how-long-does-an-id-need-to-be/?hn)

<comment><USER29> I barely ever use uuids. As you say, it solves a fairly specific problem. Usually when you need to scale to multiple datacenters, it's easier and faster to add a datacenter column and starting using it with id as a composite key.

The only time I use UUIDs is when I need to pass that id out, but I want to hidr how many rows there are or the rate that they are being created. However, I usually use COMBs to prevent fragmentation.

</comment></comment><comment><USER30> I built an electron app that allows you to design, generate, and share Mongoose Schemas if anyone finds it useful: [http://mongomulch.com](http://mongomulch.com)

</comment><comment><USER31> These schemas seem like pretty simple, straightforward adaptations of specific problems. This doesn't actually look like any sort of actionable advice on how to design better schemas. Are we supposed to just osmose the knowledge somehow? I was expecting something more along the lines of recommendations like "foreign key relationships should always be indexed, nobody ever came up with a realistic example where they shouldn't! Why the hell isn't this the default behavior?"

</comment><comment><USER32> Interesting idea but it the way it is currently done isn't that great.

Most of the patterns I've seen are obvious simple things but they are missing a lot of content like : \- What was the design's intended properties? \- Expected volumes, access patterns? \- Good places for indices? Maybe the comments could be of some help but really haven't seen much. I've actually found more interesting content in the HN comments than on the site itself.

</comment><comment><USER33> I don't think this must be called "patterns" in computer science patterns are a model applied to give solutions to recurring problems. I was expecting something like Martin Fowler Patterns-Enterprise-Application-Architecture but for databases.

This should be called something like database designs.

<comment><USER34> So what you're saying is that "design patterns" should only be for code, not for data?

If you apply some recipe to structure code, that's a "design pattern"; if we apply some recipe for structuring data, it's a "data(base) design"?

But code is data. But sometimes it's not clear whether something is code or data, or whether it's closer to being code than to data.

Design patterns incorporate data. The Observer pattern requires a list of observers that are notified; that is a data structure which we can have in a database: an observer table joined to an event source by event source ID.

If I make such a database (say for a large number of users to set up persistent notifications about some interesting interesting things), am I doing "database design" or implementing the Observer pattern? :)

</comment></comment><comment><USER35> One of the keys to understanding SQL, and on that note, I would highly recommend SQLZoo's interactive tutorial that allows someone to query a (fake) database and progress using baby steps: [http://sqlzoo.net](http://sqlzoo.net)

</comment><comment><USER36> Cool website, for off the shelf models. For anything more advanced you should be careful, as modeling real world scenarios is rarely so abstract and mamy times you need to make some scenario-specific tradeoffs during the modeling phase to fulfill your requirements.

</comment><comment><USER37> Looks like they're trying to create a repo of open source DB schemas for domains. That's putting the cart before the horse in my mind. People don't start with DB schemas when building domains, they end up with DB schemas after modelling them.

</comment><comment><USER38> Had a quick look through, don't understand what audience this is targeted towards.

</comment><comment><USER39> I like this site. As simple as it is, it has a lot of potential community- wise.

\- it could allow sql exports for various platforms \- it could feature an API so people can write their own framework drivers (for example creating migrations, importing existing schemas etc)

Lets hope that it gains users, so that the voting system (the star) can become more useful to filter out the garbage.

Edit: please remove the login wall to see the starred items, it raises the entry barrier quite a bit. Do you really want new visitors to see low rated schemas as the first thing?

</comment><comment><USER40> As a database guy this makes me feel good. From looking at a lot of these schemas, my job is not going to disappear anytime soon...

Most egregious example for me is probably the prevalence of a lot of "type" tables when a simple enum column would do. Or maybe the sheer number of UUIDs that are being thrown around.

I even saw a circular ID chain in one. Would be fun setting up foreign key constraints for that!

</comment><comment><USER41> Most of these seem extremely simple. I would like to see some examples where a good database schema isn't so obvious.

</comment><comment><USER42> When looking at an author, I can see all of their patterns. This one, in particular, has a pattern that was forked 13 times: [http://dbpatterns.com/accounts/profile/thaichor/](http://dbpatterns.com/accounts/profile/thaichor/)

How do you see the forks?

</comment><comment><USER43> Was wondering how difficult is to code a UI like this? i.e. SVG with draggable boxes with the connections/lines?

</comment><comment><USER44> Wow, that's really cool! Would be nice to have a "migration" export format for Rails, Knex.js, etc.

</comment><comment><USER45> I was bored, so here is a quickly thrown together generic "thing" DB model: [http://dbpatterns.com/documents/5706a53c1514b428de88940c](http://dbpatterns.com/documents/5706a53c1514b428de88940c)

</comment><comment><USER46> I like it, I think there's a real use case for it. I spent quite some time looking for examples on how to create an schema for an activity based workflow webapp.

</comment><comment><USER47> An empty schema diagram is to a data modeler what a blank canvas is to an artist or a blank page to a writer - thrilling but somewhat intimidating.

</comment><comment><USER48> I thought about the similar idea to create domain models to elaborate business rules with UML ORD rather than database ERD.

</comment><comment><USER49> The search function doesn't seem to be working - I can't get it to return results ever.

</comment><comment><USER50> Seems like a big playground...

</comment><comment><USER51> wow. doing my first real data model. tough to find resources like this, started literally resterday. can't wait to check this out

</comment><comment><USER52> Kinda cool but the UX really needs some re-thinking.

Simple things like dialogs getting stacked on top of each other, using `prompt("...")` sometimes and modals other times, foreign key relationship arrows not indicating cardinality, etc --

Looks good but please don't consider it "finished" yet.

</comment><comment><USER53> > Public Newsfeed

> jnichols created new pattern

> Penis

> 24 seconds ago

Ok... maybe they need to start with some patterns about filtering spam and noise.</comment>


The Cleopatra's Nose of 1914 - <AUTHOR> https://www.laphamsquarterly.org/scandal/cleopatras-nose-1914 <comment><USER2> For 3'000 years, the role of women in producing armed conflict has been measured in Helens[1]. (For instance, Silvercorp's filibuster, had it had any involvement of someone without a Y chromosome, would have been rated at 2 milliHelens.)

More seriously, Lewis Fry Richardson argued that statistically[2] speaking, "deadly quarrels" over the period he studied followed a Poisson distribution, suggesting that even if we believe God doesn't play dice, a null hypothesis might be that Ares does.

[1] "Argive Helen, lovely-haired / May I inquire discreetly / When are you free to take some hemp with me?"

[2] [https://en.wikipedia.org/wiki/Lewis_Fry_Richardson#Mathemati...](https://en.wikipedia.org/wiki/Lewis_Fry_Richardson#Mathematical_analysis_of_war)

<comment><USER3> And here I thought it was Samuel Butler who came up with the millihelen as a measure of beauty.

And as Herodotus says, Nobody ever went to war over a kidnapped girl.

<comment><USER2> I have no etymology, I'd thought the Helen was folklore, along with furlongs/fortnight. (or, in common use, the acre-foot, an aggresively non- cubical volume measure.)

Thanks for the Herodotus! I wonder if that was part of Plato's beef with Homer, for taking the artistic line (as Romeo, or Shakespeare's Antony does) of "hos before bros" when everyone knows the conservative ideal is the opposite?

<comment><USER3> Homer a) does not hide the bitterness and brutality of life and death, b) takes a very earthy view of the gods, and this is what Plato/Socrates chiefly complains of in The Republic. If Achilles's shade tells Odysseus that he'd rather be alive as a hired hand that dead as a star among the shades, it does not contribute to troop morale. If Zeus and Hera are stepping out for a quickie, that just isn't dignified.

I think Butler invented the "milliherm" for male appearance.

<comment><USER2> The milliherm, evoking the mutilation of the herms? Would a millicybele then be the measure of trans pulchritude?

Zeus and Hera stepping out _together_ for a quickie at least sounds more dignified than Zeus' usual attempts to pull. Having been a god before the pill, no wonder they call him the "sky father."

κανόνας ΛʹΔʹ: if it exists, Zeus has used it as a disguise to smash mortals.

"Holding the line" has (outside of protest contexts?) become far less important since the invention of rifling. We have a national hero, Winkelried, who famously sacrificed himself to open a hole in the opposing polearm line. This leads to the schooltime question: "What were Winkelried's last words?"

The answer the teacher is looking for is "take care of my wife and children." Among students, the answer is "Melonfarmer! Who the flip pushed m-- aaaarrrrrggghhhh--"

[https://en.wikipedia.org/wiki/Arnold_von_Winkelried#/media/F...](https://en.wikipedia.org/wiki/Arnold_von_Winkelried#/media/File:Winkelried_at_Sempach.jpg)</comment></comment></comment></comment></comment>


Apply HN: OrderTrip – Crowdsourcing local people as private tour guide - <AUTHOR> https://www.ordertrip.com/
Lets travelers crowdsource locals as tour guides. Travelers can post their itineraries and budgets on OrderTrip and a list of locals willing to help them are provided. Travelers then choose their guides and they pay for the guide after their tour is completed.
Instead of travelers choosing from a prescribed list of guides, the guides choose them. This helps ensure the person leading them around is familiar with what travelers want to see and do versus a tour guide who must show several spots along an itinerary but doesn't have deep knowledge of that one spot a traveler really wants to know more about. Paying after the tour is over always offers an extra level of comfort too. <comment><USER2> I like the idea of "anyone can be a tour guide" as a gig economy company. But my experience is that professional, fulltime guides are much better guides within the arguments you made. Specially about deep knowledge about specific spots. What made you think otherwise?

Your benefits look much more like group tour vs personal tour (not pro guide vs local guide). Wouldnt this be your value proposition?

And assuming you have a local, personal guide and people want it. How do you train these guides? How do ensure their quality?

<comment><AUTHOR> First of all, thank you for your comment and feedback. I appreciate it.

> But my experience is that professional, fulltime guides are much better > guides within the arguments you made. Especially about deep knowledge about > specific spots. What made you think otherwise?

Giving just the general knowledge of placs is less value because travelers can get information through google or Wikipedia.

What if a professor of History can be a guide, what if food blogger became a guide. These "nerd" people (positive meaning) can be a really good guide for some travelers.

I am sure they can have deeper knowledge. Moreover, you will get as many offers as possible from locals so that you can pick up the best guide.

Moreover, we are considering that the value of guide is not only deep knowledge. The guide's profile such as personality, job background, and interests are also important.

I don't remember "Guide" but people who I met and have great conversations. We believe that it is the main value.

In terms of value proposition, generally group tour vs personal tour but narrower value proposition is pro guide vs local guide. Moreover reservation vs crowdsourcing. Nobody does crowdsourcing personal local tour guide.

> How do you train these guides? How do ensure their quality?

At the beginning, we have to define what is the quality of guides for travelers.

I don't think giving knowledge is not main quality (or value) on our website. As I said, I believe that type of guide is less value these day. We will not train guides but advise them just to be polite and on time. I would like guide to show their own knowledge and perspective and traveler will review it.

Sorry for bad writing. I have to code Thank you again for your comment.

</comment></comment><comment><USER3> You most probably have decent chance with just being "AirBnB of tour guides" where Tour Guides are hosts and travelers visiting the town are guests. Like AirBnB, host guide showcases his preferred tourist spots in listing and traveler decide whether to book them. The quality is maintained through mutual reviews. You take a cut from traveler's payment and transfer rest to guide. The travelers pays in advance to you, a comfort to guide about no-shows and need to overbook.

Keep it a simple straightforward, easy to understand system. A decent extension to AirBnB lodging business and most probably your exit strategy.

</comment><comment><USER4> Some cities (Washington DC, Philadelphia, New York, New Orleans, etc) have licensing and testing requirements for tour guides. Will you verify tour guides are licensed, if required? Exclude those cities? Disrupt?

</comment><comment><USER5> I have a friend that have an app that does something similar, the name is PartyWith a local

So I have help him research for similars and found this.

couch surfing, TravelMate, tournative.com, toursbylocals.com, moneysense, toursbylocals.com.

What I found is that families seem more willing to pay for a service like this, than young.

</comment><comment><USER6> I think something like this is needed, but I question the need for an actual tour guide.

What if I wanted to go to Vancouver and I wanted a walking tour with some great food and drinks, with some idle time spent at a couple parks or walking around a museum? That's a pretty typical ask and something I'd gladly pay $10 for in order to just get a list of things to visit in a sensible order (so I can just walk along a set path from place to place). As a local of Vancouver I could create my own "poutine, cocktails, and parks" guide, post it, and get some commission every time its sold.

How will you recruit guides?

</comment><comment> d--b This is a good idea, however you will have crazy safety problems here. What would prevent your "guide" to fake stumbling upon pickpockets or worse. I surely wouldn't hire anyone who is not certified one way or another.

</comment><comment><USER7> How do you make money? What prevents the local contact travelers privately, bypassing your platform?

<comment><AUTHOR> > How do you make money? We will take a commission model like Airbnb.

> What prevents the local contact travelers privately, bypassing your > platform?

We will scan the part of messages such as URL and Email not to navigate the other URL. However, reviews and tour guide records are more important to get reliability and customers for them. If they navigate to their own website or contact privately, they can not use review system which means they have not done any tour guide previously. Obviously, we need to consider more the way to prevent the situation like this.

Thank you for your comment, yanglang.

</comment></comment><comment><USER8> Hey! I'd love to sign up as a tour guide. Can I?

</comment><comment><USER9> Have you looked at vayable.com?</comment>


How I lost 3 jobs in 2 weeks - <AUTHOR> http://ravish-writes.blogspot.com/2015/05/how-i-lost-3-jobs-in-2-weeks.html

<comment><USER2> I disagree with the writer's conclusion that one should't mention other interviews or other offers. In my most recent search (after a layoff), my best leads were two companies who'd gotten in touch while I had been with my former company. One came in with a low offer, which I declined--they countered with a higher one. That was also followed up by the other company coming up with a higher offer. I told the first company about it, and they ended up exceeding the other offer.

My experience may have differed from the author's because of how I presented the situation. He says, "So I told both of them that I had other offers and they must give me a revised and a better offer." That reads a bit smug to me. The way I said it was, "I'd like to work with you guys, but I'm looking at an offer from (other company) that's $X higher. How can we make this work?" I mentioned some concerns and reservations I had about the other, what I liked about each, and they came up enough to make a difference.

I didn't ask the other company to counter--I think that I would have worn out both companies' patience and probably had the same result the author had. In the end, money was important, but fit was also important, and if one of them had been a clearly bad fit, this process wouldn't have been productive.</comment>