Valueflows' "value proposition" to developers

simontegg commented 9 years ago

What does valueflows offer developers?

This has been on my mind because Enspiral is planning to opensource and put some energy into "My.enspiral" - the software we use to create virtual accounts and transact money within a company while reducing overheads.

A year ago @bhaugen wrote a pretty good description of one of the main use cases here and its overlap with valueflows. The other week I started a design exploration thread targeted at my.enspiral. I've put my hand up to help with the design and development but I imagine work won't really get going until the new year. Since enspiral is a do-acracy and I will be doing some of the doing I hope to influence my.enspiral to align with valueflows but I don't have good understanding what that means.

I'm not sure yet but lets say that redevelopment means spitting the app in to an API and a frontend. It would be great if the API could handle syncing accounts and company level transactions with Xero and also with a third app for a specific collaborative funding use-case Cobudget.

Imagine you're a sceptical developer of my.enspiral. In the projects you've worked on you've seen the benefits of keeping a tight scope and minimising coordination costs by giving the lead dev autonomy over implementation details.

Why would you give up your hard earned autonomy over technical implementation to do things the "valueflows way"? How will this benefit the redevelopment, and ultimately users? What does "valueflows way" even mean in practice? Won't that blow out the scope of the project? Isn't software development about meeting and responding to user needs (agile), rather than conforming to abstract prefigured requirements (waterfall)? :)

Thinking about this case may help us get develop better comms in general

cristianvasquez commented 9 years ago

Hi @simontegg,

I recently discovered this valueflows repo. And I find it really interesting :)

As a developer I find it valuable as a vocabulary. A vocabulary is not meant to impose certain way of doing things. You just build your applications and annotate your data with it in a way that another software can consume your data in terms of that vocabulary.

This has several benefits, for example 'being seen' by semantically-enabled search engines or to directly use third party software that understands the shared vocabulary (but not your API)

An example of a successful vocabulary is the good relations ontology: http://www.heppnetz.de/projects/goodrelations/

bhaugen commented 9 years ago

@simontegg - thanks, that's a great set of questions. Don't know it there is a "valueflows way" yet. If one emerges, I want it on my teeshirt, which I have not ordered yet.

I can tell you a shaggy dog story about finding and adopting REA, which is some (but not all) of the inspiration for valueflows, and may explain some of the motivation.

Tl;dr: if you are doing internal systems for one context, valueflows may be overkill. If you are trying to develop software that will work across different organizational contexts, or tie together different apps for different contexts, then valueflows is your friend.

Longer version:

I was leading a skunkworks project for an ERP software company in about 1990 and was charged with "reinventing ERP". Which was the slogan from a product manager, of course. So I spent maybe a couple of years doing so, working in Smalltalk because it was the most flexible environment I could find. And working agile before agile was invented. We had a great team, and a lot of freedom, which we guarded fiercely. We also ran through three companies all of which died before we got a product out the door, which we finally did in about 1996 or so. You can read about it here.

We had struggled a lot with the object model for that project. Spent many hours arguing over whiteboards, not quite knowing what we were doing.

Long story made short, after that, I wanted to take what we had done and use it over whole supply chains. But the model we had developed wouldn't work. Was too company-centric, for one problem. Didn't deal with the backflows of money, for another.

I spent a long time researching supply chain models, and everything I found was crap. Worse than what we already had.

Then I ran into REA and Bill McCarthy. Bill had created it as an model for internal company accounting. But when I looked at it, I saw something different. It didn't care about companies at all. Nor do supply chains, which was one of the key lessons from that period: supply chains are relationships between people. The companies just get in the way.

Anyway, when I retired from working for money, and started to work for alternative economic networks, I found I could move a lot faster if I had REA in my back pocket. Not using it religiously, but understanding a simple model that works, and adapting it to the situation. Saves me a ton of time.

Sorry for the length of that story, but the lesson for me was doing systems that span organizations is hard, and it actually helps to have a model that works. But if you hard up for entertainment, here's an even longer version: https://plus.google.com/u/0/+TammyLeaMeyer/posts/A2z6Tqbj97d

If you are doing internal systems for a known context and especially if you are just trying to develop an extension of an internal app for an internal audience, it will just get in your way.

P.S. when you were doing your design exploration thread, you said you were working on "visualising stockflows". I didn't understand it was focused in my.enspiral, which I've never seen. In that context, your visualizations make total sense and are lovable.

P.P.S what @cristianvasquez said (who popped in while I was writing my reply). And who appears to be working on visual rdf, which I lust for!

simontegg commented 9 years ago

Thanks @cristianvasquez and @bhaugen. If anyone else has some shaggy dog stories I'd love to hear 'em!

if you are doing internal systems for one context, valueflows may be overkill. If you are trying to develop software that will work across different organizational contexts, or tie together different apps for different contexts, then valueflows is your friend

The points about apps that work across organisations are interesting. They way I've been thinking about this recently is "general" vs "specific process".

The tension here is that I think "general" apps, or at least general API's have better business models, but "process" apps perhaps have arguably better social impact (or at least better social impact narratives). The ideal would seem to have your process apps connect to a general API. In addition, after looking at mobile design, I think constrained process apps work better on mobile

Examples: Cobudget is a process app. It was originally built to very specifically for Enspiral's use case where we pool money, then fund projects in monthly rounds. Its been rebuilt twice. The current rebuild gets rid of the "rounds" concept with a mobile first design. I'm not intimate with where cobudget's at, but a difficulty I've heard is that different organisations approach (participatory) budgeting differently. For these orgs to adopt cobudget they also need to adopt the way that Enspiral does cobudgeting, which turns out is quite radical! If an org wants to do democratic budgeting, and is open to doing it enspiral's way then cobudget solves their problem, but I think its harder to sell that than a general app and its not clear how big that market is Lesson: the more specific the process the smaller the market

Loomio is sometimes thought of as an app for a specific process (collaborative decision-making), but comes with a base of general functionality (discussion). I believe most of Loomio's use is general discussion and reporting rather than collaborative decisions per se. After Loomio achieved relative success the idea that Enspiral should dogfood specific processes then make apps for these processes gained currency. But its not clear that's the lesson we should draw from Loomio's experience. Lesson: general functionality can be adapted to the org's need

Holodex doesn't have a specific process attached to it. It does general stuff with people and groups and relationships, but perhaps makes more sense as a puzzle piece than standalone. This made it hard to sell to some in Enspiral especially when it was just an idea with no UI "Where is the process?" "Umm finding and exploring people and groups...". [No transformative social process here] Lesson: its hard for people to grasp an ecosystem app when the ecosystem doesn't exist yet. Its hard to see the value of a vocabulary or plug-socket standard when there is only one plug, and one socket.

Anyway, that's what's been on my mind recently and what I might feed into some internal Enspiral discussions. I'll keep thinking about how to pitch valueflows.

bhaugen commented 9 years ago

I'll keep thinking about how to pitch valueflows.

Curiously, more people seem to be discovering valueflows, without much pitching going on. These are the early adopters who can see potential before it is glaringly obvious.

If we get enough early adopters, and they start building things, and we get some components of an ecosystem up and running and working together, then I think the next layer of adopters will get the message.

Re mobile UI, I plan to experiment with conversational ones, which I think will fit nicely into valueflows.

simontegg commented 9 years ago

:+1:

simontegg commented 9 years ago

Related to @bhaugen's point above and the social impact thread

Rich Hickey actually did nearly nothing to promote Clojure. If memory serves, his complete marketing campaign was a single email on the mailing list of dotLisp (his previous language). The vast majority of Hickey's public communications which are not responses to questions about Clojure, i.e. the ones he himself initiates, are language agnostic and only present his ideas about software development, which happen to be the ideas behind Clojure.... ...I personally think that Hickey's approach to marketing Clojure, whether intentional or not, is brilliant and extremely effective. This is basically the kind of communication advocated by Simon Sinek (How great leaders inspire action). He's never telling anyone to use Clojure, he simply explains what Clojure "believes in" https://www.quora.com/How-big-is-the-role-of-Rich-Hickeys-charisma-in-Clojures-popularity-How-popular-would-Clojure-be-if-Rich-were-invisible

People don't buy what you do; they buy why you do it, and what you do simply serves as the proof of what you believe. http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action/transcript?language=en

bhaugen commented 8 years ago

valueflows / forum.valueflo.ws

Valueflows' "value proposition" to developers #32