Sunday, January 26, 2014

Cost Beyond Code #2

Some quick feedback on my rant mainly wanted some examples of a costly situation that is a result of poorly managed requirements.  I'm going to use a lot of "probably's" and "likely's" so just bear with me :P

The Project


  • Requirements are maintained in word docs on a shared drive (not Sharepoint) where the filenames are along the lines of "Release - June 2007" that nobody's opened in years.  Essentially, they're practically un-browseable and un-searchable in any decent amount of time.
  • These requirements were never formally reviewed by anyone.  People would show those groups like QA and End User Trainers "how it should work" in a 1 hour meeting.
  • Developers tend to "own" things where one feature set is entirely done by a single guy.  No recorded code reviews.

The Costly Situation


  • Some piece of software has a feature that has been working in production for a couple years.
  • An odd behavior comes up it is keeping an order from being Billable.  For arguments sake, it is a scenario that hasn't come up in an extremely long time and there's no documentation in the IT Ticketing system of how this was resolved the last time.
  • The guy who coded it is no longer with the company.
  • None of the "expert" users know how the software SHOULD react in the given scenario.
Cost #1: Operations
The earlier you have that money in the bank, the earlier you're making more money for you.  If this is visible to the customer, you run the risk of their simply cancelling and going with a competitor.

So let's say this IT ticket rises through the different levels of support and reaches you, the developer.

Question #1 - Have we ever encountered this scenario before?  What did we do last time?
  • If you're pretty immature about your requirements maintenance, chances are you're pretty immature about your bug tracking too.  For me, this is a classic example of a Broken Window phenomenon in a software development project.
Question (set) #2 - Why is this happening? Is it a bug?  Did the requirements cover this when the feature was developed?

There's absolutely no reason for you to look up the requirements.  You're not going to try to wade through 10's or even hundreds of Word docs that were meticulously documented but whoever wrote them didn't really think about how to reference back to them.  If you're not a developer, the one thing left to do is at least dork around in the stage environment to reproduce the issue.

Cost #2: Support Investigation
Even if the issue is reproducible, without the requirements from when this feature was developed, you probably can't answer the question "is it a bug?"  "Why is this happening?"  Without the context of the requirements, reproducing the issue can be a significant challenge.

You're still going to need a developer to look into this.  However, it is extremely likely that in this scenario the first 2 questions aren't even asked so one could argue that this cost in labor isn't even accrued.  :P

OK DEVELOPER SAVES THE DAY.  Not Really.


Ok you're investigating the code to answer Question #2.  You're likely wading through code you're unfamiliar with.  At this point a lot of people will argue that this like ability of the investigator, coding conventions, and quality of code will impact how efficiently this investigation will be accomplished.

Question #3 - What is the context of this code?

Commit messages can help.  Code quality can help.  However you likely don't have any linkage from a commit message to the actual requirement.  That would come in handy, but like we said, that stuff isn't there for you.  So the differentiation between "this is by design" or "this is a bug" is close to impossible.  It's going to take you some time to figure out what's going on in the code, describe it to somebody, and hopefully have a solution on what the user should do to keep the Order moving forward.

Cost #3: Developer Support
What could have been answered from a requirements lookup has now extended to any other full-up bug investigation in reproducing an issue and passing it onto a developer.  You're going to have some back and forth between the developer and others in terms of trying to answer "why is this happening" question.

Question #4 - Is this by design?

You can't tell.  Chances are this will be dependent upon your opinion of the guy who wrote it.  Either way, it's going to be pretty hard to answer this question.  It will be up to some pointy haired person to decide that it is a bug that needs to be resolved right away in the code, that the business needs to update their procedures to be aware of this scenario, or that some behavior change is required to go through some other channels of funding.

Cost #4: Aftermath - Because you haven't come up with what the requirements were at the time the feature was implemented, you can't hold the business accountable for what discussed, reviewed, and implemented.  It is generally easier to get a customer to swallow the "this is by design" story if you have the documentation to back yourself up and simply update their processes.  

Some people will say that some email will be required to accomplish this but that's in lieu of a decent requirements tracking system.  Without this documentation, you're likely going to take up some time to discuss whether it's a bug (money from the IT Bucket) or a new feature that needs to be implemented (money from the Business Bucket).  

Either way, in order to move forward, the relationship between business and IT runs more smoothly if the conversation goes down the path of "ok now we know what the thought was when we implemented this, but we'd still like to submit a change request," vs. "we're going to just have to agree to disagree so what are we going to do about it?" 

There are a lot of pieces that need to be in place to reduce all the costs identified.  However, requirements that are clarified, reviewed, and traceable are key to making all those pieces be in place (and alleviate the cost of that too).

A common reaction of all of this is "Documentation is always out of date when the code is implemented"

This is what User Stories in a Scrum process are meant to alleviate.  I'll talk about this in some User Story post, but I'm already getting requests for describing the costs of getting a Release out after a Release Candidate has been cut so that might just be my next post.

Friday, January 24, 2014

Oh Hey This was in Draft for a Year

I had the opportunity to speak with someone who left the food truck business.  Food trucks are an interesting beast as they are just now becoming a pretty common in the St. Louis area.  Sure, there are some pretty well established hawker stands like that dude with the boombox at Olive and 6th, but the idea of getting your food off the street is still a new experience for a lot of St. Louisans during the workday.

Anyway.  I was looking at my blog stuff and saw that I still had notes for a post here.  I'm too lazy to see about actually putting these things into wordy-form so here they are.

The Idea

Provide a food truck meal with a gourmet twist.  Meals that included a side and a drink started a $7.

How it got Started

A loan for $50,000 from a combination of friends and family

3 partners - 2 ran the truck, 1 ran the business plans, supplies, and red tape.  The lady I talked to was #3 and would sub in whenever one of the other two wasn't available.

Making Money 

Stick with the city - County had way more red tape.  Only ventured there for single-day events like Stl County Parks

Sporting Events?  There were rules about the trucks that made it too much of a pain.

Tried to do catering events.  That seemed to go well but again, that only worked well in warm weather.

Competitors

Brick and Mortar - there is a rule that you can't be so close to a brick and mortar competitor.  That was annoying.
Other Trucks - Sure they tried to organize with each other so that they wouldn't cannibalize each other's business but a lot of times some of the other trucks ignored it.  You'd think you'd have a spot all to yourself and then boom.  Your lunch crowd just got cut in half because another truck showed up.

What happened at the end?

The Partnership ended when one of them just didn't want to bother anymore.  Business plan lady actually had a full time job so she didn't have time and they didn't feel like bringing in a new partner.

I personally thought the food was pretty decent and nowadays, lunch for $7 without a drink is pretty reasonable.  I really appreciated her speaking with me.

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.