BKeeney Briefs

Someone asked me the other day what ‘feature complete’ meant.  I replied that I felt it meant that everything you intended to put into the application is there and not missing.  Other people gave other responses but it got me to thinking.

Here is the definition of ‘feature complete’ from Wikipedia:

A feature complete version of a software is not yet final, but contains all intended functionality of the final version.
Usually a feature complete software still has to undergo testing and bug fixing as well performance or stability enhancing before it can go to release candidate and finally gold status.

I think the semi-permanent beta status of open source and web software skews our expectations.  We’re so used to the term ‘beta’ being applied to software we’ve really lowered our expectations of software.  It used to be that software at the ‘alpha’ stage was feature complete but functionality could significantly change with usability testing.  ‘Beta’ stage was when all functionality was complete and usability testing started, usually by allowing a bigger group to test it.  Any bugs get fixed and a new beta version is released to make sure the bugs were fixed and no new bugs introduced.

Finally, the ‘Final Candidate’, or ‘Release Candidate’ was a fully functional version of the software that if everything worked properly it would be released to the public.

The Wikipedia definition for ‘Release Candidate’:

The term release candidate (RC) refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage of product stabilization (read QA cycle), all product features have been designed, coded and tested through one or more Beta cycles with no known showstopper-class bug. When a version get to the Release Candidate cycle, only one iteration should be necessary.

Obviously, these definitions are fluid – at best.  Problems discovered late in the beta stage could seriously affect functionality and certainly a major flaw discovered in a Final Candidate could (and should) push a public release back.  If you have a ’set in stone’ release date, however, how does that affect your releases?  I imagine that it severely limits your flexibility if major problems are found – especially if you have some sort of contractual obligations to release.

Is this your understanding of the software process?  Or is software now so complex and so fluid that we need lowered expectations of what software should be capable of doing for us?  Is it okay to release with known bugs as long as it’s ‘good enough’?

Product registration and licensing systems is a fairly common call for help on the REALbasic forums.  I know I’ve rolled my own registration system and used various commercial solutions over the years.  In fact, we came up with a solution that works with desktop apps using a licensing system meant for servers.  That solution has worked well, but time goes on and what was good for years might not be such a great idea now.  Software grows old and stale and new solutions are born.

To me it seems that there are a couple of issues to deal with.  The first is keeping casual piracy down to a minimum.  I have no doubt that someone determined enough can pirate any piece of software.  It’s just a fact of life-get over it.  This means that if someone pays for the software they can’t post the registration code and have it go all over the internet.  Or if they do, it quickly gets squashed and it’s no longer valid.  Another consideration is that I don’t want to piss off my good customers because my licensing scheme is so draconian (I’m looking at you Microsoft).

The second part of the equation is getting paid.  People want to use PayPal or their credit card (and occasionally checks via snail mail) but setting some of that up on your own is a pain.  PayPal is probably the easiest but I know there are segments of the population that refuse to use it.  Plus I want my money sooner rather than later.  If someone else is handling my money will I have a waiting period or minimum balance before I get to see the money?  Is it an automatic transfer or is it via check?

The third part of the equation is administration of the system.  How easy/hard is it to add coupon codes?  Can I get detailed sales reports?  How easy is it to issue to refunds?  Can I email customers with news?  And do those customers have an easy way to opt-out of future emails?  Can customers retrieve their licenses without manual intervention?

The fourth part is how easy/hard is it to integrate into my application?  Do I have to come up with my own registration code algorithm?  How do I convert existing customers over to the new system?  Does it work on Mac, Windows and Linux?

So I want it good, reliable, cheap and fast!  No pressure there! 

Kagi and eSellerate seem to be two fairly common solutions.  Both take a chunk of money from the sale price and until I saw the Apple app store I thought their commission was a little high.  Perhaps it’s worth the hassles leaving all of the server details to someone else (after having dealt with server issues in the past six months it might be worth it!)

FWIW, I used Kagi several years ago and was not very impressed with their responsiveness to support issues.  I also found their interface for making a webstore to be very clunky.  Hopefully they’ve changed, and if so, I’d love to hear about it.

What are you using for registration systems?  Do you like it?  Was it easy to integrate into your application?  Has it helped income or hurt it?  What sort of problems have you had?

I ran across this post today:  http://blog.bitquabit.com/2009/07/01/one-which-i-call-out-hacker-news/ The basic story is that the author is refuting the claim that StackOverflow.com could be replicated “easily”.

I think this is an awesome post because it’s a warning to others and reminder to myself that everything is not as easy as it seems.  Often we look at an application and say, “I could do that.”  Yes, you could.  Without a doubt.

Here’s my advice though:  Take your estimate of weeks and make it months and turn months into years and you’ll probably be closer to the truth.  Even copying user interface and data structures verbatim I think most people would still have a hard time replicating an existing application quickly.

One project I worked on was a QuickBooks-like accounting application.  On a four person team.  Five days a week.  For FIVE YEARS!  And we had QuickBooks as the blueprint, if you will, for the accounting side of the application.  Guess what?  Even though I’ve moved on they’re STILL adding to and modifying the accounting engine.  QuickBooks is a moving target and I wish my old teammates luck in striving for it.

Every now and then someone gets a hair up their rear end and brag that THEY could do REALbasic better than REAL Software (because some bug has really pissed them off).  It’s quite possible that someone out there is working on an awesome RB clone and someday release it.  But don’t expect it anytime soon.

The same goes with claims of “I could easily make the RB IDE do this or that!”  If it was easy no doubt RS would already have done it.  Let’s face it, software is often a case of the mistakes of the father now make our lives a living nightmare.  This is not to knock our forefather developers just that what seemed like the best way five or ten years ago is woefully inadequate in today’s terms and to make it do ‘x’ (which seems easy) isn’t because the infrastructure isn’t there to do it.  So the whole thing has to be redone and done so you don’t break backwards compatibility.

Again, sorry for the blog about another persons blog.  I hope you find these discussions helpful and thought provoking.  Thoughts?

As a software consultant I get asked by non-software developers why do people  have me write custom software when there are easy-to-use tools out there, like Microsoft Access, FileMaker, Visual Basic, and REALbasic?  It’s a tricky question to answer because they aren’t software developers nor or they power users.  They use their computers to write documents, email and surf the web – not exactly the rocket science apps of the world.  So I came up with an analogy that people understand.

This comes from the world of ‘Do It Yourself Home Repair’.  In my younger days (you can read that as not having a lot of money) I would always take a stab at doing all those little projects that come with owning a house.  Faucet needs replacing?  No problem!  I’d go size it up as best as I could, go to the hardware store and pick up what I thought were the parts and tools I needed.

Some of you know where this is going.  On the second trip to the hardware store I’d get the parts I REALLY needed to do the job and on the third trip to the hardware store I’d pick up the things I had no clue I needed to begin with (or possibly to fix what I broke in the process of fixing the original problem).  The final trip to the hardware store is to return all the unused parts.  And all that is assuming I don’t find a leak in the next day or two (or two weeks later).

Did I get the job done?  Sure but it took three trips to the hardware store and an entire day to do it.  I called a plumber to do the same thing recently and they were in and out in 30 minutes and if I’m not happy or something doesn’t work right they come back out (typically for free because I’ve already paid).  My job isn’t too much different than the plumber.

When people come to me for a project I can guess how much work is going to go into it a project before I’m done reading their requirements document (if they have one).  I’ve worked on three accounting applications and the ones that don’t like their current accounting app get excited about that.  I tell them that unless they’re willing to spend a boatload of money and wait a year it won’t happen.  Applications of that complexity are huge, hairy monsters that take time to develop and even then there are yearly (and sometimes monthly) updates (especially if you want payroll taxes calculated automatically).

Sometimes it’s a shame that there are easy-to-use products like FileMaker, MS Access and to a lesser extent Visual Basic and REALbasic.  FileMaker and Access are  powerful tools that let mere mortals do some complex things with a database.  Just like me having a set of minimal tools doesn’t make me a plumber these tools give the user the false impression that they’re a full-fledged database developer when in reality they know how to use some tools.  That’s not to put these folks down because they’ve done some really cool and complex work.

The plumber has a truck full of fittings and miscellaneous parts.  He or she also has a set of specialized tools to aid them in their work and have years of training.  Likewise, software developers have  specialized tools to help us as well and we have years worth of miscellaneous code, controls, libraries that we’ve learned to use.  And perhaps most of all, the software developer knows how to use the tools and parts together.

So sure, you could do your software project yourself and you’ll learn how to do preferences, file I/O, database operations, error handling, licensing and registration, automatic updates, custom controls, and a million other little things.  Software developers already know how to do that.  In the long run, how much is your time (and frustration) worth?

Thoughts?  Did I use the best analogy?  What other benefits are there to having a pro write your software for you?  Do you have any drawbacks?

I ran across this blog today titled Wide vs Deep and it got me thinking (which is always a scary thought). The blog is about how programmers are promoted to managers even though the thought processes are different. Managers are wide and shallow and programmers are deep and narrow.

While the article specifically references programmers that get promoted to managers I think it’s appropriate to talk about it since many of us are small business owners.  That means that we don’t have managers and programmers.  Forgive my poor English when I say, “We is it.”  So how do those of us that do both deal with being the programmer and the manager?

I’ll start off with a little bit of my background since I think it explains a lot about me and how I think about things.  I grew up in farm country in rural Illinois.  My role models growing up were men that with bailing wire, chewing gum and a welder could fix any piece of machinery under the sun.  None of them were specialists in anything and had a very wide grasp of reality.  They were tenacious and didn’t give up.  I think that’s the nature of being a farmer.

I attended an engineering college on the south side of Chicago just blocks away from Comiskey Park (and the Robert Taylor homes but that’s a different story!) where I earned a degree in electrical engineering.  Going to a private school was a struggle financially so I co-oped, did internships and worked my way through school in six years.  My education ran very deep and narrow in areas related to electrical engineering although you can argue that electrical engineering touches many areas of engineering (thank you very much for that lovely class called thermodynamics, by the way).

By the time I had graduated I had two full years of experience as an engineer and landed a great job solely because of my experience.  In my new job working in an industrial environment (steel mills and foundries) there was “the problem.”  The problem might be simple or complex, but it was my job to figure it out.  One day it might be fixing a glitch in a PLC program, looking at the circuitry of a steel hardness testing station, programming a new labor saving device or doing the load calculations for a new transformer.  The solutions involved researching the issue, evaluating the solutions, engineering the solution, getting the approvals to do it, and then do it!  I would call that the funnel approach since it starts wide and narrows down considerably towards the end.

As a software developer and the owner of a business with programmer employees I find myself being torn between being wide and deep.  I can’t do both at the same time and I can’t switch between the two quickly or easily.  When I’m in management mode I just can’t go deep without a transition period.  Thankfully, going from programmer to manager is an easier process even though it’s frustrating not being able to finish what I was working on.

From a project management standpoint I don’t need to know the details of the class/module that is being used or modified – I just care that there’s a solution.  But the programmer is concerned with the implementation details of that class/module.  They couldn’t care less (most of the time) if the customer is 30 days past due on an invoice or what the next project is.  They’re too deep into the details to care and, besides, that’s a “management problem”.

If you’re the sole developer in your business, it’s all too easy to miss the details or go too deep into the details too soon.  If you’ve ever been thinking about the code at the bidding stage and you’re designing classes or thinking about the details of how you’ll implement the project then you’re probably too into the details too soon.

Likewise, when you’re creating your bid, you can’t just guess at how long or much money a project should be.  You need to determine some of the details and maybe do some proof-of-concept programming before creating the bid.

So it’s not just as simple as being wide or deep.  You have to manage the process – especially if you’re on your own.  Here are some recommendations you can try.

1    When you first start looking at a project don’t go too deep at first.  Write down all of the major areas you (as the programmer) will need to take care of without getting into implementation details.
2    Identify those areas that you need to research and do some proof-of-concept programming.
3    Do your research and proof of concept programming but do NOT polish it.  Do not spend a lot of time on it, but also code like you’re coming back to it later (which hopefully you will if you’re awarded the bid).
4    Stop and re-evaluate your original major areas and assign values to them and finish your bid.

Once you have been awarded the work, you can use the research and proof-of-concept coding as a starting point.  You can start going deep into the details and code but keep in mind that the management of the project is not over yet.

As you gain experience it becomes easier to estimate.  You just ‘know’ that it takes a certain amount of time to do some task.  You’ve done it before and you know the pitfalls and complications that can arise.  (Shameless plug coming)  Use a product such as Task Timer to track your time.  If you don’t know how much time you spent on projects in the past how can you accurately estimate similar projects in the future?

In a future post I’ll talk about how to climb back out of the pit of details.  So what are your thoughts?  How do you avoid going too deep too soon?