Category: Requirements

Will Windows 8 bring MS into the tablet/phone game?

cvjepsenLeave a comment

Recent I had a discussion about the contents of the following article: http://gizmodo.com/5839665/windows-8-slate-hands-on-its-fantastic-but-dont-sell-your-ipad, where I labeled a post: “Eventually the tablet OS market will be like the desktop OS market. MS against Apple also on tablets.” which caused an interesting debate. So I thought I would write why I believe this will be so.

I would say that on the tablet market Android isn’t imposing any real threat to anything, maybe apart from themselves. Regardless of ice cream, soft ice or whatever sweet project name Google came up with this time – guess it requires a lot of sweets to swallow Android, it won’t bring them into the tablet market. If you’ve followed stories on non-iPad tablets, then they’re being returned at an alarming rate. There’s nobody delivering Android tablets, not I’ve been able to find, that are keen on informing about number of sold units – normally something you would be very keen on doing if you were selling a lot of units. Should give you a hint to the traction the Android based tablet devices.

One thing that history has taught us is that big corporation becomes very innovative when their core business and primary revenue generator comes under pressure, and feel themselves against the wall. That’s the point in time, they either bet their business (as Apple did) or reinvent themselves (as IBM did). Not sure MSFT is really against the wall, yet. But they definitely feel under pressure, and are probably concerned about their primary revenue generators being Office and Windows. Will they succeed, only time can tell – but it’s definitely naive to count MSFT out of the game on tablets and phones.

On the subject of Android on phones, then there’s not just 1 Android, there’s uncountable number of Android implementations out there. Every phone and tablet vendor using Android got their own version of Android. This fragmentation causes problems with the apps developed for Android, and you can have apps that works on a device from Samsung, but doesn’t work on a device from HTC. People keeps talking about the success of the Android platform and there’s a bunch of charts showing that there’s more Android phones than, but that covers all flavors of Android on all vendors of devices. If you compare the manufactures of phones, then Apple is the single biggest vendor of phones. Followed by Samsung and Nokia. Note that Samsung includes non-smartphone and non-android phones, goes for Nokia as well. So how successful is Android really when it comes to it? And also, how to you measure whether or not something or someone is successful?

Google buying Motorola could backfire on Android, as the current device manufactures will be concerned, that Motorola will get an unfair market advantage when it comes to delivering new versions of Android. There’s already been speculations about Samsung looking at WP7 and/or buying WebOS and/or promoting Bada. I bet you, that the Softies in Redmond and employees at Apple was clapping their hands when Google announced the acquisition. As much as Apple and MSFT (probably) hates each other, they do agree on disliking google. And together they do make a somewhat scary opponent. MSFT is probably already working hard to convince Samsung and HTC that WP7 is a better bet than Android, and by acquiring Motorola, Google just made the argument easier.

There’s been a lot of criticism of MSFT not building a complete new OS for tablets, or at least uses the WP7 OS from the phone. To some extent I do share that concern, as Windows is a huge OS. The interesting thing, though, is that Apple is trying to merge MacOSX and iOS into one OS, that work started with LION. So you could argue, that Apple and MSFT is doing similar things, however, Apple used a convergence strategy – having 2 distinct OSes and converge them, whereas MSFT used a duplicate strategy, duplicate your OS to multiply devices – and slim it. By the end of the day, both Apple and MSFT are trying to do the same thing, having one OS to ease development of apps. For Apple that would allow users to use iOS based apps on Macintosh, allowing Apple to sell more computers. For MSFT it’ll allow users to use the apps they already know on tablets. Same Same, but different starting point and approach.

How will this end? Well, only time can tell. But it’s imperative when we try to project or anticipate the future that we stay non-biased and objective; otherwise, we risk making critical strategic decisions based on personal preferences, which doesn’t always come out successful.

Elephant butt, Software Development and Estimation

cvjepsenLeave a comment

Okay, here’s an interesting question: what does an elephant butt, software development and estimation have in common? At first thought not really much, but then again they actually have a lot in common – depending on how you look at it.

Imagine you got blindfolded and placed right behind an elephant, being ignorant to the existence of such an animal. You remove the blindfold, blink a couple of times – and the only thing you can see is a huge grey butt! Wow, that the heck is this you ask yourself wondering. You slowly start moving around the grey butt in an effort trying to understand the nature of the grey mass you’re staring at. Getting to the side, and it’s still somewhat unclear what you’re looking at. Something very big and all grey. Unable to determine the nature of the grey mass – you step back. Suddenly you get enough distance to have the whole creature within your field of vision. And you go: aha that’s what the animal looks like.

So how does this tie into software development and estimates? Actually more than one would initially believe. Any totally new development project presented is like the butt of the elephant. You look at the task delegated and wondering what the heck is this all about. You then start working on the task, doing some research (moving around the elephant), cranking out some code (stepping back from the elephant) – and suddenly you go: aha, that’s what I’m going to build. And at that point in time, is the point in time you actually understand the task and somewhere realize the implications and start getting an idea of the time involved in solving that specific development task.

So that’s all nice and good. You get a task, researching in trying to understand it, doing some limited coding – prototyping until you go eureka! The problem is, that typically you’ll be asked to estimate or at least ball park an estimate upfront. Using the above analogy that’s the point in time someone removes the blindfold and the only thing you can see is one gigantic grey butt. If this is a completely new development task, where you’ll need to research new areas you have absolutely no clue to the implications of the task and can’t even remotely come up with a reliable guestimate on how long it’ll take.

What to do? Well, the only approach I’ve found that works is initially to spell out that you’ll need 30-90 calendar days of pre-project research, fact finding and prototyping prior to offering up any estimates. Depending on the company you work in you’ll find that some companies are completely fine with this, others aren’t. In case of the latter, try using the elephant analogy. If that doesn’t work, well – take what ever estimate that makes sense and add 60 days.

Upon going “aha!”, throw away everything you did, don’t move any research/prototype code forward into the product, as it usually is kind of messy – as you’ll be messing around trying to figure out what the heck you’re supposed to develop.

Methodologies, Better Software and Requirements

cvjepsenLeave a comment

Methodologies

Methodologies are like patterns, best practices, recipes or how-to’s. They describe how to get from A to B. But none of them claims that it’ll lead to better software, whatever better software means. Actually, that’s not totally true – some of the newer methodologies got some interesting claims on the subject of providing quality wise better software.

When discussing better software most people thinks about the quality of the software, seldom does people consider whether or not the software does what it’s supposed to do. Probably more correct to say, that people don’t factor the functionality in as part of quality. Can be observed when discussing functionality and/or quality with users, they don’t qualify a missing feature as a quality issue, but as an enhancement – and so do we as software engineers.

Okay, so 2 different objectives when developing software: 1) develop the right product and 2) in the right quality. Right product means that the product does what the user expects it to do, contains the right features. Right quality means that it does the former, without trying to ruin your life in the process – by – say – continuously crashing, or by any other means makes it unnecessary complicated to get your task done – hit the [ANY KEY] (some users actually got confused and tried to locate this key – no kidding!)

Question becomes, can a methodology help you to build the right product in the right quality? Personally, I don’t think so. However, a methodology – actually any methodology – can be a good starting point for building appropriate structure into a new project. Existing methodologies can be a source of inspiration on how you could do it. It’s much like a food recipe, if you follow it 100 %, you get something that’s not quite like on the picture and it doesn’t really taste as good as it looks (on the picture in the cook book that is).

That’s all good, but how do we then built the right product, in the right quality and at the right time? The answer to this perpetual question, and it is really perpetual as it’s been tried answered in tons of articles over the last 30+ years, isn’t 42. Probably more like 42+ something.

The Requirements

This may seem bleeding obvious, and it really is bleeding obvious – but apparently it’s very hard to get right, otherwise, we wouldn’t have late projects, wrong applications or defunct products. The key to the 3 R’s is the 4th R, being the Requirements. Having the requirements sorted out allow you to built what’s expected, to provide more accurate estimates (not just guestimates, or wise ass guesses) and also allows you to construct the test cases needed to validate the software against the requirements. Pretty obvious – huh? Well, apparently not!

Waterfall

If requirements are so important, why not gather them all up front before even starting to code? Not a bad idea! And in essence that’s what the Waterfall methodology is all about. Phased development plan, with well defined processes and stages for moving from one phase to another. Widely adopted and used methodology until the late eighties. For the waterfall methodology to be successful you need to be dead sure you got all your requirements right in the initial phase of the project, if not – there’s a high probability you’ll be hosed when delivering, and users will go: “Dude, I still can’t find the <ANY KEY>” or worse (maybe) “Dude! This is what I asked for, but didn’t expect” (more on this particularly scenario later).

Lots of empirical research indicated that waterfall works fine for projects that’s either extremely expensive or, if done wrong, kills the end user. Either way, if you don’t get the stuff right you’ll either be prosecuted and go to jail or lose your business. Huge motivator for getting it right – right?

Lots of other empirical research showed that for software projects, the whole idea of understanding the problem domain upfront seemed impossible. Mostly due to the shorter life cycle of software products compared with their more expensive hardware ones. Also, the investment model is different for software products, as the majority of the costs are salary. For e.g. chip manufacturing there’s a huge initial investment prior to producing, which is building the manufacturing plant.

Post Waterfall

Gathering requirements is an extremely difficult task, mostly because most users when asked what they want go: “Dude, show me what you can do….” or “something like who knows, that can – you know – when you hit the – whatever key…” Sigh! Very hard.

It turns out that users really can’t relate to the majority of the means used to communicate the end result. However, what users can relate to is the end result – the product, but problem being that it’s hard to change the final result. Somebody then came up with the idea of iterative processes, which essentially breaks down the development cycle into mini cycles, that each have all the phases known from the waterfall methodology: requirement gathering, analyses, design, implementation and testing. But added an evaluation phase, where the users evaluate the newly developed functionality.

Over time more and more iterative methodologies have emerged, but they all originate from the idea of splitting the phases into smaller cycles and including the users to evaluate the result on an ongoing basis, until the product is ready.

Better Software

If better software is defined as the sum of RP + RT + RQ where RS is right product, RT is right time and RQ is right quality. And we agree that the requirements actually are a key driver for obtaining RP + RT + RQ, then I believe that newer methodologies (or at least all methodologies deriving from iterative ones) will provide better software.

This being said, then personally, I believe there’s a small issue with not knowing the requirements initially as it’ll be very hard to get an initial estimate to cover RT. There simply need to be an initial phase prior the iterative process called high-level requirement gathering. The product of this phase is essentially a rough blueprint/proposal that top level explains the purpose of the system.

This leads to: for RP + RT + RQ = True, requires R. Meaning that to deliver right product, at the right time in the right quality you need to understand the Requirements.
#requirements #programming #software #engineering