Link Dumps

[simontegg]

No description provided.

[simontegg]

http://lowrekey.github.io/fourd.js/
https://developers.google.com/chart/interactive/docs/gallery/orgchart
http://techcrunch.com/2015/04/28/facebook-api-shut-down/?ncid=rss#.pnrnmr:NEcQ

[simontegg]

http://99designs.com/designer-blog/2014/01/15/7-unbreakable-laws-of-user-interface-design/

[simontegg]

https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html

"Because of multiple round-trips and over-fetching, applications built in the REST style inevitably end up building ad hoc endpoints that are superficially in the REST style. These actually couple the data to a particular view which explicitly violates one of REST's major goals.
"

[simontegg]

Alan Kay on messaging:
http://c2.com/cgi/wiki?AlanKayOnMessaging

Hacker News discussion on Diaspora's 0.5 release:
https://news.ycombinator.com/item?id=9482469

[simontegg]

Compare and contrast:
Rich Hickey - Hammock driven development
Peter Hintjens - Simplicity Oriented Design
Mary Poppendieck and Tom Poppendieck - Lean Software Developent
Audrey Tang - Optimise for fun

[ahdinosaur]

http://www.slideshare.net/alvarosanchezmariscal/stateless-authentication-for-microservices

[simontegg]

http://sahandsaba.com/nine-anti-patterns-every-programmer-should-be-aware-of-with-examples.html

[simontegg]

http://bigeng.io/post/118399425343/why-the-way-we-look-at-technical-debt-is-wrong

[simontegg]

Hacker news on "the failure of agile"

https://news.ycombinator.com/item?id=9538858

[simontegg]

interested in your take on this one @ahdinosaur @joshuavial http://martinfowler.com/bliki/MicroservicePremium.html

[simontegg]

http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
Martin Fowler's original take on micro-services http://martinfowler.com/articles/microservices.html

[ahdinosaur]

@simontegg i agree that microservices have a cost, which is why i started Holodex as a monolith and would recommend doing so for any project in the 'make it work' phase of development. the problem is that the longer a project remains a monolith (especially if it increases scope to include any dependency services), the harder it is to split out later. an open question that was brought up in the articles is 'what's the right size of a microservice?'. should Holodex be one service, many services? and that's not even mentioning the question of Holodex's scope.

the approach i'm taking by intuition: clearly define the scope of the project, start building a monolith to solve this scope, then as things start to work split things out into re-usable modules and eventually de-coupled services, and if your scope ever requires another scope (Holodex will soon require authentication (who you are) which i've defined as out of scope for Holodex) please take the extra effort now to add it in a somewhat de-couple'd way as otherwise it's gonna be much more expensive to de-couple later, plus it's best for the ecosystem as a whole to have more re-usable services for common app dependencies.

that's a bunch of rambling, does that help at all @simontegg?

[ahdinosaur]

in the broader app ecosystem perspective, i'm okay if an app is grossly monolithic the first time some problem is solved (e.g. Loomio which is (should be?) scoped to discussions and decisions but also includes authentication, user profiles, groups (admins, memberships, invitations, profiles, child groups), notifications, etc.) but when it's the second time around (e.g. Cobudget which is (should be?) scoped to group crowdfunding but also includes authentication, groups (admins, memberships, invitations)) i find it harder to swallow, as i reckon that's when we should be putting in the extra effort to make the solution re-usable and de-coupled so that we solve the problem for good, not just until we want to build another app.

[simontegg]

http://www.slideshare.net/neo4j/raph-visualization-unpicking-the-hairball-joe-parry-graphconnect-london-2013

[simontegg]

http://www.inf.uni-konstanz.de/gk/pubsys/publishedFiles/NoOrBr14.pdf

[simontegg]

In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams.

http://www.upedu.org/papers/ICSE2015_OrganizationalFactors/LavalleeRobillard_ICSE2015_WhyGoodDevelopersWriteBadCode.pdf

[simontegg]

I think there are a lot of conflicting ideas at play here. As a coder, yes I can write good code. But however, everyone I know in the valley tells me "just shut up and launch, it doesn't have to be good. You should have launched yesterday, that's what they would have told you at YC". This advice have a lot of truth to it, because you need to get feedback, validate your project, and perhaps have the first-to-market advantage in the highly competitive world of technology today, with investors and customers hounding you on both sides. However, this hasty, rushed culture necessarily will result in a lot of poorly-written code being deployed (followed by a lot of rewrites), even by decent coders, because they simply aren't given the time and runway.
reply

The situation is very different when creating software for internal use in large corporations, which I think was the case with this study. With a startup, launching early can get you the advantages you mentioned, and your code quality does not necessarily have to be high because you generally will not have many users at the start. Large internal software must be highly functional and performant from the first deployment because it will immediately be used by the whole company and will often affect revenue streams. This allows low quality to have a huge impact from day 1.

https://news.ycombinator.com/item?id=9565218

[simontegg]

http://hepburndata.blogspot.co.nz/2011/12/perspective-is-everything-why-even-most.html

[ahdinosaur]

http://makerbook.net : hand-picked directory of the best free resources for creatives.

[ahdinosaur]

from @simontegg, http://conceptviz.github.io/#/e30=

[ahdinosaur]

http://zguide.zeromq.org/page:all#Chapter-The-ZeroMQ-Community

[simontegg]

With ZeroMQ, we said we were going to make "the Fastest. Messaging. Ever.", which qualifies as a good motivator. If we'd said, we're going to make "a smart transport layer that'll connect your moving pieces cheaply and flexibly across your enterprise", we'd have failed

Then your work must be beautiful, immediately useful, and attractive. Your contributors are users who want to explore just a little beyond where they are now. Make it simple, elegant, and brutally clean. The experience when people run or use your work should be an emotional one. They should feel something, and if you accurately solved even just one big problem that until then they didn't quite realize they faced, you'll have a small part of their soul.

Oh, yes

[simontegg]

I think this is going to be important now and in the future. Systems are getting so complex nobody can build something complete from scratch. I see people making high quality components and then merging or being acquired to create a whole end user product. Prior to that point, you'd have something that's not very profitable unless lots of companies license your component and do integration themselves.

So, an interesting thing I observed while building a SaaS company was that you can actually get off the ground with a very simple solution, you'll just end up serving smaller customers with relatively simple needs (say $50-100/mo.) These initial folks will pepper you with feature requests while still paying you money for what you've got, which can give you feedback about which complexities you're missing that you really need to implement. If you choose which things to implement carefully, you end up making your product more useful to larger customers and you'll start closing some larger deals. (E.g. $500/mo.) Rinse and repeat and before too long you've got a product with all the bells and whistles and you're closing enterprise deals. (E.g. $2,500+/mo.) The numbers here are all relative, but the point is that the smaller customers end up subsidizing the development of what becomes an enterprise product.
(I think the advantage this approach has over the one you've suggested is that the product is always capable of making money even from the very beginning, just on a smaller scale at first. I think this is a critical feedback mechanism so that folks know whether what they're developing is actually useful to folks.)

https://news.ycombinator.com/item?id=9589202

[ahdinosaur]

from Ants, ‘the future of work visualisation'. note the pricing is $13/user.

[simontegg]

http://www.coppelia.io/2012/06/graphing-the-history-of-philosophy/

[simontegg]

via @rdbartlett

Yeah I wanted to track plans vs reality. Now I have come to terms with the fact that I hate plans. Agreed objectives + high communications + small tasks suits me much better. Seems much more efficient to invest in making people feel nice at work than it does to invest in highly detailed plans and roles and tracking

However I am revealing my 'full timer' privilege. People working multiple simultaneous contracts can't play it quite like that usually

[rdbartlett]

Yeah I keep re-learning over and over: information scarcity is the justification for command and control hierarchies >> information abundance creates opportunity for nonhierarchical organisation >> but it only works if you actually do the information abundance bit!!

[simontegg]

http://www.kennybastani.com/2015/05/graph-analysis-microservice-neo4j.html

[simontegg]

http://rhiever.github.io/redditviz/clustered/

[simontegg]

https://github.com/stuarthalloway/presentations/wiki/Narcissistic-Design

[simontegg]

@ahdinosaur gratipay/inside.gratipay.com#421

[bhaugen]

That (the gratipay conversation about maybe joining Enspiral) is really exciting. Please keep the valueflows gang informed? It's all part of the same convergence. Maybe.

[simontegg]

http://evelinag.com/blog/2015/12-15-star-wars-social-network/index.html#.VnnBZezLGc0

[bhaugen]

Wow. I assume that was a labor of love...but what a lot of both!

[bhaugen]

http://www.enliveningedge.org/news/holacracy-makes-the-leap-to-open-source-and-zaps-the-painful-legalese/

[simontegg]

https://twitter.com/leashless/status/685695315249377280

[ahdinosaur]

http://www.infoq.com/articles/no-more-mvc-frameworks

[simontegg]

https://medium.com/the-ready/the-org-chart-is-dead-e1d76eca9ce0#.tp3e1re6n

This tool would be a living, breathing org chart — a dynamic network — combined with what I’m calling “GitHub for organizations.” What roles exist inside our companies? What rules? What policies? Who has authority? Even if the answer is “everybody” (heck, especially if it’s everybody) we need to know. We need a tool that helps us change those things, edit those things, and share those things inside and outside our companies— easily or automatically. Imagine if you could take your world-changing maternity/paternity policy and share it with a friend’s company with one click, like a developer sharing code on GitHub. Now imagine millions of companies sharing what’s working for them, seamlessly.

[bhaugen]

Looks like holodex to me. The author has apparently not caught on yet.

[gcassel]

^ agreed... and I find it somewhere between amusing and horrifying that they're openly trying to get funded by describing it as a billion dollar idea.

[simontegg]

The trouble with the expedient path and building for ourselves https://medium.com/swlh/the-surprisingly-simple-thing-slack-got-wrong-b16f489395e#.jge16ohq8

[simontegg]

https://twitter.com/KentBeck/status/704452340397404160

early product development is more productively seen as answering a sequence of questions rather than filling a sack with features

[gcassel]

^quite concise and clear

[simontegg]

http://www.ribbonfarm.com/2016/03/17/go-corporate-or-go-home/#more-5345

[simontegg]

https://ventrellathing.wordpress.com/2013/06/18/the-case-for-slow-programming/

[don-smith]

Great link @simontegg. That definitely resonates with me on the last project I did. Oddly, the customer didn't seem like they were in a big rush, so I took the extra time (staying within the budget) to apply more refactorings ... a bunch of them. The result? A codebase I can honestly say I'm proud of. Based on the requirements, I knew exactly how the codebase will evolve and I designed it so those evolutions will be as easy and straightforward as possible. I attribute the quality of the codebase on my ability to go slow. And, it was a wonderful experience for me, and the customer is thrilled with the quality. Highly recommended.

[gcassel]

^ quite heartwarming :) thanks for sharing @locksmithdon !!

[robguthrie]

Hammock Driven Development has been shared around these parts already,
right?
https://www.youtube.com/watch?v=f84n5oFoZBc

On Sat, 30 Apr 2016 at 14:20 Greg Cassel notifications@github.com wrote:

^ quite heartwarming :) thanks for sharing @locksmithdon
https://github.com/locksmithdon !!

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#60 (comment)

[simontegg]

http://pchiusano.blogspot.co.nz/2013/05/the-future-of-software-end-of-apps-and.html

[simontegg]

We are going to build native apps because it turns out, it’s cheaper. It’s cheaper to build multiple proprietary applications than one responsive web app.

https://hueniverse.com/2016/06/08/the-fucking-open-web/

[simontegg]

Roads and Bridges: the unseen labor behind our digital infrastructure (pdf)

[simontegg]

In one study (Barrow and Neville, 2001) People preferred traditional org charts and icicle plots to treemaps and tree ring charts for hierarchical data https://medium.com/@kennelliott/39-studies-about-human-perception-in-30-minutes-4728f9e31a73#.3m8kuq4f3 (scroll to halfway)

cc @ahdinosaur

PS starting to stew on holodex reboot

[fosterlynn]

PS starting to stew on holodex reboot

cool!

[ahdinosaur]

"Replacing The User Story With The Job Story" @simontegg

[simontegg]

https://justinjackson.ca/saas/ SaaS is ripe for disruption

[simontegg]

Ask HN: What's the best 'non-frustrating' search/directory UI/UX you've seen?
https://news.ycombinator.com/item?id=12713604

[simontegg]

https://blog.prototypr.io/interaction-design-is-dead-what-now-db09d77cadae#.333xxlkex
@ahdinosaur