Pragmatic Dictator

Let’s say you sell pottery. Your core business is about making that pottery, perhaps to order but there’s a whole load of additional work you must do around accounting and the like. Perhaps you also ship your pottery via surface carrier, this introduces further work tracking customer details (watch our for pesky privacy regulations), working with couriers etc.

Almost from the get go these days you’ll automate as much of this drudgery as possible using computers, essentially creating a one person IT department that supports your business processes. Obviously the bigger the business gets the more automation you will require, perhaps developing custom software to support the execution of your business processes (all that drudge you have to do but isn’t core). Your IT department will have to grow accordingly, hiring developers, project managers etc.

This standard tale of the relationship between business and technology plays out in many an enterprise every day. IT and in particular software development is a necessary evil, an undesirable cost to be carefully managed.

However for a certain class of enterprise, software is the product. Maybe it’s a shrink wrap product or a set of services provided to customers via the web. There will still be a need to have an IT department to support the business processes and it might well develop software of it’s own. There’s a fundamental difference between these two types of software because one of them is the business’ money generator. This software must be nurtured and tended to carefully, one can’t just add features, one must care about stability, performance, availability, scalability and so on. Money put into this effort is not a cost it’s an investment. Fundamentally, this software is not enterprise IT as most know it.

This key difference is oft-missed by management, vendors and analysts leading to confusion and unnecessary mistakes. I’ll cover one such mistake (related to SOA) in a follow-up post.

Technorati Tags: business, engineering, software

Planning and estimation discussions always come back to:

1. Agreeing what will be done
2. Agreeing how much it will cost
3. Agreeing a deadline by which the what will be done

Because these questions require that one knows everything down to the deepest detail and that all possible happenings are known (which means knowing when people will be ill and for how long, how much time they’ll need to take off for dealing with family troubles, problems with the plumbing etc) and the risks are mitigated such that they absolutely will not affect your project in unpredictable fashions.

That’s not to say that one can’t set deadlines but one has to expect to trade features away, adjust resourcing etc. Of course none of this is news and yet so many places claim to be agile whilst continuing to have the what, how much, when discussion.

Technorati Tags: development, engineering, process, software

That’s what everyone craves. That’s why lines of code is still seen as a useful measure in various quarters. That’s why we obsess over IDE’s and other so-called productivity tools.

Trouble is every decent software engineer knows that actually you want less code. It’s easier to maintain, easier to change, easier to debug, easier to build on. They’ll also tell you that the best way to build big codebases is out of lots of small, well isolated, loosely coupled bits with minimal knowledge of each other.

The less code philosophy requires doing some design, pausing for thought and not cranking code. It can provide massive benefit but it’s difficult to measure in any simplistic fashion and thus is seen as pure cost by many.

More code is the hare, less code is the tortoise – know which one I’d bet on.

Technorati Tags: development, software, systems

For a long time, software development within many an enterprise is treated as a subservient entity. Something that is expected to comply with the demands of the business without complaint and with limited options for pushback.

I believe the software we produce should be viewed as a stakeholder in it’s own right. It has it’s own needs for survival and ongoing growth and if these are always placed behind everyone else’s (i.e. the business) considerations, the results will be a long slow, painful death where the software becomes more and more brittle, less and less maintainable and staff productivity drifts down as staff turnover creeps up.

Consider a car – it has needs, new tyres, oil flushes, new exhausts, paint chip removal, new springs, new clutch etc. Fail to address those needs and your car will turn into a pile of rust before your eyes with all the attendant issues of depreciation, lost investment, breakdowns etc.

Why do we refuse to accept that software has a need for the motoring equivalent of oil changes and the like? Probably because software is an invisible abstract thing such that only those working with it see the damage being done, problem cars are easier to spot for a greater percentage of the population. This isn’t really an excuse however because software gives warning signs just as cars do. If there’s steam coming from under the bonnet (hood) you’d go to a mechanic, if your software keeps crashing or upgrades keep failing or development takes longer and longer it surely follows that it’s time to visit with your software engineer.

[ You may have noticed I like car analogies - here's another: You can't endlessly tune a car, it will only go so fast. Any further increase in speed can only come from starting with a new car that has better basic performance ingredients. The same is true for software, eventually you need a redesign to make further progress because the initial assumptions you made have all been invalidated. ]

Technorati Tags: development, software, systems

I was reading this from Bill which follows on from Joe. And had a couple of thoughts:

1. Google seems to have applied N > 1 to everything, not just storage – that’s pure distributed thinking, not the norm for the majority of software heads.
2. Eventual consistency might be kinda like concurrent programming for most people – i.e. many like to program sequentially and with the certainty that x has been completed immediately, in order and within a known timespan. Concurrency, eventual consistency and friends aren’t terribly amenable to this programming approach and it consequently melts many a brain.
3. We need for a lot more people to understand CAP.

[Note for Bill should he read this: it seems like your comments are broken, I'm seeing server errors when I hit post]