Pages

A blog for jon@eaves.org

Menu

Monthly Archives: March 2015

I don’t like being by myself as much as I am these days. It’s something I struggle with quite a bit. I’ve had quite a while to reflect on this topic, and there’s a couple of words that are often used to describe the situation, but they mean quite different things to me.

The first is “alone“. To me, being alone, is to not have physical or mental proximity to other humans. This is relatively rare, and for me is a choice that I make if I decide to isolate myself. I like to be alone at times, and to ride, and to run. They are my favourite things to do alone.

The second is “lonely“. This is a feeling of a lack of connectedness with other humans, and in my case I feel this more strongly without a partner. I’m certainly least lonely at this stage when I have my close buddies over, chilling and talking shit. I feel less lonely when I have George with me.

Those who know me IRL would probably consider me fairly extroverted, and that’s true to some extent. I do enjoy being in groups of humans, and it’s something I’ve become comfortable at. It’s not natural for me by any means, I was taught this by my parents, and something that I’ve worked on in my career. What many people might not understand is that I do like to be alone at times, and to contemplate the vastness during that time. I’ve never really been able to describe it well, but I like to ride (and now run) to the limits of my physical capabilities – and use that so my thoughts become focussed on “the now”.

I’ve done this for years, and really didn’t notice what I was doing until I had a conversation with a Twitter friend about what she gets out of Yoga and the mindfulness aspects of it. I like this alone, it’s active or voluntary alone-ness.

Then I read this; http://www.brainpickings.org/2014/09/03/how-to-be-alone-school-of-life/

I was impressed by how it seemed to accurately describe my feelings on the matter. The distinct difference between alone-ness and loneliness was laid bare and what was confusing to me (I like to be alone, I don’t like to be lonely) and how the world reacts to the alone-ness. I must say I’ve not really felt any great society pressure about my need to be alone. Probably because it’s hidden behind my physical activities that are considered normal to be performed solo.

Turning the gaze to loneliness it’s a bit harder to reconcile my thoughts and feelings on the emotion. While I’d like to “not care”, I find it very hard – and it’s almost something that I find defining as a human. I’m unsure what other people in similar situations to myself do, or if they feel the same way. I suspect that at at this point some form of substitution of life occurs, where distraction, numbing or soothing becomes commonplace.

Working long hours? Drinking? Drugs? Religion?

Who knows?

Excuse me while I go for a ride and think about it a bit more…

” Men will always be mad, and those who think they can cure them are the maddest of all. “

I had a brief conversation on Twitter with Camille Fournier (@skamille) about costing for projects and development, and this is something that I’d been thinking about (but not writing about) since I was at ANZ bank about 2007 or 2008. Most of it was trying to explain/understand expectations about software development and delivery and “how much effort to put into projects”.

Even though I actually have a commerce degree, I don’t intend this observation to be a strict treatise on the accounting terms “asset costing” and “expense costing” but more about the general expectations set by considering the constructed software as an asset, or an expense.

The basic premise is that in general teams of software developers, in the absence of specific direction or rules will assume that the software being delivered will have the properties of an asset. The software will last for an extended period of time, it will be modified and updated and will not generally have a short defined end of life date.

However, in many cases the teams of people asking for software to be built will not always have the same view, and they may be well asking for systems that are developed in shorter time frames, and have a short defined end-of-life date. This generally is where the difference in expectation on project cost (and time) often comes from. We see this a lot in start-ups, where iterating and responding to new ideas trumps all possible long term benefits. With nothing right now, there is no future for the start-up.

Coupled with this particular problem, there is generally a mismatch between how much effort the demand team expects the supply team will take to construct a solution.

So, what should we do about it?

At REA, I’m starting to help our teams with this, and the first step is to get some greater definition about the expectation of not only what problem the system should help solve (“functional requirements”) but also the scope of what that system should participate in (“non-functional requirements”).

Generally these would be called something like SLA (service level agreements). How many users will it support, what is the uptime? What is the response rates? What are the transaction rates? These are pretty standard non-functional requirements that you’d see in systems descriptions. However, one key part that I’m trying to encourage people to think about is “how long should this last?”.

I think the first part of the problem is trying to get an understanding from the customers about what their goals are. Do they want to create some “disposable software” to solve this problem? Do they think that the solution to this problem should last for a long time and be enhanced over that time? Do they even understand there is a difference to the engineering required to do this?

Now, if we add to this the general trend towards microservices (smaller units of functionality that can be more easily replaced) maybe we are looking at a general shift in the way we write code for systems and how we might wish to think about, and set expectations for system development. Can we really think of software components as “write them to throw away”?

Certainly if we’re looking at treating the components or code like an expense, I think there’s a better chance. I also think that using expense based thinking for “research and discovery” might lead to more opportunities for faster iterating through ideas, knowing the expected use and lifespan of the work performed.

I’d also like to see more input from people who have tried similar ideas. It’s a slice of a topic about “software life-cycle management” that is more deserving of thought that most teams give.