Access, not ownership. My view on digital books.

Digital books, blah blah blah -- the argument seems to centre around all things related to ownership. For me, it isn't about ownership -- unless you see yourself as the sum of your things or you consider that books are a better medium from which to learn or enjoy.

Which brings me onto the key point in all of this: access. If that means $10 on a book because I didn't buy it already / don't have it to hand / lost access to it due to a poor purchasing decisions -- then so be it. Next time it'll be $0 on a wikipedia article or blog post or whatever.

If you really do want to "own" your digital content in the I-can-and-will-take-all-responsibility-for-its-wellbeing sense, then you can -- all the major digital book services provide you with permanent, resilient, local, disconnected copies of files. You just need to know how to manage each and every source and be prepared to do a little management. Compared to the pain in the ass that is finding, moving, storing and living with a large number of physical books I think it's no big deal.

Wired: "An unfinished e-book isn’t a constant reminder to finish reading it." WTF? An unfinished e-book isn't a burden on your conventionally-bent self assessment. As it happens, I do finish most books I read. In fact, I finish far more ebooks than I did physical ones because I've always got them all with me. Further counters to Wired's nonsense an be found here at allaboutthevoluntary.com.

Revisionism is a valid concern. But with a little more market saturation and a few more tools, it'll be hard to get away with. Once DRM goes away (it will), it's a non issue as copies proliferate and comparisons are easy. Existing DRM will be brute-forced in about the same time it takes for DRM in the book space to go away. It's really not an issue from a technical point of view. Sure, it'll happen (and does in print books as well as ebooks), but it'll be highlighted.

In the Kindle app on my iPhone I generally have between 10 and 15 books on the go, and manage to get through 1-2 a week. This is done either in 15-minute segments when I have a free hand and eye, or as a reference to whatever I'm working on. At the minute that includes Enter The Kettlebell!, Replay: The History of Videogames, Atlas Shrugged, The War of Art,  The Art of War, The Vegetarian Myth,  and The Art of Game Design: A Book of Lenses, Demon's Captive and Fun Inc. That includes a book not available in this country in print, one that I've been reading for about 3 months, one that's entirely reference, one that has been revised and translated many, many times but I was able to find an as-far-as-can-tell faithful translation of and one that even I may be too embarrassed to own in print.

We're at same point we were 5-7 years ago with digital music. The transition might take a little longer (recordings of music as property have been around for far less time than the printed book) but it'll happen, and in so happening a lot of these little things will go away. Those who really care about "books" (I don't by the way, I care about information), will revel (I am revelling already -- see above paragraph) in the access granted to them and embrace digital books. For the majority, the perceived snobbishness around books will eventually go away with this realisation.

The motivations of the remaining minority will become clear. Either they do actually prefer physical books as a way of accessing and digesting information (and this is entirely reasonable) or they perceive some other value in the ownership and accumulation of those physical books.

Some thoughts on satisfying pursuits, discipline... and Warhammer

Was just going to scribble this down for myself -- as part of figuring out some drive and interest things... and how they're not always manifested in the same way. But figured you might be interested as well.

I have very much enjoying engaging in Warhammer Fantasy -- playing, strategizing, optimizing, painting, crafting, acquiring etc. But last Thursday night (the last game Goose and I played), for the first time, I didn't really enjoy it (this was from the outset -- not just after I started loosing). This I found especially odd as all the circumstances were supportive of a good time: we'd had a very significant output for 36peas that day; I had a busy but well-prepared-for day of PBAL the next day; the kids were in bed etc.

I'm pretty certain – in fact I know for sure – that this was because in the preceding 10 days I'd spent no time whatsoever engaging in Warhammer stuff – I'd not thought about army lists, strategized, painted or done any related activity.

Last night I spent an hour painting – and I deliberately set aside an hour so that I'd a.) have some measurable and quantifiable assessment, and; b.) go to bed at a reasonable time in order to be up this morning.

I thoroughly enjoyed it. And this morning I am happy and enthusiastic about playing later in the week and already spending my off time (time when I can't fit any other activity in -- normally between modes of transport, in lulls of conversation etc) strategizing about how I intend to play, what things I'd like to paint in advance, etc. I also listened to TWIT live in that time, something else on my list of must-do-regularly-because-get-a-good-bit-out-of-it-personally-and-professionally.

This brought me round to thinking about discipline and immersion (the latter of which Goose and I talked about in GDIM #4). Do I (can I) only enjoy the separate elements of Warhammer when I engage in them all? And does that have to be on some kind of regular basis?

Given the variety and volume of different things that I do, this is something that worries me – I want to understand better that behavior (immersion in multi-genre gaming pursuits) but I find it unlikely that I (personally) would naturally end up keeping to any kind of regular pattern of engagement (at this point in my life) because of the multitude of other (self-imposed) demands on my time. But I really, really enjoy this particular pursuit, and I find it rewarding and useful as a game designer.

So, in the interests of full immersion (I’m one army of 10+ into one game of 3+) I’m going to try something else I’m interested in – disciplined activity. This is unknown for me – I do a lot of stuff, but it’s almost all on either a get-as-much-done-in-the-time-permitted or a just-in-time basis. First part of said discipline (KISS for now) will be to spend an hour painting at least 5 evenings out of 7. I always have other activities I can combine with this (watching, listening, thinking) and it I don’t expect to have to shift anything else out of the way – but doing it against a personally-imposed discipline may change how I look at this, and, more importantly, other pursuits in the future. I hope it will also give me a better view on games from the perspective of a fully-immersed player. 

8 Entrepreneurial techniques for effective software development (and other complex creative projects)

As the first post in our #idevblogaday Wednesday spot, I thought I'd take the opportunity to expand on a few points relating to the management and getting things done of software development with an entrepreneurial slant.

This is pitched at those involved in the practice of software design and development - primarily for those working alone or managing small teams. However, it's easily applied to people doing similar in other fields - particularly complex creative projects. It jumps about a bit between personal productivity and project design and decisions.

The inspiration for this list comes directly from a couple of videos in which Jerry Kaplan discusses the 5 biggest mistakes entrepreneurs make and the 5 critical skills entrepreneurs need. His points are related to business development and the management of people specifically, but the core of them can be applied easily to the creation of things, especially in the realm of software development.

I manage and lead a small team that makes computer games (iOS computer games at present) -- and the points I make below are all drawn directly form my experience and development doing that, and from having managed a variety of teams of developers and other creatives in the production of a variety of software projects, business applications and services. It all works the same, it's just that some of it (the games development bit particularly) is more fun.

A lot of the points below can be applied to different aspects and levels of software development and design, but I've mostly avoided the people-management applications as there's no point in repeating Kaplan's original (and very useful) observations.

1. Set a clear mission, goals and objectives at every level

Establish how you intend to measure success - at every level. How do I know if this feature is complete? How do I test that this bug is resolved? What should this button do? What problem is this application trying to solve? In what way is this game fun for the player?

Without a clear objective and measure of success, not only is it impossible to efficiently move from one task to the next, it's difficult to guarantee that the work you're putting in is even required in the first place.

2. Don't try to be clever

Being clever for the sake of it does nothing but make you look like an ass. And it almost certainly confuses the requirements or expectations of anything you create.

When you come back next week to write a parser for that set of data structures you just designed, what would you prefer - an obfuscated mess of techniques you don't fully understand, or a solid, transparent solution to the problem they were intended to solve?

Users of your software don't care how smart you are. In fact, they would really prefer to feel that they are the smart ones for choosing you in the first place. If you want to show off, go join the circus. If you want to impress users, deliver on your promises (see #1 Objectives).

3. Don't do it for the money

Do it because you want to, and worry about the rest later. If you genuinely want to make software, then make your decisions in that context.

If you can figure out how to find and utilise resources (your time, skills and passion count) and convert them into value, what you do inherently has value in and of itself. If you can't figure out how to make money at that point, go ask someone else - others are more than happy to help if properly recognised or rewarded for their input.

4. Share your wealth and skills

Kaplan makes the observation that "equity is like shit: if you pile it up, it just smells bad; if you spread it around lots of wonderful things grow." This can be directly applied to your most precious resource -- your time.

If you concentrate on any one piece of the software development process or on a specific aspect of one stage of that process you will almost certainly fail to meet your objectives. Just because you love to perfect the game mechanic doesn't mean you shoudn't be paying equal attention to the UI, or the audio, or the help system, or the game's marketing material... and on, and on.

5. Use what you need, not what you like

Maybe I've spent too long in the enterprise software world, but this seems to be apparent in almost every software development or delivery project I've been involved in.

It's simple: use the tools that get things done.

Do not use something (a platform, a method, a person, an IDE, whatever) because you like it -- remember this has got nothing to do with you -- keep your objectives in mind (#1 Objectives) and choose what gets the job done.

6. Know when to let go

Just because you thought it was a good idea a week ago, doesn't mean the same holds true right now. Your agility is one of your key strengths - adapt, change and -- if you have to -- let go of what you don't need.

7. Telescope as required

Every single one of us has spent an afternoon so absorbed in detail that by the end of it you're unsure of how you got there and, more importantly, why you were there in the first place.

If you're not consciously doing it already, identify and refine your ability to telescope: You need to be able to pick up on the detail of a problem, apply your skills and solve it with a constant view on its relationship to the wider context.

8. Lead and make decisions when you need to

You have to make decisions in order to move forward and if you want to be in any way efficient about doing so, you need to make them at the right time - not too early and not too late.

Don't try and anticipate problems for the sake of doing so and don't avoid making a decision because it changes something that came before (see #6 Letting go).

As Kaplan points out, leadership is often defined as the ability to build consensus in the face of uncertainty. Software design and development presents infinitely uncertain paths - you need to have the confidence that you can consistently pick them as you need to.

Update: For those of you who saw the original title -- I was planning on 10, but settled on 8. I guess 9 and 10 could be "pay attention" and "be concise."