Developing SaaS? Forget Scrum, Check Out Kanban and Similar Approaches - <AUTHOR> https://onsaasproducts.wordpress.com/2012/03/09/developing-saas-forget-scrum-check-out-kanban-and-similar-approaches/ <comment><USER2> Issues I've seen with scrum

1\. Ratcheting workload

Your sprint commitments are based on average past velocity. Because it is an average, half of the time, you take too much, and half the time you take too little. But no one likes schedules that are finished only 50% of the time, so teams push to reach commitments. Thus measured velocity is naturally much more prone to increasing than decreasing.

2\. Heterogeneous work

Scrum was created by engineers. Scrum treats each story as pre-dev, in-dev, or post-dev, and only estimates and plans the in-dev work. In the real-world, engineering is not the only work (or even most of the work!). Requirements, product design, UX detailing, quality assurance, marketing, and sales are no less of a feature than its engineering. "Okay," you say, "include these aspects in the scrum estimation too". But....

3\. Heterogeneous resources

Each story has a different composition of types of work needed. And each of these types requires a specialized skill set. Your blanket cover-all estimate will wind up with engineering-heavy, or UX-heavy, or QA-heavy sprints.

I would no sooner have an engineer market a product as a I would have a marketer engineer a product. But that's what scrum sprint estimates seem to imply.

4\. Uneven cadance

On the first day of the sprint, all devs are starting stories. On the last day of the sprint, all devs are ending stories. This causes uneven sense of cadence (I need to get this in), uneven needs (lots of QA, now!), and unnecessary contention (everybody merging, conflicts, breakage).

\---

To sum it up: At the end of the day, pipelines are simply a more accurate domain model.

<comment><USER3> Would you really have all of these "Requirements, product design, UX detailing, quality assurance, marketing, and sales" done by the same team? That is what your point two seems to imply and I have never seen teams structured like that before.

<comment><USER2> Agile teams are supposed to be "cross-functional", meaning they can define, build, test, and operate.

<comment><USER3> Cross-functional doesn't mean that the entire world is part of your team. Sales and marketing are stake-holders that work with the Product Owner to define a Product Backlog. They are not part of the Development Team.

</comment></comment></comment></comment><comment><USER4> One of the best lessons I've learned as an engineer manager (and former engineer) is to let the engineers drive the process.

Some teams will want to do scrum, some will want to do kanban, some will mix and match. Some of my teams have wanted a heavy process with actual planning poker cards, others just want a few standups and a simple retro.

The important thing is to communicate the needs of the other teams they'll be working with, and not demand the methods. Team boundaries are in many ways like API boundaries -- as long as you implement the interface, who cares _how_ you go about doing it. (As long as it isn't needlessly wasteful.)

I'm happy to offer past experiences and ideas when teams get wedged, but in general I've found everyone is happier and more keyed in when they've built the process we're all going to be working by.

<comment><USER5> Agree with letting the team choose and adapt it over time. Seems to correlate with my experiences and insights that I've cataloged here [https://leanpub.com/agileforleads/](https://leanpub.com/agileforleads/) ( <\- also FREE )

</comment></comment><comment><USER6> Adding a JIRA Kanban board has hugely improved my team's daily standups. Workflow goes: Backlog ⮕ Prioritized Backlog ⮕ Doing ⮕ Ready For QA ⮕ Doing QA ⮕ Ready For Release ⮕ Done, and there's a quick filter for each team member that will show only their tasks, as well as a major release filter.

In standup we have the board on a large screen and filter through by person. The difference is night and day. Standups have gone from vague "uh yeah I'm working on some 1.2 features" to snappy, concise updates that help focus the person on their daily tasks. You can see the switch flip in people's eyes as soon as their tasks are up on the board.

Project Management has essentially been reduced to prioritizing new tasks into the pipeline. It's wonderful.

<comment><USER7> I've got a similar setup in Trello that's really just for me and a couple other people. I'll have to look into JIRA, but I have a little bit of "what did I do before this?"

<comment><USER8> JIRA's query language is Turing complete[1], don't bother if you don't need an unrealistically huge amount of power over your data.

[1]: I don't actually know if this is true, but my point is it's way overkill for small projects.

</comment></comment></comment><comment><USER9> I'm sure this won't be popular with the devoted, but I find Scrum, Kanban and daily stand-ups a huge waste of time. It's funny how rigid agile becomes when you can make a lot of money making it rigid through consulting dollars.

<comment><USER10> Anything that's rigid is by definition not agile. For every practice it's important to understand the reason behind it and what it's supposed to accomplish, and then you can determine if that's something that you care to accomplish, or if perhaps there is a better way to accomplish it within your own team.

The converse is also true though. A lot of things will get resistance because people don't like to change, or they'd rather not leave their desk and talk to other people, or they only want to optimize for their personal productivity without considering the productivity of the team as a whole. That last one in particular is the source of a lot of friction with developers in my experience. Individuals like to optimize for their own personal productivity, and sometimes in order to increase the productivity of the team the individual productivity needs to suffer.

So as long as you're being mindful of your practices, what you're doing and why you're doing it, and looking to constantly improve the output of the team as a whole then feel free to adopt what makes sense and discard what doesn't work, and ignore anyone trying to sell you on dogma that they barely understand themselves.

<comment><USER5> > Anything that's rigid is by definition not agile.

Disagree only in that you need some rigidity for some time in order to get consistency and value. Agile dictates that this time-boxed rigidity should be routinely inspected and adapted over time. Does that make sense?

More of my views here [https://leanpub.com/agileforleads/](https://leanpub.com/agileforleads/)

<comment><USER8> Right, this is my view on agile. The only constant should be re-evaluation.

We started out differently than most teams, where we began with a very loose process and tightened it over time (as opposed to many who start out very rigidly and let them slack over time) and this has led to us:

1\. Predicting with surprisingly good accuracy (within 10% usually) how much work we can get done

2\. Spending only ~3 hours a week doing "rituals" (we do our stand ups in HipChat and we have two backlog grooming sessions a week; every other week we spend an hour for review/retro and an hour for planning), which gives us an overhead of ~8% time "wasted" doing our planning

3\. onboarding new members in only a couple of weeks; we plan so that they always join mid-sprint so that they get a solid week to just read up on our code and observe our process before jumping in for their first planning

4\. creating a really cross-functional "everyone works on everything" team; for my part, I spend most of my day in the weeds of Kubernetes for a variety of projects, but I'm able to cross-train on the other components my team works on, and I'm slowly teaching all of them K8s.

I won't call it "agile" because it's a dirty word apparently, but I really like it now that we've spent a few months hammering out the kinks.

</comment></comment></comment></comment><comment><USER11> Scrum fixed one of the biggest issues that came with it when it corrected loaded wording.

[https://www.scrum.org/resources/commitment-vs- forecast](https://www.scrum.org/resources/commitment-vs-forecast)

I totally agree that Kanban is _much_ better for SaaS development, but that small change corrects Scrum's biggest issue.

</comment><comment><USER12> It kinda depends!

If you have a small team, kanban is really great. It's easy to communicate what goals are; everyone's pretty aware of what is going on, development-wise, company-wise. You just need a good workflow, and that is what kanban is.

I like scrum more when you have a larger development team, because it's much _harder_ to communicate what goals there are. People are _less_ aware of what's going on in the platform, in the company, etc. The start and stop points in scrum are great times to reconnect and allow that communication to happen.

But, there are _lots_ of contexts, and lots of ways to solve communication problems, so it's really difficult for me to tell you what you should or shouldn't be using. It's almost more important to just have _a process_ that is clear to everyone so they know what their expectations should be.

<comment><USER13> I'd argue that Kanban doesn't prevent you from having regular points in which to communicate. It's just that the work itself isn't bound by those points.

Having worked both scrum and kanban, I feel kanban is better for both large and small teams, so long as the team puts some thought into which items each person takes out of the backlog.

<comment><USER12> I agree with you that the name itself (kanban) does not preclude one from having those regular times to get together.

People joke that nobody actually follows "Scrum" or "Kanban"; it's interpreted differently everywhere. I personally think that's a good thing, if it is done so in a directed fashion. (E.g.—don't estimate hours if that's not a useful thing to do for your team.)

Kanban and Scrum are themselves starting points, and perhaps a statement of where you align philosophically; in the end you are either using an agile process, where you kept what was useful or added what was needed, or you are in a muddle, where inefficient processes have crept in that are frustrating to the team.

</comment></comment></comment><comment><USER14> This may sound crazy but we manage our entire SAAS and open source project with GitHub Issues. We have monthly milestones and assignments and seems to work well for our team of 15 devs. Where we are hurting is managing multiple projects.

It would be awesome is if GitHub would allow us to set milestones across repos. Then we don't really need anything else.

<comment><USER15> There are tools to help you with multi repo GitHub issue management. A little bit of a plug but [https://codetree.com](https://codetree.com) is built to solve your exact problem - we sync up milestones (and labels) across many repos and allow you to visualize and work with cross-repo issues in either kanban or list view.

<comment><USER16> Right, we've been using ZenHub's issue board on top of our dozens of GitHub repos to do something that is Kanban-ish. It works well enough for the teams that actually want to follow a process.

With open source, it can be frustrating when other loosely coupled teams and silos have a dependency for a release, but their overall issue-tracking process is mostly an abandoned in place mock-up or fiction. If their repo is included in our board, their issues show up as noise across the whole pipeline. You start remembering to ignore certain issues that you know don't reflect reality, then ignoring everything for certain assignees or reporters, and eventually decide to toggle off their repo from your board view.

</comment></comment></comment><comment><USER17> Agile coach here.

Although I love Kanban this article is only half right. Scrum and Kanban solve two different problems and you might encounter either when developing SaaS. Let's get down to first principles.

Scrum is a batch oriented process. Batch processes are useful when the outcome of a process is uncertain and requires inspection and reconfiguration of the inputs after each batch until a stable and predictable process can be produced and the variables understood.

Kanban is a throughput oriented process. It is useful for reducing waste and optimizing for consistent and high output in a process where the inputs are _already_ well understood and the output is of a more consistent quality.

You can then imagine how at the start of things when you aren't sure how everyone is going to work together well, or when you introduce a new paradigm or technology to the mix, Scrum might make sense.

You can also see how a long running SaaS endeavor with incremental upgrades, no major changes to staff or technology, could use Kanban to increase throughput and reduce waste.

For more information please see the fantastic "Process Dynamics, Modeling, and Control"[0] who's author was consulted, ironically, in the very first Scrum book from Beedle and Schwaber.

The lack of science and first principles in the Agile space is why people say "agile is dead" and Agile coaches are treated like hacks.

This is my plea for more science and rational thought.

0: [https://www.amazon.com/Process-Dynamics-Modeling- Babatunde-O...](https://www.amazon.com/Process-Dynamics-Modeling-Babatunde- Ogunnaike/dp/0195091191)

<comment><USER18> FYI Kanban isn't a process according to Kanban author David J. Anderson: [http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanba...](http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanban+process+for+software+development).

<comment><USER17> The link didn't work for me but I can do you one better I have (saved somewhere) a Yahoo groups conversation where David goes on a tirade about exactly this.

Also, David can split hairs all he wants about this (as agilists love to do) but the process theory around this stuff was laid down long before he graduated high school.

</comment></comment></comment><comment><USER19> This should have (2012) at the end of the title.

</comment><comment><USER20> Once you're in steady state maintenance/incremental improvement mode, then sure, kanban is probably the appropriate approach. But for initial product development, and major new feature releases or product re-writes, scrum with its measured discipline and time restrictions is better. It's more difficult to force functionality/schedule tradeoffs with kanban. You simply end up reinventing scrum by grouping stories and imposing deadlines.

</comment><comment><USER21> "At no point in the execution of this Issue was it discussed by the team (neither in a daily stand-up meeting nor in any other meeting). In fact, any type of a team discussion would have probably doubled the overall time spent on this Issue."

This lack of ceremony sounds very refreshing.</comment>


'Most sophisticated mobile virus' starts spreading on Android smartphones - <AUTHOR> http://www.smh.com.au/digital-life/mobiles/most-sophisticated-mobile-virus-starts-spreading-on-android-smartphones-20101231-19bne.html

<comment><USER2> Sounds like a trojan, not a virus…</comment>


America's Industrial Revival - <AUTHOR> http://blog.tomevslin.com/2011/09/americas-industrial-revival.html <comment><USER2> >Improving standards of living in the third world

Rise in wages in China/Taiwan/India more or less follows wage rise in USA and EU and other developed countries.

 __* Downvote without an argument is downright irrational.</comment>


HackCampus Internship: A programme built by students for students in the UK - <AUTHOR> http://hackcampus.io/internship/

<comment><USER2> I really like this idea. I also really like the nav column.</comment>


Google Officially Launches Beta Music Service - <AUTHOR> http://www.macobserver.com/tmo/article/google_officially_launches_beta_music_service/ <comment><USER2> Thanks for sharing!</comment>


As Schools Shift to Google Apps, Blind Students Object - <AUTHOR> http://arstechnica.com/tech-policy/news/2011/04/as-schools-shift-to-google-apps-blind-students-object.ars

<comment><USER2> Google should be fixing some of these accessibility issues themselves. As for the actual GMail client though... nothing prevents the user from using the third-party client of their choice, so nothing has really changed from before.</comment>


Alfred 3 – Productivity App for Mac OS X - <AUTHOR> https://www.alfredapp.com/ <comment><USER2> It's a welcome upgrade from version 2, but I think Workflows and Snippets really could've done with a central hub for developers to upload and share their workflows/snippets, alongside a panel in Alfred to search and install them in-app (much like the 'Package Control' package manager on Sublime Text).

With the new Snippets Collections ([https://www.alfredapp.com/extras/snippets/](https://www.alfredapp.com/extras/snippets/)) page on their website the developers say they'll be 'adding many more snippets collections over time', but I feel like this is going to be heavily curated and infrequently updated.

The Packal ([http://www.packal.org/](http://www.packal.org/)) website does a pretty good job for Workflows currently, but I hope that expands to Snippets soon.

</comment><comment><USER3> It's pretty.... But..but I have linux.

<comment><USER4> Unfortunately I think Synapse [0] is your only option.

0: [http://lifehacker.com/5704221/synapse-is-a-super-fast- tightl...](http://lifehacker.com/5704221/synapse-is-a-super-fast-tightly- integrated-application-launcher-for-linux)</comment></comment>


Ask HN: I'm a successful founder biz-dev guy. Should I get an MBA? - <AUTHOR>

Back in 2008 my two best friends and I founded a startup straight out of college. It was tough, but earlier this year the venture started to really take off.
As the business guy for the startup, I would like to eventually transition to project management at a larger tech company. Since the startup is successful, I'm not in a hurry, this is more of a longer-term goal, which is why I'm thinking about MBA programs.
A family member who is a senior project manager at a large tech consultancy said I should just go to b-school right now because I will definitely need it. My cofounders disdain MBA programs.
I'm a light web developer, a designer, and I live and breath the internet, but I don't have any formal qualifications for the job, so I've been favoring the idea of getting an MBA.
Hacker news if full of people with more experience than I, so I thought I would ask and see if anyone would like to help a young grasshopper like myself. <comment><USER2> Business school and MBA are not the same thing. Have you considered an AA or BA in (say) accountancy, or finance and economics? You probably need to learn the nuts and bolts of corporate structure rather than the leadership and vision skills touted by so many MBA programs, which are geared more towards meeting the challenge of expanding/restructuring an existing organization. If you want to build your startup or move up to a corporate business job later, work on the foundation skills.

There's a great set of college review books from Barron's covering business basics, which are some stupidly low price like $12 a pop on Amazon: [http://www.amazon.com/s/ref=nb_sb_noss?url=search- alias%3Dst...](http://www.amazon.com/s/ref=nb_sb_noss?url=search- alias%3Dstripbooks&field-keywords=barron%27s+business+review&x=0&y=0) This particular series is produced to a much higher standard than their other study guides and seems to come from a different business unit - well written, properly proofread, and they make for accessible but challenging introductory texts. At this price, you might as well grab a few different volumes and see which ones you find especially interesting. You're a bit late if you were thinking of going to school this fall, so see where your curiosity leads you and then go into 2012 with a strategy.

</comment><comment><USER3> Have you considered a part-time MBA? This might fit your needs to keep working on your start up and at the same time working towards your MBA degree. Although I don't know your life circumstances, in general I would not recommend leaving a successful company. If you look at the MBA graduates many try to do what you do right now: start and run a successful business. UCLA and Berkley for example offer great part-time MBA programs.</comment>


Designing Genderless Emoji? It Takes More Than Just Losing the Lipstick - <AUTHOR> https://www.wired.com/story/designing-first-genderless-emoji <comment><USER2> What a load of fluff. I'm glad wired hasn't endangered it's preeminent position as the tech equivalent of the National Enquirer.</comment>


Agile Is Not A Panacea - <AUTHOR> http://www.eylean.com/blog/2013/03/passalong-founder-agile-is-not-a-panacea/

<comment><USER2> Nothing is a panacea if applied blindly</comment>


My First Game of Tic Tac Toe - <AUTHOR> http://fongchin.com/personal-coding-project-i-with-pusher-api/

<comment><AUTHOR> Haha great morning read. Keep up the good work!

</comment><comment><USER2> Love it!</comment>


Introducing Silent Diving Seagulls: An XMPP Interface for Desktop Notifications - <AUTHOR> http://blog.abi.sh/2009/silent-diving-seagulls/

<comment><AUTHOR> I'm the author of Silent Diving Seagulls and I just wanted to say something that I didn't include in the blogpost. I know, some of you probably think that instant Growl-like notifications are really distracting. I completely agree. Personally, I don't use notifications for emails or Twitter because it breaks my train of thought.

But one of the coolest things that could come out of having desktop notification support is this - say you have (1) a notification log and (2) a "Do Not Disturb" feature in your client. Then, if all your social networks like Twitter, Facebook, Wordpress start using it, you could easily have a neat log of all the happenings (sort of like mini personal FriendFeed). And we could go back to using email solely for 2-way communications. Email really shouldn't be used as a notification system. Email has been abused because it was the only easy solution in the past.

On a related note, Hacker News ought to notify you when someone replies to your comments or submissions.

<comment><USER2> This is awesome. We've been searching for a notification system for our users that is NOT e-mail for our product Ask My BrainTrust (<http://askmybraintrust.com>). For a product that tries to get you away from annoying e-mail threads, using e-mail as a form of notification seemed hypocritical. This would make an awesome alternative, especially since we already have XMPP baked into the backend.

<comment><AUTHOR> Great! Once we figure out how to handle authorization (suggestions?), I'll _email_ you. :P

</comment></comment></comment><comment><USER3> This looks amazing. We've been waiting for something like this that we can directly plug Fluther notifications into, without having to build and maintain our own desktop notification client.

Keep up the great work.

<comment><AUTHOR> Thanks, it would be awesome to integrate this with Fluther. But there's still a lot of work to make this work especially on the authorization front. Let me know if you have any thoughts on that. And would you be willing to send Fluther notifications to a public open source web service such as Growl.fm or would you, as a website owner, prefer to run your own XMPP server to pass notifications _directly_ to the user?

<comment><USER3> We already run a XMPP server for direct user notification.

I'm not familiar with Growl.fm, but I can say we're not at all ideologically opposed to using an open source web service. In general, we're looking for: \- Good UI/install for end users \- Minimal hassle to setup for us \- Sensible authentication

When you think it's ready for primetime, shoot me an email (ben [at] fluther.com) and we can talk about setting something up.

</comment></comment></comment><comment><USER4> I really hope one of these projects catches on. Notifications represent a gaping hole in browser functionality. Does anyone know if it's on the HTML5 radar at all?

We could definitely use this for ShopTalk (<http://shoptalkapp.com>). Keep up the good work.

</comment><comment><USER5> I desperately want _something_ like this to succeed before Twitter takes over the world and becomes the defacto standard with all it's closed, proprietary, single-vendor, feature deprived, insecure, unstable and unreliable patheticness.</comment>


When to Rewrite from Scratch – Autopsy of Failed Software - <AUTHOR> http://codeahoy.com/2016/04/21/when-to-rewrite-from-scratch-autopsy-of-a-failed-software/ <comment><USER4> Unfortunately this is a lesson that often has to be learned the hard way when you have a lead or team that lacks experience/wisdom. If you can survive that educational expense, you end up much better for it but it's painful nonetheless.

Aesthetics are never a legitimate reason to replace a functioning system with something else. I do not care how it offends the eye, the mind, the ear, or any other sensation you have... if it does not have a fundamental functional problem your best option is to maintain or plan an incremental rolling replacement that is tightly scoped at each step.

For large systems that do present functional problems, identify the egregious offenders in that system, abstract the entities/behaviors most responsible, and replace-in-place in a Ship of Theseus fashion. Despite how familiar you believe you are with a monolithic or complex inter-dependent system, you will discover how much you don't actually understand about how it works as a whole if you try and re-implement in its entirety.

<comment><USER5> I perpetually love the references to Ship of Theseus, and find it particularly applicable to this problem.

You mention fundamental functional problems, and I'd like to add something: sometimes it's not a functional problem, but a changeability problem. The code functions fine, but the process of adding a new feature is incredibly painful.

I've done big-bang partial rewrites of systems before, quite successfully, but I've got a Ship of Theseus rule of my own that I follow: no new features during the rewrite, and no missing features. The first example that comes to mind was a rather complicated front-end application that had become a total spaghetti disaster. It had been written using Backbone, and from my research it fit the Angular model of things quite well.

I took a pound of coffee with me out to the cabin for a weekend, and rewrote the whole frontend. Side-by-side. I started with the first screen, and walked through every code path to populate a queue of screens that were reachable from there. Implement a screen, capture its outbound links, repeat.

Nothing changed, but everything changed. The stylesheet was gnarly too, but I left it 100% untouched. That comes later. By keeping the stylesheet intact, I (somewhat) ensured that the new implementation used identical markup to the old system. The markup was gnarly too, but keeping it identical helped to ensure that nothing got missed.

48-72ish hours later, I emerged a bit scraggly and the rest of the team started going over it. They found 1 or 2 minor things, but within a week or so we did a full cut-over. The best part? Unlike the article, clients had no outward indication that anything had changed. There was no outcry, even though about a quarter of the code in the system had been thrown out.

<comment><USER6> A full rewrite absolutely should not be taken lightly (if ever). It's very much a last resort and something that requires deliberation and a clear path to success. You're spot on with your rules - nothing new; nothing lost.

I had a similar experience, sans the cabin. I was hired onto a startup that already had a functioning app in the wild. The API was written by one of the founders, who is not a developer in the professional sense, and holds my undying respect. As an early-stage startup with lots of ideas, we needed to move fast, and I wasn't going to be able to do so with the existing code base.

I stocked the fridge, locked myself into my tiny Brooklyn apartment, and got to work. I started by logging all requests to the API in order to ensure I had all the necessary endpoints covered. Then I wrote integration tests - <USER2> as an HTTP client - for the entire API.

About a week or so later, once the rewrite was finished, I added automated tests that compared the output between the two APIs, and once those matched perfectly, ran it live beside the original API (sending requests to both) and compared results from real requests to ensure there were no discrepancies.

Besides a couple very small bugs after the switch, it went very well. The user base was none-the-wiser, besides the sudden uptick in features after the rewrite. The startup was relatively successful (acquired), and I still work with those guys from time to time.

<comment><USER7> The thing that struck me is that they decided to rewrite the system without talking to the customer. I believe that if they kind of __sold __this first, they might have gone a different path.

</comment></comment></comment></comment><comment><USER8> I no longer believe in rewrites.

I used to believe that every company gets one rewrite, but only because I have seen that most places have the patience and the stamina for a little bit less than a single rewrite, but I was on the fence about whether they were a good idea anyway.

Trouble is, I could never put my finger on why, other than that it never seemed to fix the problem. It was a bit like moving to a new city to start over and finding out you brought all your problems with you.

In the last couple of years I have begin to figure out what I know in a way I can articulate. The people who have the skills and discipline to take advantage of a rewrite _don 't need a rewrite_. It's a short distance from that skill set to being able to break the problem down and fix it piece by piece. They just need permission to fix key bits, one bite at a time, and they've probably already insisted on the space to do it, although they may be clever enough never to have said it out loud. They just do it.

Then you have the people who don't have the skills and discipline to continuously improve their code. What the rewrite buys them is a year of nobody yelling at them about how crappy the code is. They have all the goodwill and the hopes of the organization riding on their magical rewrite. They've reset the Animosity Clock and get a do-over. However, as the time starts to run down, they will make all of the same mistakes because they couldn't ever decompose big problems in the first place, and they lack the patience to stick with their course and not chicken out. They go back to creating messes as they go, if they ever actually stopped to begin with. Some of them wouldn't recognize the mess until after its done anyway.

In short, people who ask for a rewrite don't deserve a rewrite, and would squander it if they did. It's a stall tactic and an expensive dream. The ones who _can_ handle a rewrite already are. They never stopped rewriting.

Now, I've left out all of the problems that can come from the business side, and in many cases the blame lies squarely with them (and the pattern isn't all that different). In that case it might take the rewrite for everyone to see how inflexible, unreasonable and demanding the business side is, and so Garbage In, Garbage Out rules the day. But the people with the self respect to not put up with it have moved on, or gotten jaded and bitter in the process.

<comment><USER9> This comment inspired me to recount a story from my time at Amazon: [https://storify.com/jrauser/on-the-big-rewrite-and-bezos- as-...](https://storify.com/jrauser/on-the-big-rewrite-and-bezos-as-a- technical-leader)

<comment><USER10> I'm a highly biased former Amazonian.

I was expecting some real wisdom in this story, but I don't think this qualifies him as a technical leader in any way. I don't even think this needed the cargo-cult-y "leaving the room and coming back with a paper that changes everyone's mind." Couldn't he have just asked for a plan? And the ROI? That seems like management 101.

I have no love for him, but he is a genius. This story doesn't do him any justice (nor is the paper particularly compelling).

<comment><USER9> My point was not to qualify Jeff as a technical leader (though he is an excellent technical leader, IMO). Rather, my goal was to give people a sense for his leadership style, and what it's like to be in a high level meeting at Amazon.

I'm sorry you find the Rickover memo uncompelling. Speaking as an experienced engineer, I happen think it's among the best pieces of engineering writing ever produced.

</comment></comment></comment></comment><comment><USER11> Software is re-written most often for political reasons, namely for new developers to leave a mark, and put a good line in their resume. Everyone likes to read "designed and implemented" on a resume than "maintained and fixed annoying bugs here and there". We know what looks better, managers know who they'd move to the next round, and so on.

The only thing is, if there is no software to be written software developers will always find a reason to write software. Because they get paid full time, usually above what other professions get paid, to well, ... write software.

I think other reasons such as "it is slow, outdated, not written in <latest- language-fad>, bad UI", are often brought up and used as excuses. But underlying reasons are a lot more personal and subjective.

</comment><comment><USER12> Ill-fated code rewrite crusades often seem to be linked with the Second System Effect ([https://umich.instructure.com/files/884126/download?download...](https://umich.instructure.com/files/884126/download?download_frd=1) ... page 55).

Excerpt:

 _An architect 's first work is apt to be spare and clean. He knows he doesn't know what he's doing, so he does it carefully and with great restraint. As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used "next time." Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system. This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable._

And from the OP, frill by frill :-)

 _I wanted to try out new, shinny technologies like Apache Cassandra, Virtualization, Binary Protocols, Service Oriented Architecture, etc._

To OP's credit, he took a step back and learned from his mistakes.

Also related... Second System Effect may not only apply for your second system ever. It may also bite you designing the second system in a new problem domain you're unfamiliar with. I can admit I've built a few second systems in my time ;-)

<comment><USER13> I hope/like-to-think that the second-system that focuses on architectural- features is better than the second-system that focuses on new user-features.

Stuff like "no global variables" or "actually use database transactions" or "support UTF-8"...

<comment><USER14> "Remember that time zones are a thing and not everyone is in America/Los_Angeles..."

<comment><USER15> That's why I personally love most european companies, as most just assume UTC.

<comment><USER16> The gold standard is software designed to be run near the North and South Poles, like snowmobile and ICBM navigation systems, which need to be able to switch between all time zones quickly.

<comment><USER17> Why would an ICBM need to use local timezones at all?

I can't imagine any teams up their using more than one timezone anyways. Perhaps UTC + their home zone?

<comment><USER18> After a 15-year career programming, I'm pretty sure the only sane way to handle timestamps is everything UTC server side, and let the UI convert to localtime on display.

<comment><USER15> Yup. That's also my solution. Sadly, we've had to deal with doing other things recently, too, as our software was run on servers with the timezone set to UTC, but the hardware clock being 3 hours ahead of UTC (this is common especially on old Windows installs).

The result was that the displayed time on the server was local time, but if we sent it to the client, we got 3h offset there as well.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> > _The development officially began in Summer of 2012 and we set end of > January, 2013 as the release date. Because the vision was so grand, we > needed even more people. I hired consultants and couple of remote developers > in India._

Well, that's already a warning sign. If you don't have the talent to do the rewrite, consultants and remote developers in India are only going to make things worse.

<comment><USER20> Wasn't the rewrite was a technical success despite warning signs?

The customer simply didn't want to adopt the shiny new software.

<comment><AUTHOR> The rewrite was a technical success. But we missed real business opportunities and completely underestimated the effort of building a new system while maintaining the legacy one in parallel. In short, we didn't prioritize and miscalculated big time :-)

The customer confidence in us had eroded because we weren't responding to their new feature requests in the legacy system. Plus their management didn't want to take any risks since the new system offered to new features to them and only benefited us.

<comment><USER21> What about responding to their feature requests... in the new system? !

Then they'd have the motivation to make the switch.

<comment><USER22> That's the problem. From my reading of the article, their client was, probably legitimately, concerned with the risk of a cutover to a new and unproven system.

To implement a new system the client always needs to do UAT. That's actually a drain on their resources, and if they have a working system it is far better to have incremental changes made and a regular set if bug fixes than to launch a new system, then find a raft of new bugs or unexpected changes that need to be fixed anyway.

Existing systems allow enterprises to operate effectively. New systems almost always cause unexpected disruption to a business regardless of efficiencies gained from the new system. And most IT systems are to support the objectives if the business, they aren't the actual objective if the business. A software development company can lose sight of this because it IS the objective of _their_ business :-)

<comment><AUTHOR> Good point. The UAT was definitely one of the reasons. It was several Excel spreadsheets long and scheduling it was a pain :-)

Also, it was a hosted service and client saw no value to them- just the pain. There was risk of service outage during the upgrade that would have had resulted in the loss of revenue. Also, the client had to provision extra resources to run Cassandra/SOA servers. In short, it was a lot of work for them with no benefit to them.

</comment></comment></comment></comment></comment></comment><comment><USER16> "While parts of code were bad, we could have easily fixed them with refactoring if we had taken time to read and understand the source code that was written by other people."

This is the thing. Many people just HATE and REFUSE to read other people's code.

Maybe they just don't teach code reading and reviewing in computer science classes, but they should.

Printing it out on paper and reading it away from the computer is helpful, but a lot of people write code for wide screens that doesn't print out well, or they just don't give a shit and it looks terrible even on the screen. And some people just don't have the stomach for reading through a huge pile of pages, or think that's below their station in life.

But reading code is one of the best most essential ways to learn how to program, how to use libraries, how to write code that fits into existing practices, how to learn cool tricks and techniques you would have never thought of on your own, and how to gain perspective on code you wrote yourself, just as musicians should constantly listen to other people's music as well as their own.

I just don't feel safe using a library I haven't at least skimmed over to get an idea of how it's doing what it promises to do.

There are ways to make reading code less painful and time consuming, like running it under a debugger and reading it while it's running in the context of a stack and environment, looking at live objects, setting breakpoints and tracing through the execution.

Code reading and reviewing is so important, and it should be one of the first ways people learn to program, and something experienced programmers do all the time.

And of course as the old saying goes, code should be written first and foremost for other people (preferably psychopaths who have your home address, photos of your children, and your social security number) to read, and only incidentally for the computer to execute.

<comment><USER23> > _Maybe they just don 't teach that in computer science classes, but they > should._

Should they? This seems like a classic conflation of computer science with programming. Perhaps the reason this important craft skill is not taught in CS is because it has nothing to do with complexity classes, automata theory, etc.

Programming != CS

<comment><USER24> It may be the case that programming is applied CS, and that a CS grad might therefore not actually be a decent programmer. However, employers are considering a CS degree as proof of competency in programming. So, if CS classes don't teach programming, then they're failing to provide what the expectation is that people have of that degree.

<comment><USER16> And they're also failing to educate their CS grads as well as they should. I think every CS grad should have a firm grasp of programming, and I'd consider a CS grad who doesn't know how to program to have a gaping hole in their education.

This notion of considering programming a "craft" that's below you gets at the attitude problem I think a lot of people (not just pure theoretical computer science graduate students) have towards reading other people's code.

<comment><USER23> Just to be clear. I don't consider it a craft that's below me, I'm a working progammer. I don't consider the use of the word craft to be in any way derogatory either. Quite the opposite. I have a knowledge base from CS and a knowledge base of craft skills that is derived from the practical professional application of the former. I consider these to be separate domains. The latter is not in any way a prerequisite for the former. The obverse may not be true. YMMV.

<comment><USER22> Given that all the things you list that are important parts of a Computer Science course are tools to create better software, why do you consider the ability to analyse and understand code as seperate from CompSci?

When you are working out the complexity of a program, you need to be able to read and understand it. It seems to me that if tiu are taught the fundamentals of CompSci, reading code and understanding good coding practices naturally are part of the subject matter you should be taught!

</comment></comment></comment></comment></comment></comment><comment><USER22> This is one of the reasons I love working on LibreOffice. I think most people acknowledge that LibreOffice is a pretty decent office suite. But it is just over 30 years old now and it has acreted massive amounts of legacy code, some questionable design decisions and in terms of often trying to track it in version control it can be a nightmare if you go back far enough.

But it would definitely be a mistake to rewrite it from scratch. There are millions of users who rely on it, and it's a massive code base that runs on three major operating systems - four if you include Android.

Instead, the LibreOffice developers are slowly working through refactoring the code base. They are doing this quietly and carefully, bit by bit. Massive changes are being done in a strategic fashion. Here are some things:

* changed the build system from a custom dmake based system to GNU guild - leading to reduced build times and improving development efficiency

* the excising of custom C++ containers and iterates with ones from the C++ Standard Template Library

* changing UI descriptor files from the proprietary .src/.hrc format to Glade .ui files

* proper reference counting for widgets in the VCL module

* an OpenGL backend in the VCL module

* removal of mountains of unneeded code

* cleanup of comments, in particular a real push to translate the huge number of German comments to English

* use of Coverity's static analysis tool to locate thousands and thousands of potential bugs most of which have been resolved

* a huge amount of unit tests to catch regressions quickly

This has allowed LibreOffice to make massive improvements in just about every area. It has also allowed new features like tiled rendering - used for Android and LibreOffice Online, the VCL demo which helps improve VCL performance, filter improvements which has increased Office compatibility and allowed importing older formats, a redesign of dialogue boxes, menus and toolbars which has streamlined the workflow in ways that make sense and are non- disruptive to existing users, and many more improvements which I probably don't know about it has slipped my mind.

But my point is - if LibreOffice had decided to do a rewrite it would have been a failure. It is far better to refactor a code base that is widely used than to rewrite it, for all the reasons the article says.

</comment><comment><USER25> True story. Similar start. A couple of enterprise customers, kludgy old code. Changeability was the problem. Decision made for total rewrite. Budget no probs, team of 10 allocated. I was the guy who sold the deals. Wanted to assess if we had a disaster on our hands. Asked CTO to explain how team was constructed. Here is how the conversation went:

Me: tell me about the team

CTO: well it is actually all being built by two guys.

Me: That's crazy. We have a 10 person team.

CTO: Actually I lied, it is actually all being built by one guy. Before you get me fired, let me explain. One guy just builds prototypes to keep all those idiotic requests from management.

Me: I knew the guy. Fastest damn developer on the planet

CTO: we just throw his code away. The other guy who we don't let you meet actually writes the code that works. You see nothing for weeks, then it emerges and works beautifully.

Me: what do you do with the other 8 guys?

CTO: give them make work to keep them out of the way.

The system was a market success for a long time.

<comment><USER26> That's fascinating, was everyone involved in on the deal, or how did they manage to keep that under wraps?

</comment></comment><comment><USER27> I rewrote from scratch once, after much deliberation and was successful. In my case, I had some extremely good reasons:

The original codebase was build using good old waterfall, where neither programmers nor testers had ever met a user in their life. So all the things that are good about working software kind of go out the window: There are a lot of abstractions in the code, but they didn't match the user's mental model, or helped in any way.

My users didn't like the software at all. It might have me their requirements in theory, but not in practice.

The team that had built the application was pretty much gone, nobody that had any responsibility in any design decision was still in the company.

I actually had managed to get access to people that actually used the software, and people that supported those users, so relying on them, I was able to get a model of the world far better than the original developers ever did.

300K lines of Java, written over three years by 10+ developers were rewritten by a team of two in three months. All the functionality that anyone used was still there, but actually implemented in ways that made sense for user workflows.

I'd not have dared a rewrite had the situation been better though: Working code people want to use trumps everything.

<comment><USER28> I have always felt that if you need more than 3 developers and 12 months then the software is too big and the scope needs to be cut down. Better a small program that does one thing well than a monolith that does everything badly - why do we never learn from the UNIX philosophy.

<comment><USER29> I think what you're referring to is what the kids call "microservices".

</comment></comment></comment><comment><USER30> Survived a complete rewrite for a client just now.

The previous team blindly relied on a single method from Spring framework's RestTemplate for every rest service calls with SAP backend.

        ResponseEntity<T> exchange(String url,
            HttpMethod method,
            HttpEntity<?> requestEntity,
            Class<T> responseType,
            Object... uriVariables)
            throws RestClientException

(ref: [https://docs.spring.io/spring/docs/current/javadoc- api/org/s...](https://docs.spring.io/spring/docs/current/javadoc- api/org/springframework/web/client/RestTemplate.html))

This forsed them to create object models structured to match the complicated and inconsitent request and response JSON strings that SAP used, instead of creating the objects modeled after the business domains. The result was no surprise was a disaster and the client wasted five months with them and I had to redo and complete the project still on time.

I still see many teams make their function signatures in Java so convoluted like below and don't know what hit them.

        interface ToDoService {
            ListToDoResponse listToDo(ListToDoRequest request) throws ListToDoException;
            AddToDoResponse addToDo(AddToDoRequest request) throws AddToDoException;
            .. and so on ..
        }

<comment><USER31> Can you shed some light on how to best solve this problem? I'm pretty much in the same boat with a restful service I depend on.

</comment></comment><comment><USER32> That guy really has a done a rewrite and then got it back to the point where it is used. That is what I felt when reading the article. Many people just rewrite and then complain that their rewrite never gets used. So they don't draw the important conclusions and the next time they will try it again. If you really push yourself, your team and the users to using the rewrite and getting it back on track with the original solution, then you have to go through all the disappointments of your rewrite not being better than the original, the real pains you induce in your users, and solve so many problems you've never signed up for solving because you didn't know that the old, ugly solution actually solved these as well.

The pain of reading, understanding and fixing/improving the old, ugly solftware is never that painful. And the value is much more immediate since your users already use and know the old software.

</comment><comment><USER33> I have incrementally refactored large codebases by committing to a guide of which constructs to replace with what, what is the final goal and writing test cases. Once the guide was seen beneficial by other developers, rather they were forced to use it, they were surprised how well that worked. All this was behind the scene from the customer and updates bugfixes were going out. Re- write may be the answer sometimes, many times, a well thought incremental re- factoring guide is an easier path.

</comment><comment><USER34> I'm facing this at work and wanting to rewrite, updates are to slow when one small change needs 1000 other changes in spaghetti code in piles of scripts...

Difference is we can roll our users over as they renew and in a year after release all new customers and old will have the same software.

Only about 2000 users not as big as a scale as the story here.

</comment><comment><USER35> Jeff Meyerson's interview with David Heinemeir Hanson [DHH] includes rewriting software. It discusses the reasons rewrites have a bad reputation and the difference between rewriting because "it's not my code/language/idiom" and declaring "technical bankruptcy" as an extension of the technical debt metaphor.

Agree with DHH or not, he's thought deeply about a lot of software development tropes.

[http://softwareengineeringdaily.com/2016/01/13/the- evolution...](http://softwareengineeringdaily.com/2016/01/13/the-evolution-of- rails-with-david-heinemeier-hansson/)

<comment><USER36> I listen to every DHH interview I can but his view on a rewrite is different than others that do rewrites. There is no "second system" per say in his world. He leaves the old system up for people that still think it works just fine. Instead of messing up the old versions with upgrades, they leave them up and if a customer wants to go to new version that is "rewritten" they can.

</comment></comment><comment><USER37> What are everyone's thoughts on rewriting in order to simplify your developer overhead with the likes of React?

We are a small shop and have a non-game app for html, ios, and android. The non-public (used by less than 30 people) backend has two management interfaces in, you might want to sit down for this, Adobe Flex. There are 2 full time developers (1 backend/flex/html and 1 ios/html) and 1-3 part time (android/ios) contractors depending on workload/deadlines. Everyone is pretty siloed with mostly 1 additional cross over app.

I have read articles similar to this as well as worked with some greybeards that carry this philosophy of staying the course and righting the ship rather than jumpin. However, this siren's song of React is luring me in with their philosophy of "learn once, write anywhere"[0]. Instead of siloed developers we'd simply have developers that would feel comfortable in [management interface/html/ios/android]

[0]: [https://facebook.github.io/react/blog/2015/03/26/introducing...](https://facebook.github.io/react/blog/2015/03/26/introducing- react-native.html)

<comment><USER38> Sometimes, you've got to dump the old stuff because it is just too painful to make changes on. I've rewritten more than a couple of projects that I inherited from less than competent outsourced contractors... Number one, these projects mostly didn't work, and had so many bugs that I'm not sure how it was ever shipped software that somebody paid for. Number two, it was all the worst kind of WebForms and Visual Basic monstrosity. I'm sure its possible to write non-terrible code with WebForms that looks good, but I've never seen it, and it was a matter of a couple weeks to burn it down and build a proper MVC application instead. My only regret there is that I waited too long to rewrite, and wasted a few months battling the manure pile of the old version and trying to improve it incrementally.

</comment></comment><comment><USER39> I want to try a re-write project at least once in my career. I've been thinking about how I might tackle it:

The legacy system components are unlikely to have ideal boundaries (unless you're insanely lucky) due to organic growth. So step 1, identify key boundaries and implement them as libraries / micro services / whatever makes sense.

Step 2, identify the highest value component to refactor - that might not be the part that makes the system go better for the users, it might be tackling the bit generating most support noise so you can free up more dev resource.

Begin the refactoring with a release, the new component begins life as a shim between the component interface and the legacy component, calling out to the legacy component for all features initially but as functionality is migrated to the new component it gradually uses the legacy component less and less.

You can always release at any time and you'll have a system using new code where it's written and falling back to old code where not.

Lather, rinse, repeat.

Key challenges I see during the refactoring are managing state during the refactoring of complex behaviors of the original component. It may lead to a private interface which is more granular but only exposed to the new replacement component.

Interesting stuff for sure.

</comment><comment><USER40> The only cases where I've seen rewrites work are when the software fails to consistently complete the task it was written to do. A lot of software is garbage but gets the job done. When you encounter hot spots its best to slowly refactor until you get the system where it needs to be. Lots of little changes mitigate risk, and it is easier to track down bugs if you make a mistake.

</comment><comment><USER41> Part of me was really hoping that some startup had written an MVP in Scratch and was seeing how far it could scale.

</comment><comment><USER42> I don't believe in rewrites. But I believe in the evolution of the understanding, what a system is supposed to do and how to do it.

A customer might have a lofty web-scale vision, the first version is built with all scaling and no maintenance in mind. You are then faced with a decision: carry along the visionary nightmare and get almost no real work done, because the system itself is in the way, or rewrite the system with a fresh, minimal approach, focusing on a valuable target.

The point being: Software requirements evolve and sometimes, writing a first version of the software is the spec itself. Just as with specs, you can try to scavenge all good things from the previous version for the next one - <USER3> actually getting better over time, despite being in a rewrite mode.

</comment><comment><USER43> The new Software Development Manager always wants to rewrite the code from scratch. That's the way it's always been. I like that the guy who wrote this post had the courage to admit that he was motivated partly by the desire to play with new tech. reply

</comment><comment><USER44> I recently faced the decision whether to rewrite

I took over a rails + angular 1 codebase from another developer who left the company. I would be working on the project for few months.

I rewrote the entire app with Meteor + React in few weeks. Best decision I ever made. Even though the app has same features, customers say the app is faster, has less bugs, and overall feels more solid. Security is also better because of the pub/sub system. It also gave me a chance to fully understand the ins and outs of the database and how the app works.

I can also develop features much faster with Meteor + React than with Rails + Angular 1. So time spend re-writing is saved by enabling faster feature development.

</comment><comment><USER45> > The development officially began in Summer of 2012 and we set end of > January, 2013 as the release date.

This is the problem right there. In my experience, successful rewrites only happen when they get done quickly. If you know exactly what you're re-writing, you can get it done within a few days. If you have no idea what you're doing and think it'll take more than a week, it will probably end in failure. The truth is, I re-write code almost every day in my programming life. I usually don't realize I'm rewriting something until after the fact.

</comment><comment><USER46> "Incremental change is always better for testability and validating the existing features"

\- from _97 things every programmer should know_

</comment><comment><USER47> Interestingly I've hardly seen this 'rewrite' vs 'no rewrite' debate regarding to microservices, with all the talk about them.

In theory it shouldn't be more work (as they are supposed to be so small) than some refactoring in your old (big) piece of software, and you can even rewrite it in a different language.

</comment><comment><USER48> I think there are only two reasons to rewrite.

1) When you need to support a different platform, ie we have a Windows Desktop app and want a Web or Mobile or Mac.

2) When the code base is so bad adding any new features creates many time more bugs.

</comment><comment><USER49> A lack of design skills and code-cleaning skills can mislead you into thinking "the code needs to be rewritten from scratch".

However, as the new code grows, you're going to need badly these very skills anyways.

</comment><comment><USER50> This is why all developers should build their own framework from scratch in their spare time... It scratches the itch and helps one appreciate existing software.

</comment><comment><USER51> "and changed our protocols to binary, all at the same time. "

What does the author mean by that statement?</comment>


ACLU exposes Facebook, Twitter for selling surveillance company user data - <AUTHOR> http://arstechnica.com/tech-policy/2016/10/aclu-exposes-facebook-twitter-for-selling-surveillance-company-user-data/ <comment><USER2> This is a very messy, multi-layered issue.

First of all, a large part of a social network's utility is derived from sharing data about oneself. This data is public, for the benefit of other participants of the social network. Some of those participants may have agendas that are contrary to one's own: stalkers, adversaries, data aggregators -- it's impossible to know all of them ahead of time, and a granularity of permissions that satisfies these competing goals is... tough.

Second, it ought to be a person's reasonable expectation that law enforcement is a benevolent actor. Actions such as this, which amount to targeted crowd surveillance, don't instill much faith in this assumption. This is a very serious issue that merits more discussion than my terse comment.

Lastly, this data aggregator should not be the target of the outrage. They're an intermediary in a system where we willingly share data with private companies to get some value-add, who then sell that data to fund their operations, and some of the purchasers of our data happen to be law enforcement. Anger directed at any particular intermediary -- like anger at reposessors or ambulance chasers or debt relief counselors -- is woefully misdirected; we should instead be asking why corporations feel the need to sell our data in the first place, and why we have law enforcement that feels the need to employ mass surveillance. If we ponder these questions, we'll have accomplished something more than drive an inconsequential company out business while leaving the systemic faults in place.

<comment><USER3> >Second, it ought to be a person's reasonable expectation that law enforcement is a benevolent actor.

I totally disagree. Care to expand on that?

<comment><USER4> I think the point is that police etc should not behave in such a way that many people immediately assume that an encounter would likely be antagonistic.

Basically, if you're afraid to go ask a police officer for help (which, apparently, is fairly common among black people in US, for example), then something is very wrong about police, and needs to be fixed.

<comment><USER5> It's worse than that. Some prominent lawyers advise that everyone should never talk to the police.

<comment><USER6> Which is very good advice, but it's because of the fact that testimony given to a police officer can only ever be used _against_ you (it's hearsay otherwise). Not to mention that if someone slips up and accidentally tells a lie in the middle of a testimony, that instills doubt in the entire testimony ("I didn't kill her, I've never killed anyone, I've never even used a gun, I wasn't in the area that night" sounds fine until the last part if it turns out you were in that suburb that night).

Basically, to a lawyer a client talking to the police is giving the prosecution ammunition. Not to mention that nobody (not even the supreme court) can claim to know every federal law that applies to a person at a particular time (there was a quote for that but I can't find it on my phone right now).

<comment><USER7> _Which is very good advice, but [..]_

Wrong conjunction? It seems like you're explaining why it is good advice, not offering an opposing view.

I think you have given a perfect illustration of the GGP's assertion that "if you're afraid to go ask a police officer for help [..] then something is very wrong about police". This is a good example where the law sets up the police as antagonists against the general population.

<comment><USER6> My point with the "but" was that the reason why lawyers advise this is not because police are trying to harm you. It's because in general, people are very bad at law and providing testimony. So maybe I should've clarified that -- the police are not at fault for doubting flawed testimony.

To be fair, police do engage in manipulative tactics in questioning, but that's kinda their job. The job of the person being interrogated is to ask for your lawyer and say nothing else.

<comment><USER5> It's good to keep in mind how police are incentivized. They are paid to arrest suspects and close cases. Whether or not they nab the wrong person hardly matters to them. So although they generally may not intend to harm you they will gladly do so if it increases the numbers on which they are graded. And if you happen to have some cash on you when you make the mistake of talking to them then there is the bonus opportunity of asset forfeiture.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> [https://www.aclu.org/blog/free-future/facebook-instagram- and...](https://www.aclu.org/blog/free-future/facebook-instagram-and-twitter- provided-data-access-surveillance-product-marketed)

Instead of ArsTechnica, why not link to the ACLU's website?

<comment><USER9> > Instead of ArsTechnica, why not link to the ACLU's website?

I prefer journalism to the original source's post. The ACLU is an advocate for its cause; a secondary source can provide context, other sources, opposing points of view, etc. For example, compare a post by a political candidate, with its natural extreme bias, to a newspaper article about it, which includes fact-checking, expert analysis, their opponent's reaction, etc.

That's the reason Wikipedia requires secondary sources for its citations and forbids primary sources.

EDIT: Fleshed it out a bit.

</comment></comment><comment><USER10> If the data is public, why is it a problem? If they're sending private info to cops, that's different, but a reasonable person expects all public info to be visible to the last person you want to see it. Theyre just feeding the customers the same data users can see in a more condensed form aren't they?

<comment><USER11> This conflation is made too often. I think the problem with the assumption that if someone made something public willingly they don't care is if people knew they are under surveillance they may not speak their mind, or speak at all.

If people who use the internet expect all their activities to be logged and mined for patterns that can potentially be used against them, they may behave very differently.

Since we all act in self interest this means no one will speak freely. This is what surveillance does, this is what the chilling effect is.

This reduces the value of the internet for the free exchange of ideas and discussion. People who seek this will have to resort to encryption and other tools and forced to behave in a secretive fashion as if they were doing something wrong.

Protests and activism are supposed to be normal part of every democracy and its disconcerting the see the strange discomfort our 'democratic societies' show to activism and the sheer amount of effort devoted to managing it from infiltration to surveillance.

<comment><USER6> > If people who use the internet expect all their activities to be logged and > mined for patterns that can potentially be used against them, they may > behave very differently.

Unfortunately you see this already. Though usually people are worried about adversaries taking screenshots of conversations out of context and then painting them in a negative light, not the government doing that. But ultimately it's the same issue, there's a chilling effect on speech which is caused by the overwhelming fear of mass surveillance.

</comment></comment></comment><comment><USER12> I laugh at twitter playing stupid to what their information was being used for.

Government loves its surveillance. Try this though, if you live next to a cop, FBI agent or public official place a high res video camera on your property facing their house and leave it live streaming. Post it to a website with photos of all their family and children, their license plate numbers the time they leave for work etc. All things that are publicly available and captured from a simple video camera. Start having multiple people do the same and locate it all on your website. Then watch how fast the hypocrisy rears its head.

</comment><comment><USER13> It's interesting to note that in some cases the data was being fed through an intermediary... who's to say there aren't other integrations doing the same thing?

</comment><comment><USER14> > ... The companies need to enact strong public policies and robust auditing > procedures to ensure their platforms aren't being used for discriminatory > surveillance."

Hm, is it okay to use it for non discriminatory surveillance? Can there ever be surveillance that is not discriminatory since the surveying entity is usually has no interest of surveying itself and to provide that data to the public.

</comment><comment><USER15> from a story posted yesterday about the CIA crunching data to predict social unrest, it is fairly obvious the feds have access to social media firehoses

[https://www.engadget.com/2016/10/05/cia-claims-it-can- predic...](https://www.engadget.com/2016/10/05/cia-claims-it-can-predict-some- social-unrest-up-to-5-days-ahead/)

</comment><comment><USER16> I find it strange that it would be perfectly OK to sell this data to a commercial entity, but it's not OK to sell it to the government.

<comment><USER17> I think that what the buyer _does_ with the data has a lot to do with this. They would be in even more trouble if they had sold the data to a private mercenary firm who takes out contracts on business rivals, for example. Conversely, if they had been selling to, say, the U.S. Census Bureau or FEMA, they would likely be lauded.

It does say a lot about how little people trust the police these days, though.

</comment></comment><comment><USER18> As a non-native speaker this headline took me way too many attempts to parse correctly. For anyone wondering the same, it's meant to be read as:

ACLU exposes Facebook and Twitter for selling user data to a surveillance company

The way I read it the first few times I thought they sold user data _of_ a company, _for_ surveillance.

<comment><USER19> As a native speaker, it's a poorly written headline.

One term for this form of misleading / confusing sentence (and especially headline) is a "crash blossom".

[http://www.quickanddirtytips.com/education/grammar/fun- with-...](http://www.quickanddirtytips.com/education/grammar/fun-with-crash- blossoms)

[https://en.m.wikipedia.org/wiki/Syntactic_ambiguity](https://en.m.wikipedia.org/wiki/Syntactic_ambiguity)

<comment><USER18> I think in this case it's made worse by the wording "selling X Y" as a substitute for "selling Y to X" being relatively rare and in this case both X and Y being compound words (surveillance company and user data).

So not only is it a crash blossom in the sense that it's ambiguous whether it's [surveillance] [company user data], [surveillance company] [user data] or [surveillance company user] [data], but it could also be read as [surveillance company user data]. There are at least four possible ways to attempt to parse the sentence and the only one that makes sense relies on unusual phrasing.

</comment></comment></comment><comment><USER20> I'm pretty sure I have seen other apps do similar things. The data they are feeding them does seem to be mostly public data. I'm not exactly sure how I feel about this, or how outraged / surprised I should be.

<comment><USER21> Just because the data is public doesn't mean it can be easily accessed or aggregated en-masse for real time survellience.

If Geofeedia was only using public data, easily available to anyone else, then Twitter and Facebook wouldn't have been able to cut off their access.

<comment><USER22> "Public data" doesn't mean easily accessible.

Twitter sells access to their data. They can cancel that account, but the data is still public. Without the access contract it is inconvenient and against the terms of service to access in bulk.

</comment></comment></comment><comment><USER23> I love that "user data sales" has become such a normal thing that when someone stops selling it to ONE company out of like several thousand, it's considered newsworthy.

</comment><comment><USER24> Here's Geofeedia's response: [http://blog.geofeedia.com/a-commitment-to- freedom-of-speech-...](http://blog.geofeedia.com/a-commitment-to-freedom-of- speech-and-civil-liberties)

</comment><comment><USER25> Shame on Facebook! Shame on Instagram! Shame on Twitter! I consider this a despicable act on the part of these companies. They stopped this data selling only because they were caught. Using data internally to feed to algorithms to show targeted ads is one thing (though privacy wise it's bad). Selling data outright to other companies is a terrible state of affairs. It's sad that this won't make a big dent in the user base or make people flee these platforms in large numbers.</comment>


Show HN: Funk – a toolkit for using PHPSGI stack (middleware, http servers) - <AUTHOR> https://github.com/phpsgi/Funk <comment><AUTHOR> Funk implements PHPSGI specification (the PHPSGI repository contains middleware/app interfaces implemented in both PHP and Zend Extension)

[https://github.com/phpsgi/phpsgi](https://github.com/phpsgi/phpsgi)</comment>


Should Net Neutrality Apply to Google, Facebook, Etc? - <AUTHOR> I understand that Net Neutrality prohibits internet service providers like AT&T, Comcast and Verizon from speeding up, slowing down or blocking any content, applications or websites you want to use. What about for content providers like Google, and Facebook? Would they be held to the same standards? Would Net Neutrality prevent Google from speeding up, slowing down or blocking any content, applications or websites? If it doesn't, should it? <comment><USER2> By law, no - since these aren't ISPs.

However, they're a monopoly in their own vertical.

1\. Apple often gets away with anti trust behavior by calling itself a phone maker. However, in the "app store" category Apple is a clear monopoly - because not being on the app store can adversely affect your bottom line.

2\. Google can bury you in search results if they dislike you, just ask protonMail

3\. Amazon can delist you from the only online marketplace that matters.

Clearly, these companies are monopolies in their own verticals, and regulators aren't really protecting smaller companies against them</comment>


NEM had a flawed ICO that left hundreds without their coins - <AUTHOR> https://forum.nem.io/t/not-claiming-nemstake-why-it-is-no-longer-possible-and-the-history-of-the-process/2859 <comment><AUTHOR> My twitter([http://twitter.com/pontifier/](http://twitter.com/pontifier/)) has links to many discussions about this by many of the people who did not get their coins. I also flew out to an event to ask the VP of the NEM foundation about it. He acknowledged the issue, but refused to make any attempt to fix it.</comment>