HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


Delivering innovation vs Leveraging value

Delivering innovation vs Leveraging value In our community we often get questions that might sound something like:
How do I allow users to negotiate the dates of events posted to the calendar, by specifying the dates acceptable to each user, and having the system choose an appropriate date automatically?
or
How do I allow user's to upload files, but only be able to download them themselves?
or
How do I allow ocPortal users to log into the genealogy software I've installed?
(these actual questions are made up)

These questions all start with the words "How", and by implication there is an assumption that any particular requirement is possible via some kind of existing feature for it that can just be configured or activated.

I consider myself leader of the ocPortal product before I am CEO of a company. What matters to me most is helping people succeed with their projects based on ocPortal – or, pointing people to other products if something else is more suitable (e.g. dedicated groupware, or a eCommerce package).

If someone starts from an assumption that anything is possible via just choosing the right settings in ocPortal, or installing the right addons, almost certainly any project started like that will fail. It puts a proverbial knot in my stomach every single time I see it: I'm failing to meet my personal objectives because I can see that other people won't be able to have theirs met, due to a critically broken planning process.

The problem is that these faulty assumptions, while very noble for the optimism and "let's get to it" attitude behind them, are at complete logger-heads with the serious challenges the software development industry always faces. Actually, in an unconscious sense, I think many people assume that new projects are not actually software development in the first place, i.e. without really realising there's even a question to be asked. The question really does need to be asked, right at the start of any project: "Is this a software development project, or is it just a deployment of an existing system?".

In fact, the question isn't a simple yes or no. There's a spectrum, and any project sits somewhere on that spectrum. If it's close to the deployment end, it's possible that no developers will be needed at all, depending on the implementor's skill. However, most projects where I see these kinds of questions, they definitely are not mere deployments. In fact, I see many people ask questions that immediately tell me that they are actually attempting full-blown software development projects, without any developers at all.

I love ambitious people, it gives me a lot of joy to see what cool stuff people do around here, and the huge diversity. There's positive energy, there's great ideas, and there's a great product to help realise them – but depending on the idea, it's not always simple.

The challenges of the software industry

Project costing is notoriously difficult. Essentially any time a new custom project is being done, it's a process of invention, and it's impossible to work out how long it will really take. All people can do is make their best guess by trying to pull out the right key points from the project and intuitively understanding how hard each will be. You can only know how long it will really take if you have an exact knowledge of every tiny task that will be required, and whether your particular implementation of that task will be considered acceptable. The only point which you know this is when the project is actually completed.

In the past teams have tried, and consistently failed, to specify things completely in advance. They've often taken years just to actually get to the point of having a costable specification, by which point the specification is almost always out-dated, and a lot of money has been spent just getting to that point. A detailed spec takes as long to produce as a real prototype system.

Nowadays software teams prefer an incremental development process that starts off delivering a bare minimum, and then delivers additional requirements in small, separately quoted, steps. These are called 'agile' processes. Common examples of agile processes are 'XP' and 'Scrum'.

The challenges of software development are so great that many software engineering degrees will be 50% dedicated to the challenges of specification and costing. Books aren't written about the subject, hundreds of books are, and anyone working on serious software projects should read more than one.

So, with all these challenges faced in delivering a successful project, it's more than a little worrying when someone doesn't even realise they have a software project. As Shakespeare wrote, "A rose by any other name would smell as sweet" (who doesn't love a good quote?). In other words, if it is a software project, not considering it a software project won't remove the challenges – it'll just obscure that there are these challenges and keep always all the useful techniques for solving them that software people know.

Development or deployment?

It comes down to that critical question that you need to ask:
Is this a software development project, or is it just a deployment of an existing system?
Or:
Am I delivering innovation, or leveraging existing value?

("Innovation" is a greatly misunderstood word. For something to be "innovation", it doesn't have to be some inspired new idea that nobody has thought of before. Taking existing ideas and putting them together in a useful new way is innovation. Progress is delivered by standing on the shoulders of giants.)

Perhaps the best way to answer my question is to be a bit introspective, and consider how you already view your project. If you are thinking in terms of generics, there's a better chance software development won't be required, and you'll just be leveraging existing value. For example, "I require to be able to post news, have a calendar to show some events, and a forum for people to interact" is very generic and corresponds very well to existing ocPortal features. However, if you are already thinking in detail, and need particular interaction flows, there's a very high chance that you'll need custom software development.

One mistake people often make is that they might see something somewhere in another product, or an online service, and assume that because it has been done once before, or even many times before, it is completely generic. The reality is that while many things exist in many products, there is absolutely no reason to assume that you'll be able to find them together in the same ecosystem. Earning badges for accomplishments is very prevalent in computer games, and is implemented on some websites, but is still quite a specific feature that hasn't made it into products like ocPortal yet. You'll need to appreciate that not everything is going to be organised the way you need it, even if it exists in the world already in parts. Many people want a project on the edge of what can be done today on the web as a whole, to push the boundaries for their project – and thus this kind of thing should be expected.

A related mistake is that people often don't realise that many services they use have at least a dozen programmers working full-time implementing custom features, holding that service on the edge of innovation and experience quality, and were never done using off-the-shelf tools. It takes some time for features developed for big websites (e.g. LinkedIn or Facebook) to make it into standalone products (or vice-versa actually). Smaller services are often launched by a single programmer working on his/her own – but again, not using off-the-shelf tools.

Shoe-string budgets aren't out of the question

I hugely appreciate that people want to save money, or may not even have a budget at all. This is a large part of what ocPortal is for. You can deliver many kinds of project with no software development, by using ocPortal. Or, you can find ways to do things that bypass the need for it. At the very least, you can lower costs by combining what is already generic in our ecosystem with the custom functionality that you need.

I do feel like I'm being a downer when I say that people aren't always going to be able to do everything on their own. However, I would rather see people start asking the right questions, and doing the right kind of planning, before embarking on a project that they can't finish. I know often people will draw the conclusion "well, I can't afford what it'll cost" – but it's better to confront rather than ignore it. It gives you an opportunity to reconsider your approach, perhaps properly working out the earnings to investment ratio your project could have and seeking investment, or simplifying to try and use more generics.

The age of experience

I'd make the point that we now live in "the age of experience". Respect Apple or not, the immaculately designed product lines Apple put out many years ago now (iMac, iPhone, iPad, etc) has forced the web industry to completely change how it operates. You can no longer just slap stuff together in the quickest way and put it out because "it works". Consumers are far more discerning / far less tolerant. For many projects you may not just need a designer, you might need many kinds of designer – brand design, graphic design, interaction design, user experience design, copywriting, and possibly more things.

Of course, how much you need to do really depends on the nature of your market – how much skill your users have, how patient they are, what the level of competition is, and how much investment the market can sustain. It might not cost much at all, or it might cost a lot – but you need to address the question.

Summary

In summary, it's important to identify the questions you need to ask, to answer them, and then to plan how to proceed.

Never start with poor assumptions. Be optimistic about what you can do, based on knowing the road ahead!

View all

Trackbacks

There have been no trackbacks yet

Edited