The Escapist Lays Off Majority of Staff - <AUTHOR> http://www.gamerevolution.com/news/352707-escapist-lays-off-majority-staff-members-mass-exodus <comment><USER2> I still remember the launch of The Escapist. It was so different with its styling and content, sort of an online version of the Edge magazine. Alas that didn't last long.

<comment><USER3> It was odd to watch them do a hard turn from applying more thoughtful analysis of games and gaming culture to hopping on the GamerGate train. I assume that didn't pan out for them as they'd hoped.

<comment><USER4> Oh, so that's what happened to them.

I recall seeing some really good content from them a while back, but it never was _quite_ good enough that I'd go there explicitly to check them out. Then without really realizing it, I stopped seeing links to their content, and sort of forgot they'd ever existed.

Some quick googling shows why: They'd gone totally off the deep end. What a baffling way for them to end. I wonder if it was just a (very ill-advised) tactic to try and boost traffic, or if the owner/editors were actually true believers?

</comment></comment></comment><comment><USER5> There's really just been Yahtzee left for quite some time, glad they made it more official.

<comment><USER6> Reminder that Something Awful could have had Yahtzee / Zero Punctuation and remained somewhat relevant, but Lowtax gave him an insultingly low offer amounting to something like $40 in forum credit per episode.

<comment><USER7> I don't think Lowtax or SomethingAwful did much after Lowtax had his brains punched into mush by Uwe Boll.

<comment><USER8> The strength of SA isn't their public content, it's the community and the forum. But if you do want their public content, I find that the main important output is LPs.

</comment></comment></comment></comment><comment><USER9> There seems to be a serious contraction going on right now with the mass media surrounding games, and I'm alright with it. We're heavily saturated right now with an echo chamber of websites that parrot each other endlessly about video games, game culture, streamers and their various screwups, etc.

I think this has been a long time coming, it sucks that we're probably going to lose some cool names in the process but overall I think it will be a good thing.

<comment><USER10> As far as I can tell, games "journalism" has been a cesspool of corruption and wink-wink kickbacks since the "old" E3.

Semi-professional reporters w/ unsustainable income streams + large studio advertising budgets + massive investments in AAA games != recipe for integrity

Steam refunds did more for game quality than most of the game journalism industry.

<comment><USER11> Rock Paper Shotgun[1] is really good for the most part, co-founded by the writer of The New Games Journalism[2]. Their reviews don't have explicit ratings, which neatly sidesteps the fooforaw over giving things the "wrong" rating. They're on GamerGate's hit list (because somebody's girlfriend allegedly slept with one of their writers), which is another point in their favor. They're PC-specific, though.

Any other good gaming sites out there I should check out?

[1] [https://www.rockpapershotgun.com/](https://www.rockpapershotgun.com/) [2] [http://gillen.cream.org/wordpress_html/assorted- essays/the-n...](http://gillen.cream.org/wordpress_html/assorted-essays/the- new-games-journalism/)

<comment><USER12> I think Nathan Grayson writing about his friends is pretty well established at this point: [http://www.deepfreeze.it/journo.php?j=nathan_grayson](http://www.deepfreeze.it/journo.php?j=nathan_grayson)

Although he now writes for Kotaku, not RPS.

techraptor.com and nichegamer.com are pretty good.

<comment><USER11> > _I think Nathan Grayson writing about his friends is pretty well established > at this > point:[http://www.deepfreeze.it/journo.php?j=nathan_grayson](http://www.deepfreeze.it/journo.php?j=nathan_grayson) > _

That's...alarmingly obsessive. The article, I mean, not Grayson.

<comment><USER13> That's kind of the failure of Deepfreeze - GG wanted to prove that their claims about journos held water, but when they provided and standardized their data it's so off-putting and clinical that it's hard to not dismiss as a little creepy.

<comment><USER14> The GGers who genuinely thought it was about ethics in journalism were completely missing the point though. I want you to imagine we were talking the defence industry. Imagine it was public knowledge that billions of dollars were being skimmed by defence contractors. Then imagine someone shows up and says "Hey, this guy's been telling people to go to gun store A and getting $20 store vouchers." Then imagine that turned out not to be the case.

Now, here's the point: you could spend the next year meticulously documenting every last store voucher the guy had ever received from gun shops B to Z and still no-one would care, because everyone knows that, even if it was true, it wouldn't make a blind bit of difference in the grand scheme of things. If you then announced that this was part of a larger campaign for "Clarity in Defense Spending" people would conclude that either a) you were truly clueless or b) you had an axe to grind with this guy that was nothing to do with gun store vouchers.

Anyway, that's what people mean when they say "It was never about ethics in computer game journalism."

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> I suspect in part this had to do with them losing some of the early series that brought people to the site and not finding any good replacements. I mean yes, Zero Punctuation is still based there. But stuff like Extra Credits isn't, nor is the Jimquisition or MovieBob or god knows how many other past series.

Nowadays, popular web series like that bring in more interest than written articles do. Alas, they didn't quite find a new golden goose after some of their original ones left, so they ended up with Yahtzee as the only real attraction there.

Probably also doesn't help that gaming news sites aren't the moneymaker they used to be, with the people that visit them generally not paying for subscriptions or clicking on ads.

<comment><USER16> [http://www.escapistmagazine.com/videos/galleries](http://www.escapistmagazine.com/videos/galleries) has some of their discontinued series (ex rhymedown spectacular, I hit it with my axe, and unskippable).

</comment></comment><comment><USER17> That would be an expulsion, not an exodus. "Exodus" would imply they all chose to leave.

<comment><USER18> They just all suddenly left* one day.

* After we stopped paying them and took away their access.

<comment><USER19> Your asterisked comment is the whole point.

It wasn't the staff all choosing to leave, it was the staff being told to leave. That'd be two very different stories, which is why 'exodus' would be misleading.

<comment><USER20> Pretty sure that was the point of the comment. You read it too literally.</comment></comment></comment></comment>


Ask HN: What are your thoughts on wikis? - <AUTHOR> My startup is working on a better wiki, and I thought I'd ask the Hacker News crowd what their feelings were on wikis.
Do wikis have a place in your company? How are you using wikis in your company? What software are you using right now? What do you like about it? What are your problems with it?
Any sort of opinions you can give would be very helpful, thank you! <comment><USER2> My experience with Wikis are that are only religiously updated by 1-2 people. Everyone else just kind of goes meh. But you absolutely have to document things somewhere that is shared for the bus scenario.

My requirements for a wiki:

1) Awesome search. Xwiki has a very good search, including in attached documents

2) Fine grained access controls. I need to be able to have a space W with pages X,Y,Z, and Z needs to be public, but nothing else.

3) I need to able to use my existing authentication systems.

4) It needs to be user friendly. XWiki has some serious usability problems for anyone who hasn't used a wiki before. Confluence is a bit nicer.

My nice to haves:

* Site-based documentation. Sometimes I have a workflow that's 80% similar, but the exact steps depends on the site (Example: ssh to this host, run these commands). I don't feel that it justifies having a separate page for each site when the content is mostly the same.

* Editable from my Linux environment, preferably via command line

* OneNote integration

I've used mediawiki, xwiki, twiki, and confluence before.

If you can provide me with most of the things above, and either the source code, or a service SLA (or both), I'd probably buy.

</comment><comment><USER3> We use wiki from earliest stage as a repository for all sorts of information. We don't go out of our way to get fancy it, though, so we don't need a lot of advanced/refined functionality.

I've been through this cycle a few times, this time we are using MediaWiki. I don't remember what we used last time, I think it was a Drupal-based wiki.

None of them made a whole lot of impression on me either good or bad.

I agree w/the other posters that this is a pretty ambitious goal ("better wiki") - I'm like a lot of other folks in that what is out there is more than enough and we probably don't even exercise 10% of the features.

I also agree w/the other poster that said "people don't bother". Very true, stuff usually doesn't end up in wiki unless I put it there or I ask somebody else to do so. Very few people will do this habitually without a lot of strong and recurring encouragement.

</comment><comment><USER4> Just about all of the available Wikis suck really badly. The built wiki in FogBugz is OK and I think Wiki Server in OS X Lion is quite well done but will never get traction outside EDU. (I also worked with the Apple Wiki Server team for a bit so I am biased)

Meadiawiki, pbwiki and Confluence are at the top of my list of wikis with really poor usability. I think the WYSIWYG editors are in most need of fixing (Write your own - if you can't do this you should not be building wiki software) followed by tracking changes and linking of documents together in a manner that allow you to easily track groups of interesting docs without being overwhelmed by updates after a certain point.

The last thing the world needs is more poorly done wiki software so aim high :-)

</comment><comment><USER5> An internal wiki is very useful when the team grows larger than 5 or 6 people.

Before that, it's just a lot of effort to maintain compared to the benefit that arises from it.

EDIT: But I personally wouldn't pay your company for wiki software unless it is _seriously_ good. There is a lot of free wiki software that is good enough. Also, for non-technical users, an internal wiki will be less useful. It only works when people are interested in editing it, and in my experience that is pretty much only technical people.

</comment><comment><USER6> The wiki we have now (mediawiki) isn't easy enough for the layman, and isn't integrated enough for them to be comfortable with it.

Internally, the dev teams and the IT staff use the wiki, but externally everyone uses Microsoft OneNote and there is no way for us to possibly convince them that a wiki would ever be better.

OneNote seems sort of like a wiki for the masses, and I think if you could create wiki software that is as easy for lay people to use as OneNote, you would have yourself a marketable product.

</comment><comment><USER7> <http://wardcunningham.github.com/>

I think Ward's Smallest Federated Wiki is an interesting direction to go, and should really be taken seriously.

</comment><comment><USER8> How are you going to make money from a wiki when there are so many FOSS alternatives in the market?

</comment><comment><USER9> If it's not Wikipedia, don't bother. Wiki's suck both for "project documentation" and for internal company use.

For one, it assumes multiple people want to edit it. People don't bother.</comment>


France can now (legally) veto all acquisitions by foreign companies - <AUTHOR> http://www.rudebaguette.com/2014/05/16/frances-latest-decree-allows-government-veto-international-acquisitions/ <comment><USER2> That's really great. It wasn't enough that they made all French start-ups that ever took money from a government source tainted, now they do it to _all_ French start-ups.

This is a real pity. France has a ton of talented people and a fairly unique view on the web and online services dating back all the way to minitel.

What once was a leadership position has been eroded over the years into a real-world fight for survival. With 'help' like this from the French government the fight is all but lost, why on earth would a French person or team with a good or even great idea for a start-up found that business in France when they could just as easily do it in any other EU country without the risk of having an exit blocked?

What an absolutely dumb move.

The Daily Motion affair should have had the opposite effect.</comment>


20-something Coding Geeks - <AUTHOR> http://www.bloomberg.com/news/2013-11-19/coding-geeks-can-t-save-obamacare.html

<comment><USER2> There seems to be a theme that when people criticize Computer Science fold, they like to mention that they aren't really knowledgeable in Networking concepts or other concepts that fit quite nicely into the land of 'Systems Administration'. Can we please stop with that? Two different disciplines, and while one is useful to the other, it's not practical to study Computer™. There is simply too much.</comment>


Ask HN: Would you mind being monitored at work? - <AUTHOR> I look for a remote software developer position and a potential employer say they require to install special software to track working hours and automatically take periodic screen shots. Logically, they have the right to do it and I'm fine with live pair programming, but emotionally such close monitoring is repulsive to me.
Normally, when I code, I google a lot (for documentation, samples and best practices), apply many iterations to shape the code to the final production ready form and take pauses to think. I'm afraid this process will look awful to a review manager.
Am I hypersensitive? Are my working habits normal for a seasoned software developer? Are you monitored at work? <comment><USER2> I don't care if anyone at work sees what I'm doing at any given moment as I use my work laptop for work, barely even read HN or reddit. Even with that if it was required that my laptop had monitoring sw as mentioned, I would immediately work elsewhere. I'm a professional and won't work were I'm not treated as such. It's also a sign of bad management and leadership that will get worse rather than better.

<comment><USER3> "It's also a sign"

This. It is never the case that this one terrible idea was the sole outlier from an otherwise brilliant and empathetic leadership team.

</comment></comment><comment><USER4> I would never work for a company that requires me to install spyware to take screenshots of my computer screen. It's Orwellian and any organizations that require it should be shamed and boycotted.

On a personal note, there are plenty of companies that don't do this, so I'm sure you can find a position that doesn't require it.

<comment><USER5> Most companies (Big companies) do that. You even not aware of it. They have pre installed softwares for this kind of shit. Monitoring your traffic and taking screenshot is common.

</comment></comment><comment><USER6> No, absolutely not. Trust goes both ways, and if a company cannot trust me to use my time appropriately, then I cannot trust them to provide an adequate environment for me to perform my job. This is doubly-important for remote work, as you're relying on the company to adapt to its employees and the environment they work in.

</comment><comment><USER7> > Logically, they have the right to do it

Says who? Please let's not start thinking that this kind of silly absurdities are logical or acceptable. What's next, random monitoring to identify wronthink?

</comment><comment><USER8> As a developer you are already monitored, every line of code you write or change or delete is tracked. So it is already possible to see how much you get done.

No, you are not hypersensitive. I don't wanna know how much else is wrong with a company like that.

<comment><USER9> Not disagreeing with you but I might add, pauses are also a part of the process. We (developers) aren't typists.

<comment><USER10> Yes, pauses and breaks can _increase_ productivity so this company's intrusive monitoring is probably doing the opposite of what it intends. As long as the break isn't from an external interrupt.

Note: Self-monitoring that's not shared with employer is a different story.

</comment></comment></comment><comment><USER11> Just look for another job, don't even waste a single second of your life considering that offer. I worked for a company that would allow us working from home some days a week, and we even had some remote colleagues. At some point, our manager made us install one of those applications, which denoted he didn't trust us anymore. The app worked exactly as you say, and it was frustrating and infuriating at the same time. It would "measure" your productivity based on the mouse and keyboard activity, giving ridiculous results like a 20% or 30% of effective time worked. Surely a monkey banging on the keyboard would have a much better score, but that's not what developers get paid for. Not only so, but I had the perception that the app had a special preference for taking screenshots when I was on Slack or writing an email, which feels like an utter violation of privacy. Obviously, most of us either left the company or refused to use the tracking software. Be conscious of the value you can provide and look for someone that judges your work by your output, not by the number of keystrokes you do a day.

</comment><comment><USER12> If you can afford it I would forego this employer and look elsewhere for a place where they measure your performance based on what you deliver.

Your repulsion is showing your moral compass points to 'Not okay' for this type of monitoring. Accepting it would influence the way you work, make you feel uncomfortable, self-conscious being watched.

Imho this type of surveillance should not become the norm, and we should resist submitting ourselves to it, whenever we can.

</comment><comment><USER13> Its a trust issue. It probably means that said employer lacks management skills.

<comment> bjelkeman-again I haven't hired anyone as a developer remotely who I don't trust to get in with the work, in other words I would not remote monitor nor would I work for someone who did.

I think they may lack management skills, but also lack skills in managing remote workers in general. This could well be a condition put in by a non dev manager.

</comment></comment><comment><USER14> Such a job (unless your situation is dire) is not recommended. I know of one such company, won't name it here, but such companies I think are one big scam. They will put a camera in front of you and record every moment. Cut salary if you are away for even a few minutes! Google is your friend and as expected such companies will insert a few moles to write good reviews about them as well!!!

There are way too many good remote companies who will treat you good and pay you great. Getting into them is hard as remote jobs are competed for by a larger pool of candidates.

If you are planning to switch into remote, please do a deep dive (unsolicited advice) :-) and then decide. Good luck!

</comment><comment><USER15> Hello OP. I would like to point out that the otherwise diverse and critical community of HN did something unprecedented and never before witnessed - everyone agrees.

</comment><comment><USER16> That would be an immediate deal breaker for me. There would be no discussion about it. Judge me on my output, but I decide how I work.

</comment><comment><USER17> Absolutely not. In fact, I would make it my life's mission to name and shame that company into the ground.

<comment><USER18> uh... wow

</comment></comment><comment><USER19> This can be more of a symptom of lack of trust in remote workers. I'm fine with a mostly-on live camera if you're working with a team that isn't remote and need to bridge that gap.

However, screenshots and software monitoring is a step too far for me personally.

</comment><comment><USER20> What the actual fuck.

Why are you even considering such a position?

</comment><comment><USER21> I would mind it. As long as I deliver, they shouldn't care when and how long I work.

</comment><comment><USER22> Yes, I would mind. A lot. You aren't hypersensitive. Run and don't even think about it twice.</comment>


Ask HN: Better tools for the software requirements / scoping phase? - <AUTHOR> Many software projects seem fail or go over-budget from poorly defined or changing specifications. It seems we have excellent tools to manage the delivery of software, but less so at the design/scoping phase. What are your thoughts of using better tools that leverage, say, Domain Driven Design or BDD (Behaviour Driven Development) that would engage end-users early on? <comment><USER2> The underlying assumption with requirements is often not stated explicitly: that people _can know_ everything in detail, in advance.

If that is the case, surely we can find better ways to uncover the requirements, and better tooling will help solve the problem.

Experience tells me that people don't know everything beforehand. Thus the key assumption is not valid.

Then the question we should be asking is: how do we most efficiently bring people to where they discover and understand the requirements?

Experience tells me people are much better at giving concrete, specific feedback to a running system than to an abstract requirements document.

Hence iterative development.

In essence requirements are not a document by a process.

<comment><USER3> This is largely wrong.

No, people cannot know "everything in detail, in advance". That doesn't mean that they don't know _anything_. They know a lot. Nobody with any actual experience in requirements-gathering expects 100% perfection. So the underlying assumption about the underlying assumption is wrong.

After 20+ years in this industry, I'm long past believing the conventional wisdom that running systems are the best way to gather better requirements. It's _not agile_. Think about it. A key part of agile is to push everything to the left as much as possible - to catch problems as early as possible in the cycle. What's earlier than before you write the code at all? Writing code to find out what's wrong with it from a requirements perspective is really inefficient.

This isn't to say we shouldn't get working code out there as quickly as possible, or that feedback from working systems has no value. But this idea that it's the _only_ way to get meaningful requirements, that's just BS.

Requirements aren't a document, or a process - they are a _system_.

<comment><USER4> I've found that writing (pseudo-)code is absolutely necessary to find problems in the requirements. Often enough the requirements are self contradictory or just contain too many unnecessary corner cases. I've seen requirements that sounded really simple in the requirement doc, but turned out to be extremely hard to test because they implicitly defined a state machine with dozens of transitions.

<comment><USER5> Especially because English is often a terrible language to express requirements.

<comment><USER4> Especially when it's written by people who aren't native speakers but work in a "we're a modern company now" environment.

</comment></comment></comment></comment></comment><comment><USER6> This was the inspiration for "Extreme Programming":

You make a minimal cost mockup ASAP, for the client to try out, to see if it's what they wanted. Clients can't appreciate requirements, so (like, actual) architects make a scale model first.

The alternative, of doing requirements as a separate phase, was ridiculed as the "waterfall model". In reality, there's interactions between the so-called phases of req, spec, design, code, test, maintain etc.

The truth is that understanding the problem is most of the work - not just for the programming problem, but for the business problem. It's just difficult. And when the world changes, you just have to change with it. If you try to anticipate what's next, you'll invariably get it wrong.

Because the world is changing faster, software develoment has gone from beautifully engineered software that just keeps working, to slapped together solutions, and a fulltime team that runs alongside, slapping patches on patches, continuously.

What's the point of spending the time and money on beautiful engineering, if it's going to be scrapped tomorrow anyway (or even before it's finished)?

The only hope is for tools, libraries, frameworks and languages, that address lower levels of abstraction, that change less frequently. This isn't all good, but the JVM is one example.

<comment><USER7> > What's the point of spending the time and money on beautiful engineering, if > it's going to be scrapped tomorrow anyway (or even before it's finished)?

Good luck maintaining that code. Don't forget about the team, a messy codebase and/or poor requirements, eventually, will break a team's morale until the day news devs come along and demand a refactor.

I start to love the idea of a waterfall model for software. People can still iterate on the problem with wireframes, even high fidelity ones, and speaking with customers, market research, etc.

There is a lot of value, time and money saved when you have a decent level of accuracy in the specification.

<comment><USER8> It really depends on what you're building. There's a reason civil engineering isn't "Agile" \- this also applies to major IT systems. A tiny difference in requirements can have massive impacts.

Honestly, in these cases, there's nothing better than waterfall, partly to save development time, but mostly for contractual protection: If a small change can cost millions more (and from experience, they can), you need to know who is responsible for paying those millions...

<comment><USER9> > There's a reason civil engineering isn't "Agile"

There are plenty of reasons why engineering isn't "agile" and it's only usable in software development, and one of the main reasons is that software development projects manage a single resource: man/hours. Building the wrong or inadequate solution has its cost, but rebuilding something from scratch does not require additional resources to be allocated to the project: just keep the same team working on it and results will pop up.

Engineering projects are very different than software development projects. Materials and components are the driving cost of a project and there are plenty of stuff that must be done right from the very start. It's unthinkable to scrap a machine or building or tunnel midway through, and it's inconceivable that some disaster happens at all. Engineering either gets it right at every single stage of a project or there are serious consequences to deal with, which in some cases might even be criminal charges. If for some reason a prototype crashes during development then the project might be forced to shut down.

<comment><USER10> I 100% agree with you. Software is "soft". Making changes to a code base is very cheap. Iteration just makes sense in software even for critical systems. If you build a suboptimal bridge, you have to live with it. If you write suboptimal software, you can test the actual product and fix it before you even ship. You can't really test a bridge outside of simulations. GP's comparison is apples to oranges in a lot of ways.

<comment><USER9> > You can't really test a bridge outside of simulations.

Just to pick a few nits, actually bridges are indeed tested during and after construction. It used to be standard practice to do test runs with near limit loads to inaugurate bridges, consisting of getting a fleet of military vehicles or water tankers to cross the bridge while surveyors monitored the bridge's response.

Nowadays non-destructive testing techniques are favoured for a number of reasons, including the fact that sensor rigs can also be used throughout the structure's lifetime to help determine its fatigue life.

</comment></comment></comment></comment></comment></comment><comment><USER11> You might be interested in [https://thorny.io](https://thorny.io) \- an interactive notebook for decision-making.

It's purpose is to capture design-rationale and bring it to life so that as you refine your reasoning, the changes ripple through your decisions. It can help communicating complicated design decisions that can be awkward to capture in prose.

It's intended to be very low-friction so more like markdown than old requirements management or decision support systems. My dream is that it can help us tackle decisions so complicated we usually give-up e.g. when multiple decisions impact each other.

I am currently in beta and I'd love to talk to anyone interested in the topic. Please drop me a line at duncan at thorny.io.

<comment><USER12> That looks intriguing, though I'd be more interested if it was a desktop app rather than a website. It reminds me a bit of Soulver, though Soulver is focused more on numbers & calculations: [https://www.acqualia.com/soulver/](https://www.acqualia.com/soulver/)

<comment><USER11> Soulver is very cool! We have lots of tools for calculations it's funny we have so few for reasoning.

If beta-users find the web-app useful then I can release native apps but I must resist until its proven!

<comment><USER12> Ahhh, excellent! I definitely agree with proving the demand for an app before spending time expanding it. Great strategy!

</comment></comment></comment></comment><comment><USER13> As someone that spends most of their days at the design/scoping phase, then watching the product go into development where it encounters constant misunderstandings and gotchas that the customer never told us about or never realised themselves, I completely agree that there is a huge disconnect between the scoping and requirements phase and the build phase.

I almost have guilt over feeling like my work of design and scoping is effectively useless to a developer, all my mockup layouts have to be built ground-up, my requirements aren't actionable in any way unless they feel like reading them (I try to keep them as succinct as possible, but the nature of working for clients also means I have to be somewhat specific so that people know when they should actually pay us). I've looked into things like Cucumber ([https://cucumber.io/](https://cucumber.io/)) so that my requirements can actually be compiled as tests, but adoption is slow and arduous, and all I'm really doing is adding more work to a dev.

My latest line of thinking is that I need a way to show the user interface, and then the data flow and logic all the way back through the system (usually a back-end DB or a customer legacy system). It's vital that these are presented together, hence my current process is interactive mock-ups built in Sketch ([https://sketchapp.com/](https://sketchapp.com/)) and hosted on Invision ([https://www.invisionapp.com/](https://www.invisionapp.com/)) which allows the customer and developer to click around and see it on a mobile screen so they really get a feel for it. Finally I couple that with a BPMN diagram which has swim lanes not just for the traditional system swim lanes, but also for a user (i.e. User taps Submit) and for a user interface (i.e. shows the mockup screen that is displayed), and then the logic flows down through the diagram. (e.g. User, User Interface, Mobile App Logic, Server Logic, Server DB, etc.)

<comment><USER14> Can I suggest you involve your entire team in the discovery phase, meaning talking to the customer and interacting with the problem from the very start?

Shared understanding (passing what you've learnt on behalf of the rest of the team doesn't count) can help everyone, (including the customer!) understand the whys, whats and hows of their own problem space. Then as a whole team you can come up with and vet the solution - qualified by the deeper understanding everyone in the team has.

This deeper understanding will help you arrive at a better solution, wasting less time building the wrong thing and reduce the friction in "handing-off" to development (because there isn't a hand off).

<comment><USER15> This here. Having someone who doesn't have to social skills of a house plant to talk to the customers, and then have the neckbeards in the back room code it up, is not the way to go, and nowadays I refuse to work with partners who work like this (or with subcontractors who want to force this workflow on me, and not limited to software dev either - I no longer work with e.g. building contractors who work like this either). And yes, I understand the point of specialization and division of labor, and yes in the past I too would have much preferred to just be the guy being handed perfect specs and never having to talk to anyone from the outside, and then when things go wrong there is always 'the spec' to blame. But it just doesn't work that way. In the past, being a 'business programmer' was called being an 'analyst-programmer'. I never really understood that, until I got to a point where I realized that the actual 'programming' (i.e., 'coding') is the easy part; it's the 'analysis' of the problem (well, and the formulation of a solution to the problem that comes out of that analysis) is the key to delivering value. But still, the relationship between the problem understanding, the solution and the implementation of that solution is so close that you just cannot completely separate them.

I interviewed a bunch of firms for building a website last year; nothing particularly fancy. Several of them (at least the big firms) send in a guy who would always start off explaining their 'process' (all fancy sounding), that process essentially being 'you tell me what your problem is, then we will together design a solution, and then I'll hand you off to our project manager back at the office who will just have the programmers implement it; you'll never even have to see these guys face to face!'. Uh sure, probably to 95% of your customers, naive and gullible because of lack of experience, that sounds great and like it's an advantage, but no way I'm going to get caught with my pants down 6 months from now because there was some aspect we didn't cover in the 'design' but the programmers coded it up like that anyway because hey it say so in the spec, right?

</comment></comment></comment><comment><USER16> Not a software tool but I was recently introduced to the design-sprint[1] methodology from google and found it helped a lot with the requirements gathering and speccing phases. It was also light and easily implementable - they have some resources there too.

[1] [https://designsprintkit.withgoogle.com/](https://designsprintkit.withgoogle.com/)

<comment><USER17> Also 'directed discovery' from Pluralight: [https://www.pluralsight.com/blog/career/product- development-...](https://www.pluralsight.com/blog/career/product-development- directed-discovery)

</comment></comment><comment><USER18> We do this thing we call Discovery & Framing at the kickoff of a new project. It usually lasts 3-6 weeks and involves design, product, engineering and someone with the power to make decisions on the spot. We call this role a product owner.

It's a good way to get stuff out of folks heads, validate the problem and solution with users, and end up with some stuff for everyone to execute on by the end of the process. You can google the term for more detailed descriptions.

As for tools, we've been having success with real time board, and pivotal tracker (maybe gives away where I work) and of course a ton of sticky notes.

<comment><USER18> Since this got some upvotes, if you want a taste for a process like this condensed into and hour you can visit:

[https://pivotal.io/office-hours](https://pivotal.io/office-hours)

(Free, staffed by a balanced team over a lunch hour)

</comment></comment><comment><USER19> I'm a co-founder of a Swedish startup, and we have built a tool targeting product owners and product managers. It aims to eliminate endless email threads and disconnected workflows that are common in product development. It sort of replaces Word, Google docs, and Confluence and integrates with Jira and Slack.

I would be happy to give you a quick demo!

[https://www.delibr.com/demo](https://www.delibr.com/demo)

<comment><USER20> I am seriously interested, however your website has almost no information and I'll not book a 30-minute appointment at a later time to see how it works. The only informative part of the whole website seemed to be this screenshot: [https://www.delibr.com/img/design/features/section2/xstep1.p...](https://www.delibr.com/img/design/features/section2/xstep1.png.pagespeed.ic.SffT8WJQFM.png)

Add more screenshots and less "integrates with slack".

<comment><USER19> Thanks for the feedback! We have avoided putting too many screenshots on the webpage since we made changes all the time initially. However, we are now ready to put screenshots.

"I'll not book..."? I guess you meant "I'll book..."? =)

<comment><USER21> No, nobody wants to spend 30 minutes to see if a vague description of some software might work for them. There's not enough hours in the day. There's about 20 products mentioned here already. That's more than a whole day of doing nothing but having someone try to sell me something which probably doesn't do what I'm looking for.

<comment><USER19> How about 10 minutes and you'll get a Delibr T-shirt sent afterwards?

</comment></comment></comment></comment></comment><comment><USER22> Requirements are almost never perfectly specified. One of the most substantial and hard-learned parts of good systems design is automatically pre-empting, as far as reasonably possible, the probable range and depth of requirements scope shifts over the project lifetime. (Critically, that includes the 90% of a project's lifetime which is post-development maintenance.)

In short: if you have good people it shouldn't matter! Experienced people will extend the assumed scope beyond the stated requirements without being asked, and either do so efficiently within the resources available to the project or bring an appropriate level of attention to the limitation before it becomes an issue.

The somewhat less PC and far snarkier explanation, in the immortal words of twitter: _Don 't pick the right tool for the job, pick the right framework which secures you extra work for being a tool._ \- @iamdevloper (via [http://github.com/globalcitizen/taoup](http://github.com/globalcitizen/taoup))

</comment><comment><USER23> I recently took a model-based systems engineering course that opened my eyes to some helpful methods.

Use UML, SysML, etc to diagram out your requirements (starting at high level at first, more granular as the system matures). Now build a high-level model of your system design (software and hardware if required). Match parts of your system to the requirements. This lets you see gaps in two directions: requirements you haven't addressed (because they aren't connected as "satisfied by" anywhere on your model), and questions to ask for more detail on a given requirement that could drive the design.

As others have said, there will always be late requirements that change things, so it won't resolve those. It can, however, show stakeholders how much changing a requirement can cost in terms of rework/time by showing how the model has to change to accommodate.

The caveat with this is: the model needs to reflect your actual design, and you need to keep it up to date. The times I've used it so far it has been a useful exercise.

<comment><USER24> UML? Really? Most Business Users want to discuss the UI and (if you are lucky) the data structures, two things that UML is not really very concerned with. In my experience, UML has been a really bad choice to work on requirements for corporate sw.

<comment><USER23> Agreed, it's not what business users want to (or should) see. This is an aid for what your team does internally, instead of just lists and documents.

</comment></comment></comment><comment><USER25> I agree that what you describe is a huge problem. I'm not so sure though if that problem can be alleviated by additional tooling. More often than not the cause of this is defective processes and assumptions rather than deficient tools.

DDD, ubiquitous language and bounded contexts in particular, can be enormously helpful with defining better requirements.

I'm not so sure about BDD though in this context. While the notion of the customer / product owner writing specifications in this format in a way developers can use these specifications to test their code sounds great at face value I have yet to see a project where this is done consistently and continuously.

Moreover, some types of requirements can be better explained by using diagrams or UI mockups, which doesn't really fit the BDD paradigm.

<comment><USER26> Agreed, it's not about the tools, but the process. I've worked with different agile coaches - most of them were crap, but one of them really struck a chord in how he would find flaws on the organisation that would reflect on the software side. He was really good at devising strategies to overcome this.

To address the specific question, I think most of the time there's a problem because there is no one that takes care of making sure everyone has the same vision and understanding of what needs to be done. And because sometimes words fail us, I think mockups are a great way of uncovering and sharing requirements.

</comment></comment><comment><USER3> It's not free, and it's not simple, but Aha ([https://www.aha.io](https://www.aha.io)) can be very helpful in figuring out product.

Engaging end users is a problem from a couple of directions. First, the very idea of "end user" \- you need to engage _customers_ , not end users. (Take Facebook, for example... you're not the customer, you're the product. If you build something for Facebook, your customer is Facebook, not Facebook's users.) This situation isn't exactly unusual. In this case, it's the customer's responsibility to gather feedback from end users - and put you in the feedback loop, as needed.

</comment><comment><USER27> There is a class of tools for this called Requirements Management. They tend to be expensive and clunky tools in my experience, but I haven't used one for quite a few years. Ones I have used are Rational Requisite Pro (IBM) and Doors, which is now apparently an IBM Rational product too. I've worked on a project that used Doors for requirements management but also requirements traceability, a somewhat tedious task that would let us look from a requirement and identify all development documentation that implemented that requirement and eventually to code if required.

From an logical point of view I think it makes a lot of sense to start from clearly documented requirements, then work forward to design, implementation, and testing with links back to each requirement. I don't know how testing (higher level than unit testing) can really be effective unless they have requirements documents to use as their starting point. Use Cases go some of the way to providing this information but tend to be a bit less formal. Agile methodologies tend to be less formal than older methodologies that emphasised this kind of process more. A lot of Agile is good, but it does also tend to forget lessons from the past.

</comment><comment><USER28> People build tools for use. Software projects are an example of this. A lens I find helpful is to view a software project as a "process (or game) of transforming shared and individual understanding (or belief), into a tool or artefact". The project falls short if the understanding is not valid or the tool is poorly built or if the tool doesn't encapsulate the understanding or if circumstances change and the tool becomes less useful.

Transferring valid understanding into the final artefact is a key constraint in many projects (reading Goldratt and thinking of this transfer of understanding as a constraint was helpful for me)

There are many ways to fail. Some of the traditional ways to succeed are

i) rely on an individual who really understands the desired tool, and who has the authority and skill to communicate and be the final arbiter (including sometimes to write it all themselves). Sometimes this can be also done by a small group.

ii) write a really clear, well-written, very hard to misinterpret document and get professionals to develop and test this system (before the document goes significantly out of date)

iii) Run an agile process where the business can describe what they want in small pieces that can be delivered so quickly that little understanding is lost

Obviously what works is massive contextual, depending on the domain, funding, resource reqts etc. (Glen Alleman is good on this)

So I would argue 'good software tools for requirements' are critically dependent on your approach for how you are going to turn 'understanding' into a 'system', and you don't want to worry too much about them until you are happy with your approach. At that point you can start building your 'meta- tools'.

</comment><comment><USER29> I run Canny ([https://canny.io](https://canny.io)), which is a tool that software companies use to keep track of feature requests from their customers.

One awesome thing you can do is ping everyone interested in a feature, and ask them how they want it to work. See it in action here: [https://feedback.canny.io/feature- requests/p/tags](https://feedback.canny.io/feature-requests/p/tags). (Scroll down to Sarah's comment on July 20.)

Whenever we're thinking about building a feature, we ping all the stakeholders. This gives us solid context on how they want it to work, which helps us define our MVP. If we need to follow up for more information, it's easy to do that via email / Intercom.

Hope this doesn't come off as salesy – I really felt it was relevant.

</comment><comment><USER30> The solution to a "complex" problem is only knowable after the fact, versus merely complicated problem which is knowable before the fact. Any sufficiently useful computer program is typically "complex", though not always.

That said it is still incredibly helpful for everyone to agree on what we're building in the present iteration/sprint. You mentioned BDD which can be very helpful when paired with a team practice such as Example Mapping[0].

Other practices such as DDD can help you bound the problem and define it. Also there are some helpful lessons in Feature Driven Design.

Source: I teach BDD workshops for a living

[0] [https://cucumber.io/blog/2015/12/08/example-mapping- introduc...](https://cucumber.io/blog/2015/12/08/example-mapping-introduction)

</comment><comment><USER31> You can engage all stakeholders via a series of eventstorming sessions [http://ziobrando.blogspot.com/2013/11/introducing-event- stor...](http://ziobrando.blogspot.com/2013/11/introducing-event- storming.html?m=1)

<comment><USER32> Engaging isn't sufficient, it's a start. What is typically lacking is someone with the intelligence to properly understand the problem, and map out a roadmap to get there. There is too often a naive belief that the stakeholders will put you on the right path, they don't, they just give you information that feeds into the design process. Sure you solution should be regularly validated with the users, however in my experience the tend to lack the ability to give a vision which isn't just an incremental improvement on the current solution.

<comment><USER31> Note the word stakeholders, not simply users. Stakeholders includes the team actually delivering, not just the end client/users.

</comment></comment></comment><comment><USER33> I've been doing a variation of this for security, as it's the main need that requires abstraction-on-down definition, and it doesn't translate well into agile environments where developers are designing solutions. (qtra.io, in private beta, so no free experience yet)

The fit problem I'm having is getting technical threat hunters who populate the market to think about risk and security design, or product/project managers to reason even high level about a domain they delegate to technologists.

Still iterating for fit, but so glad there is a thread of people thinking about architecture.

</comment><comment><USER34> I got frustrated with cucumber and cucumber-esque tools for doing BDD so I built my own which were optimized for programmer usability (strict type system, inheritance built in, sane syntax, etc.):

[http://hitchdev.com/hitchstory](http://hitchdev.com/hitchstory)

The time when it was most useful as a "BDD tool" was when I was working with an extremely technical stakeholder who was proposing behavior in a command line tool he wanted.

I simply wrote 'tests' that described the command line tool's behavior and showed the YAML to him. He corrected the mistakes I'd made by misinterpreting his original requirements and then I built the tool to that spec and when it passed I was confident I'd nailed his requirements.

QA picked up bugs afterwards but they were all either (quickly rectified) mistakes he'd made in the spec or environment issues. I had zero spec<->programmer communication issues even though (and here's the crazy part) _the domain was very complex and I didn 't understand it_. It had to do with a highly customized software system I didn't understand which enacted some sort of financial process which I also didn't understand.

Cucumber can do this in theory, but in practice the spec is not sufficiently expressive and the stories end up being ridiculously, unusably vague. Unit tests could also do this in theory I guess, but good fucking luck getting a stakeholder to read them even if you do manage to write them "readably".

I'm taking this process a step further. Although these YAML specifications were useful for me in the past to collaborate with stakeholders they're still not amazingly readable. For instance, the "YAML inheritance" makes it easy for programmers to maintain but harder for non-technical stakeholders to understand.

Instead of sacrificing maintainability for readability I created a process to easily generate readable stakeholder documentation from the 'YAML tests'. I used this in the libraries on the website above to generate always-in-sync- and-still-highly-readable documentation.

I think this could be used to essentially write low level "unit" tests which generate documentation which stakeholders can interpret (e.g. defining the behavior of a complex pricing algorithm) and use that to get a quicker turnaround on understanding, defining and modifying desired behavior in complex domains.

</comment><comment><USER35> If you don't mind a shameless plug, we'd be happy to invite you on Txime, a collaborative webapp to conduct DDD and especially event storming sessions. [http://www.txime.com](http://www.txime.com) We're in beta but opening soon.

</comment><comment><USER36> In my experience focusing on the tools usually ends up failing projects or going over-budget. e.g "we don't have a product yet, but look at all these shiny cucumber tests!". I think a good start is to have someone who is very user focused in the team.

</comment><comment><USER37> I just use a whiteboard or paper. Nothing beats it IMO because at this stage you want to create a brain dump and chances are you'll be making a lot of changes.

With most programs, you'll spend half your time battling its UI and trying to get around limitations.

</comment><comment><USER38> Many people have said this but here goes anyway: The tooling will not help you better define the specifications. The tooling will not help you manage changing specifications. You can cover all the bases easily in a free Github project (Edit: pick your web-based tool, basically) without too many issues.

I would argue that the reason things get called out as poorly defined or change is because risks are not addressed early, and hypotheses are assumed to be theorems.

Make sure your teams test the main assumptions early, with actual code if at all possible. That will call out why your stories aren't clear enough.

Tools are useful, but they won't solve your problem.

</comment><comment><USER39> Those days I just sketch wireframes in a Google Slides presentation.

Bonus point for the interactivity: I can share the URL for remote work sessions, and the stakeholders on the other end of the line can see me create/adapt wireframes and notes in real time, while I'm explaining everything on the phone (using anonymous access for those not logged into 'The Google').

Google Docs has version management since this year (I think), so I can pinpoint the evolution of specifications over the time. When I'm done I'll just export a PDF and attach to a "Spec done!" mail to everyone.

</comment><comment><USER40> This is very advanced topic and I think (almost) all "end-users" are absolutely not ready to embrace it. You cannot be completely sure that you and "end-user" are thinking about the same subject.

</comment><comment><USER41> I think it depends on the problem domain. In high-risk or regulated industries having requirements and specifications is a prerequisite to shipping. There are plenty of good sources for finding the standard expected formats out there. If you're an IEEE member you'll find the ISO requirements and specifications templates in the library.

Doing requirements gathering isn't an inherently bad process to adopt even in non-regulated settings. However I believe many developers will have a negative reaction due to prior experiences with, or having heard about, the waterfall method. The key to remember is that requirements don't, and shouldn't, have to come with an estimate. Great requirements demonstrate a thorough understanding of the problem. They're written from the perspective of the end-user.

Specifications are the dual of requirements and are what drive the implementation that solves the stated problem. Specifications is something I think we need to get better at. We some unit testing, some integration tests, and occasionally end-to-end user tests... some few to property tests; but rarely do we write formal, verifiable specifications in a modelling language that can be checked with a model checker. Rarer still do we write proofs as part of our specifications.

We often elide specifications or we do the minimum necessary to assure correctness. This is to the detriment of your team on a larger project. How do you know your designs don't contain flaws that could have been avoided? How much time are you spending before you realize that the locking mechanism you chose and shipped has a serious error in it that is causing your SLO's to slip?

For requirements I just use plain old Markdown with pandoc. For specifications I use a mixture of Markdown and TLA+. I use TLA+ for the hard parts of the system that we're unsure about and require correctness for. The rest of the specifications that aren't as interesting I simply use prose. It's a matter of taste but it does require an intuition for abstraction... when to do it and how to think about systems abstractly.

We could definitely use better tools for TLA+-style specifications, btw. Maye more libraries that can translate TLA+ state machines into the host language so that we can drive them from our integration tests, etc. Better IDE tooling. Better training.

</comment><comment><USER42> I have been mucking about with the idea of textual prose discussion documents, which hyperlink markdown style to usecases, which link to tickets in Jira or somesuch.

then as the document is discussed and altered by the owner the use cases alter and flow

It's just trying to keep a prose discussion in line with everything else in dev friendly manner (it can be stored in the docs folder in git and be generated onwards etc)

still playing

</comment><comment><USER43> Wireframes for UI design alongside UML for enterprise data models and process flows, and finally good old truth tables work best in my experience. They work to bridge the gap between business and development. You'll never get 100pc coverage but you'll get a lot of the way there.

</comment><comment><USER44> I loved reading "User Story Mapping" and putting it to use. It really changed how I worked. Highly recommended. [http://shop.oreilly.com/product/0636920033851.do](http://shop.oreilly.com/product/0636920033851.do)

</comment><comment><USER45> Coming back to the question: One possible helpful tool is Doorstop ([https://github.com/jacebrowning/doorstop](https://github.com/jacebrowning/doorstop)).

I like the approach to embed requirements in source code (management).

</comment><comment><USER46> Aren't there testing frameworks that were supposed to help solve this problem?

Maybe you could engage customers qualitatively, and translate that information into software requirements and acceptance tests? I'm not entirely clear how you want to engage these kinds of users.

</comment><comment><USER47> We did a lot with jstd and used doors succesfully [https://www.ibm.com/us- en/marketplace/rational-doors](https://www.ibm.com/us-en/marketplace/rational- doors)

</comment><comment><USER48> I experience issues with poor requirements everyday. The single biggest problem I see is that the people writing the requirements have no idea how to write them. We do not need a tool as much as we need better training.

</comment><comment><USER49> I always refer people to this analogy on the problem of estimation in software projects, I think it's pretty spot on: [http://qr.ae/TUGpbW](http://qr.ae/TUGpbW)

</comment><comment><USER50> Technical coach here. This is a passion of mine. I've seen far too many teams waste far too much time with horrible, horrible backlogs and tooling systems -- usually set up with the most sincere good intentions, by the way. I care so much about it I wrote a book on managing project information. The key example, repeated throughout the book, is a small team meeting folks and starting to make stuff people want. (Obligatory link: [https://leanpub.com/info- ops](https://leanpub.com/info-ops) )

I believe if you can get the small team scenario working over-and-over again scaling will work itself out. So far I have no reason to believe this isn't the case -- and I've applied the principles in the book both to functional coding and program management.

mjul's comment is the key one: you can't know everything before you start. That doesn't mean you can't know _anything_. It means that there is a "progressive elaboration" that has to happen on an as-needed basis. Otherwise you're stuck either not knowing enough to get going -- or having created a monster or a tools/information system that ends up running the project instead of the team.

There are some sanity checks for whatever backlog/requirements system you are using. Instead of my continuing to pitch, I'll just list the things that your system should do no matter what kind of system you have.

\- Handle whatever detail is needed before actual development happens.

\- Be able to "flip-around" and start from scratch within an hour or so. (And "starting from scratch" means beginning with nothing and ending with the team starting coding) While keeping all that detail in test 1.

\- Be reusable with other teams doing similar work. A backlog/requirements system can't make work fungible, but it can enable better conversations in other teams without being a burden.

\- Limit meetings around organization to under an hour or so. Yep, you gotta have those "meta" meetings from time-to-time and talk about things like release plans. But they shouldn't take over your afternoon.

\- Help the larger organization (if there is one) learn and grow over time. Orgs learn from the bottom-up. Good tools should facilitate this learning.

\- Drive directly to acceptance tests. Good backlogs are testable. Things shouldn't be in there that don't drive tests.

\- Have controls in place to prevent abuse. As soon as you create some tool for the requirements/scoping phase, somebody is going to go all architecture- astronaut and overuse it. There has to be controls to prevent this from happening. The tool should _facilitate_ the work of understanding and scoping, not _replace_ it. (I think even a lot of tools vendors get confused on this one).

I even wrote an analysis compiler that demonstrates all of this as part of writing the book. So if you think all of this is impossible -- happy to do a demo.

There are a few other testable criteria for whatever your requirements/backlog system is, but that should be enough to get you started deciding whether some system is better or worse than another system.

</comment><comment><USER51> I really like TiddlyWiki since it makes it easy to link everything together and organized.

</comment><comment><USER52> You may like a product roadmapping tool like Aha.io

</comment><comment><USER53> Better colleagues with better brains.</comment>


Canadian hacker dupes Walmart to win Defcon prize - <AUTHOR> http://www.thestar.com/printarticle/1239150

<comment><USER2> "As security systems get increasingly difficult to crack, hackers are turning toward a new source of information: people."

Social engineering has _almost always_ been the most productive way to gain access. Jessica McDiarmid does her credibility a disservice by indicating that social engineering is a new development.

<comment><USER3> For a while, you could only get info out of humans "retail", that is, one or a few pieces of data at a time. You could easily extract data from a computer "wholesale", thousands or millions of records per breach.

<comment><USER4> He's not saying it's the most productive way to get data, he's saying it's the most productive way to get access.

<comment><USER2> Exactly. However, sp332 may have meant that worms and such are much more effective at getting access to more systems and information quickly, but not in a targeted way.

</comment></comment></comment></comment><comment><USER5> Working link on mobile: [http://m.thestar.com/business/companies/walmart/article/1239...](http://m.thestar.com/business/companies/walmart/article/1239150 --canadian-hacker-dupes-wal-mart-to-win-def-con-prize)

</comment><comment><USER6> Isn't social engineering just conning? Why do we need a new name?

I remember a bit from The Art of The Steal which was written by Frank Abagnale, who is the real life inspiration for Catch Me if You Can. He talked about how to make free long distance calls in those days. Call a company via a payphone. Ask to be transferred to the switchboard. Make up some BS about being a part of the company and urgently needing to make an outside call. They dial the number and connect you, the end.

Sounds like "social engineering" to me as well. Or just good old fashioned conning, possibly re-discovered by hackers and given a new title. They're just using the same methods we've been using to get private information since the dawn of private information. Namely sweet-talking third parties that hold the information and don't really know any better.

<comment><USER7> I read "Ghost in the Wires" (a book about Kevin Mitnick's life) a month or two ago, and it's astonishing how well he knew the system. He was doing stuff like the above, but also getting around the callback as well (I don't recall exactly what he did, but it was something along the lines of conning the line workers to divert an exec's phone number for testing purposes just long enough to get the callback). That was just one of many times he pulled these sorts of stunts for curiousity's sake.

</comment></comment><comment><USER8> You can throw money at a problem like security, but it's the underpaid employee earning $7.99 an hour that you should be throwing money at if you want a secure company. The weak link in any security is always people.

</comment><comment><USER9> > _Set up an internal company security word of the day and don't give any > information to anyone who doesn't know it._

I don't think it's a good idea. Imagine a social engineering attack from inside the company, or if somehow the hacker has access to the word of the day. When he'll say the word, the guy on the other end of the phone will be way more relaxed and ready to give much more information...

</comment><comment><USER10> Are there anywhere some more detailed information about the challenge? I guess the conference recordings are not going to include the social engineering live session?

</comment><comment><USER11> Curious to know the precise list of information requested for this task.

<comment><USER12> This PDF has a list of flags from DEFCON 18 (this year was 20): [http://www.social-engineer.org/resources/sectf/Social- Engine...](http://www.social-engineer.org/resources/sectf/Social- Engineer_CTF_Report.pdf)

I didn't watch any this year, but I've been led to believe there were more than the 32 listed on that PDF.

<comment><USER4> Very interesting. Do they publish a list of what companies were targeted?

</comment></comment></comment><comment><USER13> No video?

</comment><comment><USER14> so... "The Social Engineer", the sequel to "The Social network"?</comment>


Ten commandments for developers - <AUTHOR> http://damieng.com/blog/2008/08/01/ten-commandments-for-developers

<comment><USER2> I wish all the apps on my work PC obeyed these commandments. There's a certain popular spreadsheet application that damn near reduces me to tears every time I attempt to use it.

 _("What do you mean, you can't open 2 files with the same name? They're in different folders! For the love of God, why?!")_

</comment><comment><USER3> Excellent advice! If you write client-side apps, obey these commandments, for they are truly the user's keeper.

</comment><comment><USER4> Each commandment is not prefixed with "Thou shalt"...I'm so very disappointed.</comment>


Ask HN: Review My App | "LifesBook"  =  Twitter  +  A Diary - <AUTHOR>

Please review my app AND business model:
http://www.lifesbook.com
WHAT THE SITE DOES
LifesBook is a private online diary (or journal) that works much the same way twitter works (in terms of SMS and hopefully user frequency of posts).
To make an entry all you need to do is send in an SMS, make as many entries as you like whenever you like!  If you start to get lazy with your entries (like you would with a normal diary) don't worry we can kindly remind you.
THE BUSINESS
So I think this is the kind of app that a few months ago you would see with no business model apart from ads, basically fuck that. I have gone for the typical subscription based approach set at $9.99 per month for now, I hope to get this cost down and I will be able to when I get a bit of the economies of scale loving.
I aim to and hope that I have created such a good product that $9.99 seems like great value. As you would expect after a user has been using the site for a few months the data (their entires) we store for them becomes really quiet valuable to the user. This makes me want to extend the trial period from the current week to as long as possible (eg 3 months) but SMS costs are just to crazy to be able to do that right now.
What do you think about this business model and approach?? Its an app that I think allot of people would use if free but how can i make that financially viable? I don't think I can so thats why iv done what iv done.
FEW MORE THINGS
Due to the SMS cost I currently only have a UK number available, this may mean it will cost a user outside of the UK more to send a text in. I am not to sure. But either way I plan to add a US number as soon as its financially viable, I am guessing thats within the month.
Search has just died on us in production, its a hosting issue and we are on to it.. Decided to release anyways. Meh
FEEDBACK
I want as much feedback as possible and not just on the app I also want feedback on the business behind it. <comment><USER2> First off: You stole Tumblr's icons. That's a really, really shitty thing to do. They paid good money for those icons and you blatantly ripped them from the site.

Not just that. You copy your "translucent borders" from Facebook, your "close window" dialogue from the original lightbox and your feedback tab links to Getsatisfaction. The one original idea you had, putting notebook lines in the background, you couldn't even bother to sync up with the size of your font. (Aviary does this but they actually sync up the lines.)

Second off: How is this _better_ than Tumblr? Do you know what Twitter is without ultrasimplicity? It's a downgraded version of a regular blog. That's why "Twitter+this" startups fail. Twitter is _only_ good because it's so simple.

I use my blog as a diary. I write 20-30 posts a day about whatever comes to mind in the hopes that I can preserve it as a diary for half a century and then figure out a way to make use of it. Why would I pay $10 a month for something that gives me less than I've already got?

Third off: I like the header design but it's hard to navigate. I'm also a little offended that as your "famous diary person of choice" you picked Anne Frank, whose diary is most famous because _the person that wrote it died_. What's the implication? "You'll die so write stuff down?" For an online service, that's pretty obnoxious.

All that stuff aside, it looks nice, though I wonder just how much of this design you ripped off sources of which I'm not aware. (I could swear that font looks remarkably close to the "sparse black-on-white" that Posterous uses.)

<comment><AUTHOR> The tumblr icons are all removed, I just put this site together quickly and admit it was the wrong thing to do, I apologize.

Im not sure about the facebook stuff your talking about I also thought using lightbox and Getsatisfaction the way I have is ok.

Header was never ment to offend, its was just a bit of fun. As most people would assume I am not implying that you die if you use this service. Has also been replaced.

I put the site together in a few days and design is not my strong point. The orignal diary type design is shown here: [http://www.webdesignerwall.com/tutorials/design- watercolor-e...](http://www.webdesignerwall.com/tutorials/design-watercolor- effect-menu/). I have permission to use this stuff, including the 404 page.

I honestly dont expect a HN user to use this site, its more geared towards people that havnt got a clue what wordpress or tubmlr is.

<comment><USER3> "I honestly dont expect a HN user to use this site, its more geared towards people that havnt got a clue what wordpress or tubmlr is."

If the people you are targeting do not know what Wordpress or Tumblr are, how in the internet world would they stumble upon you before first landing on one of those sites?

</comment></comment></comment><comment><USER4> First, as always, congratulations on launching and getting something out the door. I think that's one of the hardest things to do, so kudos to you for getting something out there.

I kinda like this idea though I'm not sure I'd pay $9.99 a month for it. Also, if you were industrious enough you could do this yourself with a private WP blog that you email posts to, but obviously not everyone knows how to do that.

A few thoughts about your web site that after a first look.

1.) The first thing that grabs my eye is the "A Diary + Twitter = LifesBook" yellow block in the center of the page and it immediately confused me. I first thought that the app somehow integrated with Twitter and then thought "There's no way I'd post my private thoughts to a Twitter stream." At this point, peeps who feel the same way might move on.

2.) The phrase "(SMS type functionality)" in the yellow box only confused me more and I still have no idea what it means even after realizing that you can text thoughts to your service.

3.) The next block under the yellow block focuses more on features than benefits. I wouldn't lead with "SMS Diary Entires", "Memory Bank", and "Locked and Secure". Those don't mean much to me as the user. Try something like "Post from Anywhere", "Never Forget a Thought", and "We Keep Your Secrets" instead.

4.) Small typo under the Spare Change heading on the home page. You end with "Seriously just got nuts." I think you mean "just _go_ nuts", right?

5.) Others may disagree, but I don't love the name. I think my biggest fear of using a service like this is that I'd be posting my most private thoughts out into the cloud, so a name that somehow let me know that you're storing my secrets as securely as possible would be a plus. Sorry I don't have a good name suggestion right now, but it's something to think about.

Anyway, best of luck to you. I think if you keep tweaking and iterating you'll find something that people really dig.

<comment><AUTHOR> Thanks for the great feedback!

Regarding 1,2 and 3, I agree Ill look into changing this now.

5\. I see what your saying but I think its possible to put these concerns to rest by building a strong brand based on things such as security. I don't think a new name is what should express that, I think thats the brands job.

</comment></comment><comment><AUTHOR> Iv killed the site, clearly lots of things i need to fix. lesson learnt.

<comment><USER2> Best of luck to you! When you do your next thing, absolutely feel free to submit - don't let criticism this time stop you.

</comment></comment><comment><USER5> Meta-feedback:

To be successful, you need the tenacity to keep going and the humility to realize where you erred. Welcome to the crucible.

What could you do next time to avoid these particular responses?

</comment><comment><USER5> "As you would expect after a user has been using the site for a few months the data (their entires) we store for them becomes really quiet valuable to the user."

True enough, but please don't hold your users' data hostage.

<comment><AUTHOR> Oh I don't plan to at all

<comment><USER6> We don't care what you plan to do. We care what you have in place already that allows data portability.

</comment></comment></comment><comment><USER6> I guess this is as good a time as ever to be concise and blunt. You have competitors that do exactly the same thing, better, for free, that have traction, and a recognizable brand. Good luck.

</comment><comment><USER7> I think you meant <http://www.lifesbook.com/>

<comment><AUTHOR> Cheers!

</comment></comment><comment><USER8> good luck, but I dont think u will find many customers for this due to the fact that:

wordpress if free & twitter is free and lets u keep your updates private if you want i believe

it does look very well done though

<comment><AUTHOR> I see what your saying and thats why I am looking for feedback on a business model</comment></comment>


People luring Instacart shoppers with big tips – and then changing them to zero - <AUTHOR> https://www.cnn.com/2020/04/09/tech/instacart-shoppers-tip-baiting/index.html <comment><USER2> Instacart should be on the line for promised tips if the order was successfully delivered. The onus is wholly on Instacart if they permit a change in contract post delivery. They should ban any customer doing such for a minimum number of days and ban them from the service if more than three times total.

However the only winner here is Instacart because they are still getting paid in full while those doing the work are being defrauded.</comment>


Heart of Earth's inner core revealed - <AUTHOR> http://www.bbc.co.uk/news/science-environment-31322817 <comment><USER2> As for what the east-west axis means... According to the paper, they use a cylindrical anisotropy model and the best-fit axis is located at (9° N, 89° W) or its antipode at (9° S, 91° E). In other words, the crystals point along an axis near the equatorial plane through Central America and Southeast Asia.

The paper is pretty vague about why this would occur: "may represent a tectonic evolution of the inner core and thus our finding may indeed offer 'clues about the inner-core history: its age, thermal process, and possibly an early convective event'."

Paper is available at [http://www.nature.com/ngeo/journal/vaop/ncurrent/full/ngeo23...](http://www.nature.com/ngeo/journal/vaop/ncurrent/full/ngeo2354.html)

<comment><USER3> But the core doesn't rotate at the same rate as the crust: [http://news.harvard.edu/gazette/1996/08.15/PuttingaNewSpin.h...](http://news.harvard.edu/gazette/1996/08.15/PuttingaNewSpin.html) (or has this been proven wrong?)

<comment><USER2> That's very interesting. If the inner core rotates 3 degrees a year and the earthquake data covers 20 years, that would be a 60 degree shift from start to end of the data set. I looked over the paper again, and they don't mention this at all.

Edit: I emailed the author of the paper (Xiaodong Song). He says that more recent work suggests 0.3-0.5 deg/year for core rotation. (This would make the rotation much less important.)

[http://www.geology.illinois.edu/people/xsong/Sites/papers/zh...](http://www.geology.illinois.edu/people/xsong/Sites/papers/zhangetal05_science.pdf) [http://www.geology.illinois.edu/people/xsong/Sites/papers/li...](http://www.geology.illinois.edu/people/xsong/Sites/papers/lindner_etal10_jgr.pdf)

</comment></comment></comment><comment><USER4> What does it mean for the crystals of the 'inner inner core' to be aligned in an 'east-west direction'? Its a sphere. Does that mean they are aligned in a ring, like the grooves in an lp (or the dots on a CD/DVD)? Why doesn't the graphic reflect that?

<comment><USER5> Iron crystallizes at high pressure, while the iron is molten it aligns itself with any magnetic field, then as it crystallizes it can no longer change direction as the field changes.

This paper suggests that as the inner part of the core was solidifying, the earth had east/west magnetic poles rather than north/south magnetic poles. And then something "big" happened to switch the poles north/south. That "big" thing happened in a fairly short period of time (geologically) if the boundry between east/west alignment and north/south alignment in the crystals is thin. They also mention the core is solidifying at a rate of .5mm per year. Which is how they hope to "date" the event that occurred. Although it is unclear to me if they consider the process to be dependent on the surface volume or not.

Does that help?

<comment><USER4> Not a bit. There's no such thing as an east pole or west pole, like there is a north pole.

<comment><USER6> I think the implication is that magnetic North was on the equator, rather than at the geologic pole.

<comment><USER5> exactly this. If you had a compass and were on the planet while those crystals were forming, the 'north' part of the compass would point you to a point along the equator rather than in the upper latitudes as it does now.

</comment></comment></comment></comment></comment><comment><USER7> 9N 89W is off the coast of Costa Rica, 9S 91E is off the coast of Singapore, which both locations seem to be kind of close to areas prone to earthquakes and tsunamis.

Also, it says it could have changed half a billion years ago. The current estimate of the formation of the moon is around 4.5 billion years ago, maybe these are related and they got their dating wrong?

The only thing I can find that happened half a billion years ago was the end of the the Neoproterozoic Era (the end of the Proterozoic Eon), which saw the first multi-celled life and the end of the Marinoan galciation, which could have subsided through global release of methane from equatorial permafrost.</comment>


New Finance Website based on Arc / HN - <AUTHOR> http://www.wallstbeat.com

<comment><USER2> <http://moniedinterests.com/>

<http://www.markenomics.com/>

<comment><AUTHOR> both of those are dead-pooled. looks like they couldn't get anyone using it.

and add a way to search industry/geography.

<comment><USER2> Yes, that's the point, sort of. For one this has been done before, several times. Only newmogul.com managed to make a go of it and I think that was in large part because of the fact that the people that started it continued to use it every day.

You really need some 'life' if you expect to keep this going, just launching something is not enough.

You could probably write whole books about how to bootstrap a community. It's a pity nickb could not be bothered to pass newmogul.com off to others to keep it alive, it already had the hardest problem (initial audience) solved.

And any new launch of something like that will make it harder for the next to be taken seriously.

Maybe all you guys should pool or something instead of everybody running their own 1 user domain?

<comment><USER3> Not entirely related, but did anyone ever find out what happened to nickb? All of a sudden he seemingly just dropped off the earth.

<comment><USER2> No, but not for lack of trying. Never got a response, but I believe someone else mentioned that they confirmed that he was ok, I just can't find the reference.

The phone number in the newmogul.com registration is answered by someone that says there is no 'nick' there.

What's the proper etiquette for signing off from a website anyway? Is there some kind of moral obligation to announce your departure? I'm sure plenty of people leave HN daily (and plenty arrive), surely if everybody would say 'bye' every time they leave it would get pretty messy.

But for long time contributors it might make sense, or at least an update in your profile or so...

</comment></comment></comment></comment></comment><comment><USER4> Make this but target it towards value investors (because they read a tremendous amount-- multidisciplinary stuff, newspapers, SEC filings, etc) and you will probably be able to attract a pretty good core following. Then you can gradually expand and widen the audience.

Feel free to contact me (see my profile) if you'd like some more input if you decide to move in that direction.

<comment><USER5> Do you know of any resources that differentiate the different type of investment styles? I see you mentioned value investors and know there are other types.

Finance is one of those worlds that's so big, it's kind of hard to find a place to start digging in.

<comment><USER4> Investors usually use technical or fundamental analysis. Some use both, but I would say it is not very common.

Technical guys are usually trading, they are looking at price charts and trying to gauge supply/demand and figure out how prices will change.

Fundamental investors take longer term perspectives, they analyze reported financials and qualitative factors, model earnings, etc, to determine where they think the company's performance will go and how that ultimately drives the stock price.

From there, you have some other possible divisions. There are traders for every asset class (fixed income, currencies, commodities, derivatives). Then, some investors differ by strategy (value, growth, global macro, event driven, long, short, long/short, market neutral, distressed debt). Some might use a combination of both.

E.g.: a macro trader might use technical analysis in the day to day while analyzing data releases from foreign countries to determine how their bonds will perform. So a combo of both fundamental and technical analysis.

Hope that helps.

</comment></comment></comment><comment><USER6> New Mogul was the first I've seen of this and was the best. I think New Mogul's success was also partly due to the intensity of the financial crisis and people's interest in understanding how it all works. Nickb vanished, unfortunately, and New Mogul eventually fell.

No site has been able to replicate the New Mogul community and I don't believe it's the UI's fault entirely, though New Mogul actually did a good job sprucing up the default look. I believe the intense interest along with communal enthusiasm just doesn't exist in that industry under normal circumstances. And certainly not enough for a shared information / aggregation system to prosper.

Consider the nature of the industry. Knowledge is power. If you're not all in a sinking ship together, why would you give up your competitive edge?

<comment><USER7> Re: nature of the industry -- i think there is more sharing that goes on. People send each other emails all the time. On a macro level, this stuff is already out there and so you expect the FIRM to be executing on it. The bigger question is for an individual trader or analyst (or associate) are _you_ up- to-date. So b-school classmates and friends from college help each other stay abreast of things, if nothing else as a safety net since it's always good to have friends at another building on the street.

<comment><USER8> well said. and i think that's the point. a centralized forum of like-minded people would be an invaluable asset. just remains to be seen whether the average finance person is too short-sighted / in need of immediate gratification to contribute and make it what it should be.

</comment></comment></comment><comment><USER9> I chuckled at this because of the recent "Wall St Traders = Hackers" post by Mark Cuban. Will be fun to watch how the format caters to the two if they really are so similar!

"The best analogy for traders ? They are hackers. Just as hackers search for and exploit operating system and application shortcomings, traders do the same thing. A hacker wants to jump in front of your shopping cart and grab your credit card and then sell it. A high frequency trader wants to jump in front of your trade and then sell that stock to you."

[http://blogmaverick.com/2010/05/09/what-business-is-wall- str...](http://blogmaverick.com/2010/05/09/what-business-is-wall-street-in/)

<comment><AUTHOR> Hackers care about reputation where Traders care about anonymity. The algorithms behind digg/reddit/HN is what makes them the best for finding good stuff. But maybe Traders are more like the douches that read TFLN and why anonymous voting might be a better idea than requiring log in

</comment></comment><comment><USER10> I liked newmogul, submissions were of good quality. Comments were of quality too, but had not yet reached the critical mass where a longer discussion can develop.

Problem with finance aggregrators is filtering the high quality articles, so much of finance writing is subpar.

</comment><comment><USER11> Something that could get me to participate is if I saw more technical articles and resources, rather than the same financial news I can find anywhere. That will limit your audience, but could help develop a community.

<comment><USER8> what exactly do you mean by more technical? technical as in finance-technical (mathematic, algorithmic trading, etc.)? or technical as in more related to the breed of content on YC?

<comment><USER11> I guess I meant the former, but both work. I've been building up a large collection of blogs with this sort of info for my own reading. (I've put some up on <http://quantblog.com/library> , but the whole site is still a work in progress). I can email you a larger list or post here if anyone is interested. Again, this caters to my interests, you may have other ideas in mind.

<comment><USER8> That would be really interesting -- I'd love your list, as I'm interested in many of the same areas. Much appreciated. I'm @ firstname.lastname@example.com

<comment><USER11> sent :)

</comment></comment></comment></comment></comment><comment><USER12> imho, The value of a community is in its members, not in the software. Sure, UI can have an effect on the ability to build a community, but only upon the edge cases.

What made HN successful isn't the presentation, but the character of its members and its association with Ycombinator.

Whether wallstbeat succeeds is more a function of its ability to attract valuable commentary and users willing to share analysis in a public forum. Failing this, it's vulnerable to the same pump-n-dump trash you see on Yahoo! finance and other sites.

<comment><USER13> I think you're right that the members of a community give it its value, but I think you underestimate the influence of the software. Consider it like the decor of a bar - once the regular clientele are established it becomes less important, but initially people are drawn there because they feel an affinity with the look and feel. IMHO of course.

</comment></comment><comment><USER14> There's no RSS feed.

<comment><USER7> <http://wallstbeat.com/rss>

</comment></comment><comment><USER15> UI sucks. Let me explain:

Hackers like plain boring lists (like HN and reddit) We do a quick scan and determine what is interesting or not in a second.

Non-hackers don't like plain boring lists, they like visuals, pics of the day, planes crashing, latest hairdos, etc.

So unless you put a couple of graphs and stats about the dow plunging, S&P in blood red, etc that site is just, booooring.

<comment><USER16> This site is for a crowd that spends a good amount of time watching stock tickers. If anyone other than hackers would appreciate a no nonsense interface, it would be the finance crowd.

<comment><AUTHOR> agreed. look at the bloomberg.com homepage. (hell, look at bloomberg terminal 20 years ago!)

banking analysts sit around all day and wait for their Directors/MDs to turn them work at 5pm. drawing attention away from "work" cuts into facetime. so something non-flashy might actually work.

<comment><USER17> Sorry for the accidental downvote. I was trying to upvote and missed!</comment></comment></comment></comment>


Thinking Psycopg3 - <AUTHOR> https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/ <comment><USER2> The biggest problem to be solved is that `pip install psycopg2` does not work out of the box in most cases; having to resort to the binary. I run into it with Flask and Django all the time. [https://www.postgresql.org/message- id/CA%2Bmi_8bd6kJHLTGkuyH...](https://www.postgresql.org/message- id/CA%2Bmi_8bd6kJHLTGkuyHSnqcgDrJ1uHgQWvXCKQFD3tPQBUa2Bw%40mail.gmail.com)

<3</comment>


The Unbearable Difficulty of Opting-Out - <AUTHOR> https://medium.com/p/72426b97e314/edit <comment><USER2> This wants me to login with twitter. facebook or google.

I'm not sure if this is intended to be the point or not.

Particularly given the article the web link finds: [http://www.sanspoint.com/archives/2016/06/23/the- unbearable-...](http://www.sanspoint.com/archives/2016/06/23/the-unbearable- difficulty-of-opting-out/)

If it was intended, perhaps some reference to what is going on would be appropriate?</comment>


Scaleway cloud provider object storage unsecure - <AUTHOR> At scaleway way, one key pair can access all your object storage s3 buckets with full read write access.<p>When I contacted their support to ask I got this brilliant conversation, enjoy
https://twitter.com/AKamelZAD/status/1117541887710302208?s=19 <comment><USER2> Hasn't it been removed? The link seems dead.</comment>


Show HN: URL shortner without Servier side processing, simple HTML-JS-CSS - <AUTHOR> https://github.com/bauripalash/fossurl <comment><USER2> Oh, it does have server-side processing, just not your own.

<comment><USER3> I was just going to say that. I'm guessing what was meant was maybe the redirection logic is all happening in the client, which is true. However, when you just read the title I assumed it meant everything, even the storage of the address itself, was being stored in the client. That didn't make sense to me, because you need to be able to share the links. Then I saw it was using jsonstore.io under the covers and the world made sense again.

<comment><AUTHOR> goal of my project was to build a url shortner which can be hosted even in GitHub/Gitlab without any need to buy a costly PHP or NodeJs or Other hosting.

</comment></comment></comment><comment><USER4> Couldn't anyone delete your entire database of URL's trivially? Seems like this would be pretty unsafe to use for anything.

<comment><USER5> No, because despite the deceptive title it does actually use server side processing. It relies on [https://www.jsonstore.io/](https://www.jsonstore.io/) for the actual data storage.

<comment><USER6> And the API key with write access is in the page source of the redirector, so it can do the lookup at jsonstore.io...

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

      Easy to use url shortner which does not need any fancy database or server side system

The project uses jsonstore.io as a backend. I think the author would agree that that's a "fancy database" by their own definition. Also jsonstore.io is not open source.

<comment><USER6> [https://github.com/bluzi/jsonstore](https://github.com/bluzi/jsonstore) \- but it relies on firebase, a non-open-source, even fancier database

</comment></comment><comment><USER8> I've implemented something like this before, instead of using jsonstore, I'm using goo.gl's api and adding a hash.

[https://chhota.ga](https://chhota.ga) \- it even works on custom domains with just one line of js.

<comment><AUTHOR> goo.gl is shutting down, i think you've to find other alternative api.

By the way if you have any ideas you can check my repo and contribute, we can work together to make it better.

I think we are almost at same age

<comment><USER2> goo.gl is shutting down, but is being replaced by some sort of Firebase URL shortener which also has an API, and uses goo.gl URLs.

</comment></comment></comment><comment><USER9> I was hoping for some kind of crazy compression. Dissapointed to find a state store after the headline.

</comment><comment><USER10> :/

It uses jsonstore.io for server side processing, I think the title is a bit disingenuous...

<comment><AUTHOR> Is there any URL Shortner which can be hosted at GitHub/Gitlab Pages?

<comment><USER11> I built [https://github.com/kshvmdn/point](https://github.com/kshvmdn/point) to do exactly this.

Only supports GitHub Pages right now, but might update it soon to support GitLab as well.

<comment><AUTHOR> When i started working on project, i found a stackoverflow thread where most of people said that using

<meta http-equiv="refresh" content="0; url=" /> can create lot of complexity</comment></comment></comment></comment>