Monthly Archives: December 2011

The Grinch Stole My Christmas

I recently was asked to do some programming work for a startup company through a referral. Not an unusual request since many people have difficulties when they attempt to start an ecommerce site. The problem they were unable to surmount halted further programming on many other related areas because they were not able to process credit cards. the reverse side of a typical credit cardWithout a revenue stream they were going nowhere fast. Their problems were exacerbated by having previously announced to their potential clientele they would be open and ready for online orders. As I understood it, they had made this announcement in September and they first contacted me in November. I documented some of their issues in a prior post.

As time passed their anxiety of course increased, transferring their frustration to me, instead of answering my questions I would get answers such as, “why do I need to know that?” and “big companies do it that way, we aren’t a large company” and so forth. Their anxious behavior and my frequent association with the person that invited me into this situation overrode my business sense. I was experiencing a tooth problem driving me to distraction so I failed to do what every self employed business person needs to do before starting on a project.

Yes, you might anticipate what happened, I solved their credit card processing problem but when it came time for money to change hands for services rendered, I was given the short shrift. The principal contact changed their story on how I would be paid or how much and then I was finally offered to accept 1/3 of my invoice and the rest of the balance would be my payment for all their other issues, which came to the forefront once this major hurdle was resolved. Needless to say I now awakened to the real possibility I was dealing with a less than honest person and the likelihood of seeing any payment now or in the future was about nil. I sent off an email for demand of payment in full and cutoff all further service until such time as payment and an agreement for future payment for services rendered on their behalf.

I was given an offer to accept this balance for all of their foreseeable related programming work and a yet to be defined full time employment contract would be forthcoming. On the one hand I should accept this offer, which constituted about 10 billable hours of work and then accept the remaining 20 hours as payment in full for the “rest of their work until it was finished.” Doc 44783 PaymentsOh, and they would be offering sometime soon an opportunity to go to work for them full time. I could hardly wait for the sheer joy of that moment… I’m sorry but I can do all the free work I want at my church and get a lot more thanks for it as well.

I called my grandfather and talked with him and his experience as a self-employed businessman. I asked him if in his 40+ years of work, had he ever got shorted out of a payment for work? He said the worse that happened was he wasn’t paid for ½ gallon of paint. Now that speaks volumes about the way we have accepted dishonesty to be part of our lives.  Many people see it as a way to advance themselves by either short changing or paying so little they can profit more through the loss of others. It’s a terrible and short sighted way to do business but as my grandfather says, it’s more about “yea me and boo you”.

It’s part of the reason we are currently in this economic mess. The haves want to make as much as they can and the rest can go pound sand. Bah Humbug! Merry Christmas to all their selfish little selves.

Categories: What's Up | Tags: , , , ,

Software Development and Discipline

Seldom does anyone call on the use of a person’s skill because they were an experienced Marine Sergeant but my recent coding assignment experience demonstrates exactly what can happen when a project becomes bogged down and all the players are scrambling with no coordination.

I found there were really several problems in examining the current situation but they can be summed up in two Marine Corps fundamentals; team work and discipline.Oh sure you might say, use old examples of your past life on modern problems forced to fit your model.

Lets examine the problem. A software glitch exists which prevents a satisfactory processing of a credit card. Essentially there are two participants in the control of the flow of this information;(1) merchant credit card processor(2) end merchant providing customer transaction

Each one of them insists they are doing things correctly but the end result doesn’t agree with their assertion.

This is after all an everyday transactional process performed by thousands, perhaps millions of online merchants. Why is it so difficult for it to work here? Are the people running the organization incompetent? The programmers are unable to do their jobs? Is this a first time for everyone involved? The answer to all three questions is a resounding no! Then why does this problem exist for several months?

When I was asked to step in and help correct this specific problem I ran into several unnecessary roadblocks which were; finding the right people to ask questions, evasive answers or answers that didn’t match the questions, achieving routine communication with all of the participants.

How does this scenario stack up against real world successful development? Let’s step back and see what other successful methods are used in developing workable and maintainable code

.What is “Modern Software Development”? 

  1. Do you use source control? 
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?

If the answer to any or all of those questions is no, then a discipline problem exists. Steve McConnell described Software’s Ten Essentials in 1997, ten things that every software project should have:

  1. A product specification
  2. A detailed user interface prototype
  3. A realistic schedule
  4. Explicit priorities
  5. Active risk management
  6. A quality assurance plan
  7. Detailed activity lists
  8. Software configuration management
  9. Software architecture
  10. An integration plan

Perhaps added to those lists which always become important even if left unsaid:  Do you have buy in from stakeholder/sponsor?  Are your customer’s expectations managed?  Do you have the right people for the tasks?

Often management which routinely represent the stakeholder, focus most of their attention on meeting schedule and identifying the right people. If there is anything I learned from my military experience is, people can be a problem but they can through awareness and motivation be trained to improve to accomplish the work. Using people like cannon fodder only creates losses and doesn’t achieve your aim.

So the focus on just two areas of the software development Hydra may work against rather than for a timely solution.

Team / Project Management

It has been said but usually not found that synergy is found when the combined effort is greater than the individual sum of the components.

An ideal team works and functions that way. Sports teams attempt to achieve it, actors publicly pronounce their latest achieved it and politicians promise it when you vote for their side. In reality it is seldom found but something that reasonably emulates it will provide consistent positive results.

Books have been written on the topic ad nausea, but this is a simple overview excerpt from an Air Force manual ~ Disciplined Software Development by the Embedded Computer Resources Support Improvement Program (ESIP) April 1999.

The Team Software Process® are techniques to “guide engineering teams that are developing software-intensive products. Using TSP helps organizations establish a mature and disciplined engineering practice that produces secure, reliable software in less time and at lower costs.” TSP has been proven to work for teams both large and small.

Comparing Software Development to Football

Success Factor      Software Development American Football
Team Building Project Kickoff Spring Training, Weight Training, Practice Time
 Detailed Plans  Project Plan Plays (blocking schemes, pass routes, etc.)
 Team Work  Weekly Project Meetings Periodic Huddles (allow coordination) Game Plans (emphasize team strengths)
 Defined Processes Organizational Software Process Nomenclature, Weekly Practice Schedule, Running the Playbook

“An organization’s processes and a team’s detailed plan describe how the various team members interrelate. The organization’s process captures the high-level plan outlines, the organization’s standards, and mechanisms for capturing data about project performance. The team produces a detailed plan by tailoring the plan outlines in the organizational process to project specifics.”

A short summary of the above quote;

  1. Fail to plan, plan to fail.
  2. Failure to follow a plan gets you lost.
  3. Failure to revise a plan that isn’t working, guarantees incorrect results.

Last but not least if you fail all three of those concepts, you are broken, lost and don’t even understand how.

I have to admit, this latest venture into my recent coding assignment has resoundingly received a negative response on those last 3 items.

Maybe it’s time for a Marine Sergeant?

Related articles

Categories: Information Technology, What's Up | Tags: , , , ,

Blog at WordPress.com. Theme: Adventure Journal by Contexture International.

Follow

Get every new post delivered to your Inbox.

Join 38 other followers

%d bloggers like this: