2013-11-29

Ruben Verborgh: The lie of the API

Ruben Verborgh – The lie of the API:

“Accessing the website is quite easy: you just go to the URL of an object to visit it. […] Now developers come in. It can’t be as easy as reusing this unique identifier, can it? Of course not, we first have to read the documentation. Here are the steps you need to take: 1. Request an API key. 2. Receive an e-mail with this key. 3. […]

You get what you ask for. I imagine that developers were approached with the question “can you build an API?” And this is what they did.

But the question was wrong. It should have been: “can you add machine access?” That’s what we actually wanted all along, and an API is not the Web way to do that.”

Fri, 29 Nov 2013 13:15:48 +0000
2013-11-28

Asset Bank: Introducing Crowd Feature

Asset Bank – Introducing Crowd Feature:

“As far as we know Asset Bank is the first vendor of enterprise business software to offer crowdfunding as an option for clients who request the development of a product feature. Crowd Feature is intended for clients who want a new feature, can be flexible about time scales, and have a limited budget to spend on it.

[…] Crowd Feature is a SaaS website, available to any software vendor who is interested in doing the same for their clients.”

Great idea! For add-on features that don’t need changes in the core product, I’d go one step further and add an option to collaboratively develop the feature as open source, or ask a third party to implement it. That way, instead of having to give money to the vendor and wait for him to build it, you (a customer or partner) could invest the time of your own developers or pay someone else. Suddenly you have a core product as a common platform, and a market place where anyone can add value…

Thu, 28 Nov 2013 09:37:24 +0000
2013-11-26

Short links (2013-11-26)

Tue, 26 Nov 2013 20:24:51 +0000
2013-11-19

Short links (2013-11-19)

Tue, 19 Nov 2013 08:01:31 +0000
2013-11-16

Jeff Schmitt: The Silent Company Killer

Jeff Schmitt – The Silent Company Killer:

“We had all hit the ceiling. To our superiors, we were simply plug-and-play commodities who performed a series of tasks. They ignored our ideas, so we quit sharing them.

[…] That’s the silent company killer: The failure to bring out the best in employees. They focus on executing tasks and fitting people into boxes. […] In their race to get the job done, they forget that the most productive employees are those who are learning, growing, and seeing themselves progress.”

Sat, 16 Nov 2013 22:00:31 +0000
2013-11-14

Short links (2013-11-14)

Thu, 14 Nov 2013 21:09:37 +0000

Jeff Jarvis: CMS as Media Salvation. Not.

Jeff Jarvis – CMS as Media Salvation. Not.:

“We should take inspiration from Doc Searls’ VRM (vendor relationship management) movement, figuring out how the public should manage us so we can serve them better. We should learn by example from Waze, Twitter, Reddit, Instagram, Craigslist, Facebook, et al and explore the value of offering platforms to communities so they can do what they want and need to do (“elegant organization,” Mark Zuckerberg calls that), with us adding journalistic value to the flow of information that now can exist without us.

If you have media ambitions and want to build an application, build something that is useful to the public, not us. No one in the public will value us because of the CMS we made. They couldn’t and shouldn’t give a damn.”

To quote myself, here’s a related idea from my German blog post Journalismus: Themenzentriertes Arbeiten, vernetzte Beiträge und hilfreiche Software:

“Local media needn’t cover everything themselves, but should be able to act as a platform for any topic. If readers start to write about a new topic of interest on their own blogs or social media accounts, local media can set up a central Web page for that topic, to aggregate and curate what their readers have written. They don’t even have to administer that page themselves, readers might volunteer for doing that. (An example: Combine official traffic information and tweets mentioning traffic jams in a way that’s useful to commuters.)”

Thu, 14 Nov 2013 13:59:36 +0000
2013-11-06

If I were a manager

I’m an idealist who loves to daydream. For example – what would I do if I were a manager? I work as a “lead software architect”, a fancy title that means I’m still just a developer. (Which has its pros and cons.) Here’s the entirely theoretical lessons I learned from watching others manage, and reading pieces on leadership on the Internet: 

First I’d assume that our team is a group of hard-working, intelligent, rational, professional, self-managing grown-ups who do their own independent thinking and are happy to take responsibility. We all want to do a great job and want the company and our colleagues to be great, too. Each of us has unique strengths, sees things that others overlook, and has an opinion that matters as much as everyone else’s. The team organizes itself, everyone takes on the next thing that’s important to work on.

In this environment, management mostly means helping to remove impediments which the team finds keep them from being productive. Interactions with other parties (other departments, customers) need to be scheduled and organized. Information must flow freely and tools work smoothly. The team needs help setting up spaces to review, reflect, encourage and criticize each other’s work. An occasional conflict needs mediation. Decisions have to be made in time (often by the team, but someone’s got to drive the decision making process).

I’d make almost all company information transparent, make sure that everyone has an up-to-date overview of the company financials and the work everyone’s currently doing. And of the work that lies ahead: all the features and deadlines we promised to our customers and partners. Sales people would be asked to bring photos and reports from their visits to potential clients. Developers would, where possible, publish screencasts of their work. We’d tell each other more stories of our day-to-day work, and help everyone see the big picture. This, I’m convinced, would make us grow together, increase motivation, uncover hidden problems and improve our decision making. 

And we’d obsess over what is delivered, not over processes and rules. I’d try to spark a passion for the customer, to get everyone closer to the customer, closer to the problem. Make it our own problem, either because we’re using the thing ourselves or because we’re personally being held responsible by a customer. Ain’t it funny how priorities change when a developer visits a customer and brings back a list of things to do, knowing he’ll have to return in two weeks and report on the progress?

Other essentials: Be honest, admit your own faults freely but don’t point others’ out. Be understanding and forgiving and kind. Help others to focus and learn and grow. Find the right combination of pragmatic, elegant simplicity and quality/excellence – we’ll need both for our products to survive. 

Let’s hope that I’ll never become a manager… I sure wouldn’t be able to live up to these ideals! (Hey, maybe the leader position can rotate between team members?)

Wed, 06 Nov 2013 21:32:35 +0000

Neil Gaiman: Why our future depends on libraries, reading and daydreaming

Neil Gaiman: Why our future depends on libraries, reading and daydreaming:

“We all – adults and children, writers and readers – have an obligation to daydream. We have an obligation to imagine. It is easy to pretend that nobody can change anything, that we are in a world in which society is huge and the individual is less than nothing: an atom in a wall, a grain of rice in a rice field. But the truth is, individuals change their world over and over, individuals make the future, and they do it by imagining that things can be different.”

Wed, 06 Nov 2013 21:20:59 +0000