Guess and Check
Submitted by Bob Walsh on Thu, 2006-07-20 13:12.
If you’re going to successfully fire up your micro-ISV, you need to fire your old ideas about software development, be they UML, RUP, agile, SCRUM, extreme or none: they fit like shoes on fish.
Every single methodology for developing software I’ve heard of in over 20 years in this business assumes you’re part of some vast team of programmers, never a programmer working alone. What’s more, each and every existing software development process assumes someone is going to hand you a nice gift-wrapped definition of the problem you’re going to solve via code. That is exactly what won’t happen when it comes to developing a micro-ISV app or web site.
Today’s software design theories are like using a power drill as an ear cleaner - they can be used, but it’s not a good idea. We need a better approach, one based in the reality of one or maybe two programmers who must also define the problem and its solution and who want to do so before their savings run out.
Don’t underestimate just how hard defining the problem domain is, or just how difficult it is to nail down in the absence of actual customers who will tell you what they want. Unless you plan to take a few years unpaid leave from your life to do intensive market research, endless focus groups and surveys, at best you are only going to have a very approximate idea of who is going to be using your software how to solve exactly which problem in what precise way at least all the way through to your public beta.
Submitted by Anonymous-Blog on Mon, 2005-12-19 11:39.
Well, we have our first victim for the Anonymous Blog. I've been in a situation similar to this before, but wanted to see what the community thought first. Please add your thoughts or if you'd like to post yourself, please let me know. - KC
I did a significant amount of work for a client - over 60 hours - for an application which an outsourced team had already failed on. I took over the application with an extensive bug list (20+ issues), some feature enhancements (10+), and some other conversion issues, etc.
I did the work in two stages. One in late spring to close the bugs and the second in early summer to add the functionality with a signed agreement in place stating that payment would happen this fall. I offered the standard 30 day bug fixing period and when the last issues were fixed in June, there are little communication with the client other than getting final signoffs on everything.
Two months later the client contacted me with a potential issue. Even though the bug fix period was long over, I worked with him to reproduce it and we were unable to. It faded into memory. Two months later, when the bill actually came due, the client said that he wasn't going to pay because "there are these bugs"... one of which had been reported, but months later.
Advice? Thank you.