2013-08-01

Henrik Kniberg: The Solution to Technical Debt

Henrik Kniberg – The Solution to Technical Debt:

“Crap gets into the code because programmers put it in! Let me make that crystal clear: Crappy Code is created by programmers.

[…] However, the most probable reason for why you are writing crappy code is: Pressure.

[…] Sometimes the cause of the pressure is the programmers themselves. Developing a feature almost always take longer than we think, and we really want to be a Good Programmer and make those stakeholders happy, so the pressure builds up from inside.

[…] If you are creating Crappy Code, development is going to get slower and slower over time. There is no business sense in this, and it is certainly not agile.

[…] Tell the world, and the people who you believe are pressuring you into writing code: “We have been writing crappy code. Sorry about that. We’ll stop now.”

[…] The real source of pressure (if there was any) will reveal itself. Quality is invisible in the short term, and that needs to be explained. Take the battle!”

Thu, 01 Aug 2013 12:04:58 +0000
2013-07-31

Short links (2013-08-01)

Wed, 31 Jul 2013 22:00:50 +0000
2013-07-28

My favorite quotes from “Anything You Want” by Derek Sivers

Can you read Derek Sivers’ book Anything You Want (from 2011) and not want to start a company? I’ve been following Derek Sivers’ blog since 2004 so I was familiar with many of the stories he’s telling in the book. But I still loved to read it.

Favorite quotes:

“Business is not about money. It's about making dreams come true for others and for yourself. […] When you make a company, you make a utopia. It’s where you design your perfect world.

[…] The key point is that I wasn’t trying to make a big business. I was just daydreaming about how one little thing would look in a perfect world.

[…] When you say “no” to most things, you leave room in your life to throw yourself completely into that rare thing that makes you say “HELL YEAH!”

[…] Never forget that absolutely everything you do is for your customers. Make every decision – even decisions about whether to expand the business, raise money, or promote someone – according to what’s best for your customers. If you’re ever unsure what to prioritze, just ask your customers the open-ended question, “How can I best help you now?” Then focus on satisfying those requests.

[…] If you want to be useful, you can always start now, with only 1 percent of what you have in your grand vision. It’ll be a humble propotype version of your grand vision, but you’ll be in the game. You’ll be ahead of the rest, because you actually started, while others are waiting for the finish line to magically appear at the starting line.

[…] Starting small puts 100 percent of your energy on actually solving real problems for real people.

[…] When you build your business on serving thousands of customers, not dozens, you don’t have to worry about any one customer leaving or making special demands. If most of your customers love what you do, but one doesn’t, you can just say goodbye and wish him the best, with no hard feelings.

[…] You need to confidently exclude people, and proudly say what you’re not. By doing so, you will win the hearts of the people you want.

[…] That’s the Tao of business: Care about your customers more than about yourself, and you’ll do well.

[…] If you find even the smallest way to make people smile, they’ll remember you more for that smile than for all your other fancy business-model stuff.

[…] There’s a benefit to being naïve about the norms of the world – deciding from scratch what seems like the right thing to do, instead of just doing what others do.”

Sun, 28 Jul 2013 20:54:38 +0000
2013-07-19

Jeff Atwood: The Rule of Three

Jeff Atwood – The Rule of Three:

“We think we've built software that is a general purpose solution to some set of problems, but we are almost always wrong.

[…] To build something truly reusable, you must convince three different audiences to use it thoroughly first.

[…] One customer or user or audience might be a fluke. Two gives you confidence that maybe, just maybe, you aren't getting lucky this time. And three? Well, three is a magic number.

[…] We're spending all our effort slowly, methodically herding the software through these three select partners, one by one, tweaking it and adapting it for each community along the way, making sure that each of our partners is not just happy with our discussion software but ecstatically happy, before we proceed to even tentatively recommend Discourse as any kind of general purpose discussion solution.”

I have long experienced this to be true. (It’s painful, because we’re in the “Enterprise Software” business and generate way too much code used by only one or two clients…)

It’s also true at a smaller scale: The APIs and formats and configuration settings internally used by our software need different use cases as well to prove that they’re well-designed. It helps that DC-X offers a lot of its functionality via UI, Web service, command line and PHP API (see Five faces of a Web app). Still, lots of areas remained “one-hit wonders” though we tried to make them reusable.

Fri, 19 Jul 2013 07:44:38 +0000
2013-07-18

Convergence between WCM and DAM

Ralph Windsor on Digital Asset Management News – Telerik Add Digital Asset Management To Sitefinity:

“This does mark a clear point of convergence between WCM and DAM – an outcome which has been talked about for some time and now looks to be definitely happening. It’s interesting to note similar trends with DAM systems starting to offer WCM functionality as discussed earlier this week.”

Ralph refers to WebDAM adding an embedded CMS. Adobe CQ (sorry, Experience Manager) tries to go the other way, tacking a DAM system onto their CMS (missing the opportunity to integrate with existing DAMs, and having issues). The free Koken is an interesting hybrid; it looks like a DAM but focuses on publishing and has an editor for essays/pages.

Like most DAM vendors, we did integrations with various Web content management systems at customer request (WordPress, Drupal, red.web, redFACT). Some are more elegant than others, but it’s the usual integration pains – different APIs, data models, UI extensibility points… And the fundamental problem of duplicated data that has to be kept in sync.

This is similar to the editorial systems (for print publications) we’re integrating, but the WCM / CMS market is unique in that it has a lot more active players. And it’s moving faster; new vendors and versions emerge and requirements are changing quickly.

In an ideal world, there would be both a DAM value chain and a WCM value chain: Well-architected software would allow us to use a DAM as the backend for a CMS. From the CMS, we could take the editing and administration frontend, and the Web rendering and delivery functionality, and bolt these onto a DAM content store that contains all of our assets. (Without having to duplicate the data.) DAMs are usually better at search, scaling to millions of assets, file format and metadata handling. (CMIS might be meant for that, but I haven’t heard of it being used that way. Did I miss something?)

Thu, 18 Jul 2013 06:37:47 +0000
2013-07-16

Short links (2013-07-17)

Tue, 16 Jul 2013 22:36:45 +0000
2013-07-15

Product Strategy Means Saying No

Des Traynor – Product Strategy Means Saying No:

“When your product gets traction, you’ll find yourself inundated with good ideas for features. These will come from your customers, your colleagues, and yourself. Because they’re good ideas, there’ll always be lots of reasons to say yes to them. Here’s 12 arguments in the style of Don Lindsay that are commonly used to sneak features into a product:

But the data looks good

But it’ll only take a few minutes

But this customer is about to quit

But we can just make it optional

[…]”

Mon, 15 Jul 2013 11:07:02 +0000
2013-07-09

First steps – encrypting e-mail and files with GPGTools

As Tim Bray puts it: “There are lots of perfectly-legal reasons to want privacy. If you act all the time in a way that sensibly preserves yours, when one of those legal reasons becomes important you suddenly won’t be acting different in an attention-catching way.” Back in 2011, I already created an OpenPGP key, then forgot about it. Now seems the right time to actually start encrypting e-mails… Likely too few people will bother setting up their e-mail client for encryption. But I’d still like to understand how it’s done, and be ready for it. (I’m a newbie – if you’re doing encrypted e-mail, you’re welcome to send me a test mail that helps me verify my setup… Thanks!)

I’m on a Mac, using Apple Mail on OS X 10.8 for my personal e-mail (tim@strehle.de). So I installed GPGMail from GPGTools, followed their First steps instructions and soon could use the nice “Encrypt” button when composing an e-mail to myself.

My own key, and the keys of people I want to exchange encrypted e-mails with, are managed in a separate application, GPG Keychain Access (“GPG Schlüsselbund” in German). These keys are stored locally on my computer, but there’s a central registry for OpenPGP keys, the “key servers”. I sent my public key to the key server, so you can retrieve it using the key ID 1F20C9AD or my tim@strehle.de address. As I understand it, one should verify the “fingerprint” of the key after retrieving it from the key server – my key’s fingerprint is “C29E 9A3B 786C F2CD 0943 7763 8B3D A0A0 1F20 C9AD”. (I’m also publishing the key ID, fingerprint, and even the full public key on my homepage.)

There’s an ugly but helpful OpenPGP Keyserver Web interface where you can search by name, e-mail or key ID (prepend the ID with “0x”, i.e. “0x1F20C9AD” for mine).

What’s nice is that GPGTools come with a command line “gpg2” executable that lets me encrypt a file for someone (“gpg2 -se -r tim@strehle.de tmp.txt”, turning tmp.txt into tmp.txt.gpg) and decrypt a file encrypted for me (“gpg2 -d tmp.txt.gpg > tmp.txt”).

Unfortunately, the GPGServices can only decrypt text in any OS X application, not encrypt it. Not sure how to work around this; it would be nice to easily both encrypt and decrypt text anywhere.

Tue, 09 Jul 2013 21:47:00 +0000

Short links (2013-07-09)

Tue, 09 Jul 2013 10:48:59 +0000
2013-07-08

Jonas Öberg: A distributed metadata registry

Jonas Öberg – Developer’s corner: A distributed metadata registry:

“Anyone should be able to run their own registry for their own works or works in which they have an interest.

[…] Standards such as ccREL provide a way in which a user can look up the rights metadata by visiting a URL associated with the work and making use of RDFa metadata on that URL to validate a license. That’s a useful practice, since RDFa provides a machine readable semantic mapping for the metadata while ensuring that the URL could also contain human readable information.

[…] Let’s further imagine that the unique identifier was always a URL.”

Mon, 08 Jul 2013 14:31:17 +0000

If we were to redesign Topic Maps… (LinkedIn discussion)

Steve Pepper started a (lengthy) discussion in the LinkedIn Topic Maps Community group – If we were to redesign Topic Maps based on what we have learnt in the last decade, what would we do differently?

Since LinkedIn groups are closed, I’m posting my comment here as well, in response to proposals to replace occurrences (properties) with associations:

“In my opinion, the strength of topic maps is that they’re quite intuitive and easy to explain.

When I’m modeling data, I’m thinking of topics (or subjects/objects/things) with names, classes, identifiers and arbitrary, repeatable properties (often literal values). And then about relations between topics, with relation types and roles. SQL database design made some of this rather hard, so I was very happy when I discovered topic maps back in the day.

Reducing that model to “everything is an association” seems counter-intuitive to me. This reminds me of the RDF “everything is a triple” approach that is dumbing down data structures so much that it makes them harder to understand; see my blog. “Everything is a row in a database table” is on the same, not really helpful level. And as a programmer, I don’t look forward to such a change; simple property look-ups are faster and easier to implement when they don’t need to go through the whole association complexity.

I’d like datatype support in topic maps (literals that are annotated with a datatype of “datetime”, “nonNegativeInteger” etc.). And maybe associations could extend topics, i.e. inherit all topic functionality without optional reification?”

Mon, 08 Jul 2013 12:25:44 +0000
2013-07-05

Short links (2013-07-05)

Fri, 05 Jul 2013 21:17:26 +0000