Costs of Software Beyond Code

So I might as well end my blog posting drought with a stupid gripe.

The software development cycle is but a small subset of the actual software product release cycle.

Sure, a lot of people are talking about Agile processes and getting a new release every sprint and whatnot but cutting a release for most software development teams means the following:

• We have some features developed!
• It's passed some sort of regression testing!

Especially in larger organizations, this is far from what's required to get a release out the door.

I work for a company where the developed software typically has 3 types of consumers:

• Developers within and outside the company
• A couple hundred marketing/accounting/operations folk who are in the same physical location as us
• Thousands of marketing/accounting/operations folk that are scattered around the country

Oh by the way, bullet two govern rules for bullet 3.

Coming from a large "systems of systems" integrator-esque company, it comes as a surprise to me how little care people take for delivering to another developer team.  Of course, they care when they're at the butt-end of the stick.

However, what's even more surprising is when a team isn't aware of all the work involved once a release has passed QA.

Especially for those thousands of folk scattered around the country, there's a boat load of preparation going on.  Training material, help documentation, videos, webinars, and conference demos are done to ensure that major features or even changes to existing features are flowed out and can be referenced in the future.

... and THEN there's the support and any issue investigation in production.  

The amount of personnel devoted to this is practically the same headcount as the development teams.

The absolute worst thing any team can do is simply provide these people some new features and say good luck!  No release notes.  No Requirements that fed into this.  Nothing.  Else.  Awesome.  You just tripled the cost of all the post-development work.  You probably tripled the cost of QA since you probably did the same to them as well.

I am of the firm belief that solid requirements that are reviewed early on by everyone in the release cycle is the key to efficiency in any software project.  The key words being reviewed and everyone.  It's pretty much everyone's responsibility to ensure that this happens as early as possible.  Unfortunately, what happens a lot is that everyone pretty much throws their arms in the air saying that it isn't their job and a combination of snowball and broken window effect happens.

I'll try to talk about a Shangri-la scenario in a Scrum perspective and also talk about what the overall deliverable set should be.

When I get around to it.

Not-So-Random Gripe: Inaccurate Data on the Internets

Ok so while I was writing up the yet-to-be-finished post, I soon realized that a crap load of them menu websites are pretty much throwing in the towel and turned to this service called "SinglePlatform."

Now that's great because there's nothing more annoying than ensuring that things are updated on multiple websites, but I do have to gripe about the inaccurate menu that Single Platform did for the website:

Ok so the page is pretty blurry, but it's the same freaking menu for two restaurants, one being the Gumbo Shop in St. Louis and the other being ONE of the Gumbo Shops in New Orleans.  I'm sure this service is new and all, but at least have the quality control to simply say "we don't have the data for this restaurant."  It's understandable if you bought bad data from them business listing services (they really do suck), but I'm making an uninformed conclusion that this involves some silly assumption likely done by some code doing a massive data dump that matched a menu with said restaurant.

This is probably one of the most annoying things about Web 2.0 sites in general, as it's created a complacency of "we'll put up inaccurate stuff and the people will correct it" bullcrap.