Skeptek.com

The Five Stages of Operations Grief

I think I’ve spotted a trend.  I’ve been developing software for over 10 years now, and I have observed a humorous pattern (well humorous sometimes) when it comes to telling your operations guy something is broken in production.

My current ops lead Philip is a perfect example of this behavior.   Tell him something is busted in prod, and he delivers a series of predictable responses.  So without further delay, I give you the Five Stages of Operations Grief:

Me: “Philip, user’s arent getting any email from our website.”

1. Denial:  ”Wasn’t me.”
2. Anger: “You want me to wake up NOW and fix it?”
3. Bargaining: “Can it wait till I wake up?”
4. Depression: “I can’t believe I have to wake up and fix it.”
5. Acceptance: “Sigh…. Try it now.”

December 7, 2010 Posted by Keith Forsythe | Development Management | Leave a Comment

Here’s another one for the outsourcing horror story collection

• Matthew/Chicago/: Srini I’m in a room filled with 20 very concerned UAW workers trying to run their new line financial pareto reports for the US financial accounts. This is one of the BTO transition items I have to get setup for the client ASAP.
• Srinivasanu/India: Yes Matt this is Srini.
• Matthew/Chicago: Yes Srini I know. I am inside of the report we are stuck on the case number selection field which has been searching for results for approximately 5 minutes without a result.
• Srinivasanu/India: Yes Matt. Are you connected into the internet?
• Matthew/Chicago: Srini yes I am connected to the internet. There are no values showing up in the prompt selection. The report is failing. People are not happy I’m in a room filled with upset union workers. I’m wasting their time.
• Srinivasanu/India: Matt can you see if you can get to the Google.
• Matthew/Chicago: Srini I’m connected to the internet I’m speaking to you on the internet.
• Srinivasanu/India: Yes Matt internet is not issue.
• Matthew/Chicago: You and the team marked this as a passed item in your SIT testing according to the client. Note the test cases all mentioned a specific value to search on 12501 for example case number 2 does not work. The users are trying to do the same it is not working.
• Srinivasanu/India: Matt yes I test the field and when the field didn’t return value I skip it.
• Matthew/Chicago: Srini did you skip everything that was not working and just mark it passed?
• Srinivasanu/India: Yes Matt.
• Matthew/Chicago: So you have no idea what you’re doing? Is this a correct assumption?
• Srinivasanu/India: Yes Matt.
• Matthew/Chicago: I think I’m in the Twilight Zone.
• Srinivasanu/India: I not get message Matt.
• Matthew/Chicago: Get up now walk over to Prasad and let him know you are no longer on my project. Tell him to get the entire team in a conference room in 10 minutes and to dial in my line. You’re not invited. Do you understand this?
• Srinivasanu/India: Yes Matt I think there is a problem.

August 31, 2010 Posted by Keith Forsythe | Development Management, Project Management | 13 Comments

Benefits and Tips for Offering a Third-Party API Program

Partner programs that offer an API (application programming interface) for 3rd party developers can be a great way to:

• Acquire users inexpensively.  Ultimately, users of the third party application will learn your brand and make their way back to the mother ship.
• Cheaply increase your development efforts by incenting third party developers to build interesting applications on top of your API or include your API exposed services as a complement to their core application.
• Ultimately, increase your revenue.

When designing your API program, consider the following.

• Start off small, offering a small set of core services.  If this proves popular, then selectively increase the API offering.
• If you also offer a client application, you may not want to offer every single feature so that users eventually end up migrating to your own application client.  You may also want to disallow competing applications, only allowing your API to be used as a complementary piece of content in third party apps that do not directly compete with your business.
• Set a minimum split amount that a developer’s third party app must produce in business before they get paid commissions.  This will save time and money in micro-payments.
• Publish the split, and avoid any negotiation.  It takes too much time.
• Standard contract ready to go.
• Good documentation, forum, sandbox development environment, and make sure to budget time for a developer to monitor the forum.
• PR for your API.  Development groups and local programming meetup’s make a great spot to spread the word.
• Use simple API technologies, like RESTFull services or simple HTTP XML or JSON services if you can. Avoid complex SOAP services if you can help it because not everyone can do SOAP easily (ahem… Ruby).

So get going on your API program, and get on to the internal arguments of what services to expose!

August 10, 2010 Posted by Keith Forsythe | Business Strategy, Product Management | 1 Comment

iPad… The new 10 inch home of the App Store

The brilliance of the iPad is in Apple’s decision to run the iPhone OS on it.  The iPhone OS was a great choice for the iPad, as supposed to porting their standard computer operating systems, like Windows has been doing since 2001.  The iPhone OS’s amazing multi-touch interface and low power consumption is a natural fit for the iPad.  But the real gem here is including the iPhone OS App Store and ensuring that all iPhone and iPod Touch apps work on the iPad.

The App Store combined with the iPad’s form factor and capabilities make it a sort of tablet chameleon.  Combine a driving simulator with a 10 inch screen and an accelerometer and you have a killer car racing game.  Combine the WiFi, 10 inch touchscreen and word processing software and you have the perfect intake form at a doctor’s office.  The iPad wasn’t designed to replace your current laptop or desktop.  The iPad was designed to replace the way we do a great many things.  Playing games with our families, checking email, reading books, or watching movies on a plane.  It’s verbs, not nouns that Apple was after.

I believe that we will see iPad competitors recognize the importance of including an app store in their next devices.  Google’s rumored slate device will likely include the Android Market.  HP’s recent purchase of Palm will likely result in the Palm WebOS and app store showing up on future HP tablet devices.

Thus, the iPad will be as good or as popular as the software that is created for it.  And in that regard, I think it will be quite popular.  For myself, the iPad would certainly not replace my laptop nor would my wife give up her MacBook for an iPad.  However, in a few years when our kids become school age, I can see the iPad being standard equipment for family vacations and long car trips.  How nice to be able to bring streaming TV, all of our favorite board games, and a great way to look at maps all in one device!

May 10, 2010 Posted by Keith Forsythe | Business Strategy | Leave a Comment

How to Replace the LCD Display on a Roland Juno-G

So on this very snowy weekend in northern Virginia, I had enough time to try out replacing the defecitve LCD display on my Roland Juno-G.  This has been a common problem with this keyboard, especially with the the first units produced.  I purchased my Juno-G used from Guitar Center for $650 in December of 2008.  About 6 monthhs later, the display started to act strangley.  At first, the display was distorting.  Eventually, half to 3/4 of the screen went blank.

After reading several blog posts about other folks having this issue, I called Roland Support.  They informed me I could buy the part for $135 or go to an authorized repair center.  Maybe it was my recent experience with embedded device software engineering, but I had the urge to try the repair myself for the first time.  So I ordered the part, and it was delivered a week later.

So here are my instructions on replacing the LCD.  It took me about 2 hours, but I was really going slow :

1. Get about a dozen small bowls or container to keep the screws organized.  Get little strips of paper.  When you remove the screws from a section, write a label of what the section is, put the label in the container, and put the screws in the container.  There are close to 50 screws, and you don’t want to confuse them.
2. Grab a philips screw driver, small wire cutters, and small needle nose plyers.
3. Remove the data wheel to the right of screen.  Keep pulling firmly and it will eventually slide off.
4. Flip the keyboard over and begin removing the screws to separate the case.  You need to remove every single screw you see on the bottom of the keyboard.
5. Separate the case.
   

   Inside the Roland Juno-G

6. Unscrew the mounting screws from the circuit board containing the jacks and disconnect any ribbon connectors that are in your way.  You should be able to flip the board back and over and out of the way.
   

   Getting Juno-G jack circuit board out of the way

7. Next, unscrew the mounting screws from the motherboard on your far right.  You may need to snip a couple wire ties to make room to move the motherboard up enough to get at the center board.  Disconnect any ribbon connectors that get in your way.
   

   Juno-G Mother Board disconnected to free up the center board

8. The LCD display is on the other side of the center circuit board, so you are almost there.  Unscrew mounting screws and disconnect any ribbon connectors.  There are a few screws hidden under black pieces of tape.  You also may need to cut some the the clear plastic sheets that back the circuit board.
9. Flip the center board over and unscrew the LCD display.
   

   Juno-G Center board flipped over to reveal LCD display

10. Screw in the new display, and work backwards mounting the circuit boards back into place and reconnecting the ribbon connectors.
11. Put the case back together and put the data knob back on.
12. Plug in, switch on, and get back to enjoying your Roland Juno-G.

I’ve got a little confidence now, so I suspect I’ll be trying more of my own repairs in the future.

June 29 2010 Update….  I started having problems, AGAIN WITH THE DISPLAY.  The screen was not redrawing from page to page.  I called Roland Support and they had me ship the keyboard back to them.  They fixed the issue for free and shipped it back.  Cost me $70 to pack and ship from Virginia.  According to the shipping notes, they removed an unneeded board that is related to the LCD.  This seems odd.  I think they meant to say replaced.  Either way, things are working well again.  I started working on a punk rock cover of I Wanna Be Adored by The Stone Roses.  I missed my keyboard.

December 21, 2009 Posted by Keith Forsythe | Recreation | 53 Comments

Tips for Effective User Story Gathering Meetings

The typical approach in gathering requirements for an agile managed software or hardware development project is to first conduct user role modeling meetings.  A collection of developers, product people, marketing, subject matter experts meet to brainstorm all the different user roles that will interact with the system being created. 

After gathering the list, the next step is to generate a list of user stories.  One very effective way to do this is to conduct user story gathering sessions, where the group of project members and customers iterate through each user role, brainstorming all the ways the user will interact with the system.  Often, a paper prototype outlining a rough workflow is used or created during the session to facilitate the conversation.

Mike Cohn has done an excellent job describing both of these activities in his books Agile Estimating and Planning and User Stories Applied.  I’d like to suggest a few tips that have helped make these activities even more useful in generating requirements documentation

• Prepare paper prototypes before the user story gathering meetings with the obvious stories.  This will give your meeting attendees a good starting point, serve as examples of how to do a prototype, and speed things along. 
• Use Visio or Powerpoint to build your paper prototypes instead of a whiteboard or notecards.  Having an electronic copy I can pass around to distributed members of the team is very useful.  Plus I find that I am often flipping between multiple workflows during user story gathering meetings, which is hard to do if you drew everything on a whiteboard that might be already erased. 
• Start with the user role with the largest role in the system and work your way through each user role in descending order of system interaction.  This will cause you to write up a lot of different paper prototype workflows.  As you get further down the list of roles, you will find that the paper prototypes you need to facilitate the discussion are mostly already built.  (Yet another reason to keep your workflows in an electronic format)
• Don’t forget to gather stories for the hidden users roles!  I find it extremely useful to work through the system as the role of developer, designer, project manager, qa manager, product owner, suppler, etc.  Example stories you could generate as a project manager for a new web application project could be:
  • As a project manager I want to conduct a PCI compliance gap analysis for my planed network architecture to make it easier to attain compliance later.
  • As a developer, I want to setup a continuous integration server for the project so that our unit tests are executed regularly.

I hope you find these suggestions useful.

September 11, 2009 Posted by Keith Forsythe | Project Management, Uncategorized | agile, agile project management, agile time saver | Leave a Comment

Don’t work harder. Work different.

We’ve all been told by our bosses that we need to “work harder”.  The project is behind, the product is selling as predicted, to many bugs, etc…  and the solution presented by management is “work harder”.  Or if you are a manager, you may be fond of using this as direction to your team.  I’ve come to be very weary of the “work harder” solution.  Here’s why:

• Manager’s often use the “work harder” solution as a fallback when they cannot or will not figure out what the real problem is.  It is simply easier for a manager to declare “work harder” rather than make difficult decsions on prioritizing work or changing what people are working on. 
• Manager’s may use the “work harder” speach as motivation, but this has diminishing returns.  You can only use this solution so many times until your team is skeptic that the problem isn’t in execution, but in strategy.  And really, can’t a manager come up with something more original than “we gotta work harder!”?
• I prefer to reserve the “work harder” solution for emergencies only.  Reserving this solution for times when more execution is the only solution to an immediate emergency helps ensures that the emergency is handled.

In summary, I believe there are times when “working harder” is an acceptable solution to a problem.  But managers, please be very frugal in how you use this tool.  Be sure that the problem will be solved with improved execution, and investigate the more likely solution that the planning or strategy is the real culprit.

August 28, 2009 Posted by Keith Forsythe | management | Leave a Comment

Send and Receive SMS Text Messages Using a GSM GPRS Wireless Modem

If you need the ability to send SMS text messages from your website or Internet connected software, you will quickly discover several options such as using the free wireless carrier email to SMS gateways (ex. 5555551212@vtext.com), third party SMS gateways (ex. CellTrust HTTP API), direct connection to SMSC’s (after days of research and phone calls to AT&T, we couldn’t figure out how to do this), and GSM GPRS wireless modems.

The free SMS gateways are great if you know both the phone number and mobile carrier, and you don’t require delivery to or from a short code.  If you don’t know the mobile carrier you can look it up through any number of free or paid third party API’s (CellTrust offers one).  If you need to use a short code, then third party SMS gateways are your only choice. But at large volumes, the cost can really add up. GSM GPRS modems are the best choice if you need to send high volume, don’t know the carrier, and don’t need a short code. However, programming and scaling GPRS modems can be a challenge because you have to use AT commands that aren’t always implemented in a standard format and you also have to do deal with serial port communication (For a great tutorial, checkout: www.developershome.com/sms/). If only somebody made a GSM GPRS modem attached to a web server…. Somebody did, and I have to give it a very positive review.

We stumbled upon the SMSFinder while on a tech support call with Multi-Tech. We had purchased a GSM GPRS modem and we intended on programming it using AT commands to send and receive text messages. We found out from our very helpful tech support person (Multi-Tech support is excellent btw), that if we just wanted to send text messages, the SMSFinder is for us. The SMSFinder is a GPRS Wireless Modem, with an ethernet port, wrapped with a web server. Just slide in an active SIM card, plug it in, and your ready to go. It exposes a simple HTTP API for sending messages, along with a basic GUI web admin portal. The device handles queuing the requests if it gets behind. We have put multiple modems behind a load balancer, assigned it a VIP, and instantly have the ability to scale. The downside to this approach is that your messages will come from one or more phone numbers, not short codes. But if you need to inexpensively send a large volume of messages very cheaply (10,000 messages via a third party api will cost you about $500), and you don’t require a short code, then you should consider the SMSFinder.

Here’s a short summary of options for sending SMS test messages.

And one more thing, Multi-Tech is releasing a 4 and 8 port version in Summer of 2009.

May 31, 2009 Posted by Keith Forsythe | SMS | 1 Comment

Don’t Mix Brainstorming and Estimating Effort in the same Design Meeting

Recently, Derrek Long, my system architect, asked me to read a few pages from the book I.M. Wright’s Hard Code by Eric Brechner.  He had observed issues our company was having with mixing brainstorming and scope cutting in the same meeting.  Brechner describes over a few page in Chapter 5 how to avoid getting FOCKED, or “Failing to Orchestrate Collective Knowledge Effictively for Design”.   Essentially, Brechnar preaches to have very specific goals for a meeting, and to avoid at all costs mixing goals, especially when the goals are completely opposite to each other. 

After reading Brechner, and thinking about it for the last few weeks, I’ve expanded this idea out a bit further as to why mixing brainstorming and estimating effort during initial design meetings between the business stakeholders and development is a bad idea.

1. Discussing effort for each idea discourages creativity when brainstorming.  People will be less likely to offer “out of the box” or “half baked ideas” that need to be flushed out if they are afraid they will be scolded for coming up with something “too hard”. 
2. Dev often will give a big estimate when they don’t like an idea.  So waiting to estimate the idea at a later time demonstrates that dev still put in the due dillagence to consider the idea and the estimate isn’t just based on dev not immediately liking it.
3. Initial estimates given 10 seconds after hearing an idea in a brainstorming meeting will be less accurate.  Dev needs time to absorb the idea, think it through, and then offer an estimate of effort.  Even spending 5 or 10 minutes considering an idea results in the developer spending 100 times more time considering the idea and will result in a more accurate and reliable estimate. 
4. Other ideas presented later in the meeting might add further clarity to earlier ideas or might prevent the idea from needing estimation altogether. 

I would love to hear from other people their experience with keeping brainstorming and estimating separate.  If you have techniques you employ to do this, let us know!

May 1, 2009 Posted by Keith Forsythe | Development Management, Project Management | Leave a Comment

Save Time by Checking Email on Your BlackBerry Instead of Your Computer

I’ve noticed that I can get through my email in half the time if I use my BlackBerry rather than my computer. Email using my computer takes about 3 to 4 hours of my day, so using my BlackBerry is a huge time saver.

So why is it faster to do email on my BlackBerry than a computer?

For one, firing up my Windows Vista laptop sure ain’t quick. Even coming out of sleep mode, this can take a few minutes. My BlackBerry is always on, ready to go as fast as I can reach in my pocket.

Two, I’ve got about 1.5 GB of email, and I receive about 150 emails a day, so opening Outlook can take a while. Other actions, like deleting messages, switching to the next message, etc… also take a second or two and seem to get worse as my mailbox grows over time (I know I can archive things, but I tend to use past mails every so often). Flipping to email on my BlackBerry takes about a second. Deleting multiple messages is fast and easy to do by selecting multiple messages. Opening messages is instant. Even viewing attachments is quick on my Verizon BlackBerry Curve.

Thirdly, typing on a BlackBerry is almost as fast as a computer for me. But because its a BlackBerry, I somehow feel it’s ok to much more brief in my responses… like its a text message. I make use of common acronyms like TY or IMHO (or WTF) that I wouldn’t normally do in an email I’d type out from my computer. Maybe it’s just me, but I feel like its ok to use text speak in email from a BlackBerry but not from a email created on a computer. Saves alot of typing and time!

If a particular email message requires extra attention, or a very long response, I will mark the message as not opened and take care of it from my computer later.

So maybe this approach can work for you? If you have a BlackBerry, or any smart phone with a real physical keyboard (I don’t think a touch screen keyboard will be fast enough), consider using this as your primary email device.

March 28, 2009 Posted by Keith Forsythe | Uncategorized | BlackBerry, checking email, efficient, email, email best practices, save time, tips | Leave a Comment

« Previous Entries    

About

Thanks for visiting!  My name is Keith Forsythe and this is my blog about product development, product marketing, mobile devices and general business practices at an Internet Startup.

I am currently co-founder and Director of Product Development at RideCharge, Inc (Taxi Magic), a startup mobile and web taxi booking service.  Prior to RideCharge, I was an IT project manager as CVS/Caremark, and a software engineer at Baxter Healthcare.  I have a MS in E-Commerce Technolgy from DePaul University and a BS in Chemistry from the University of Illinois at Champaign Urbana.

• Categories

  • Business Strategy
  • Development Management
  • management
  • Marketing
  • Product Management
  • Project Management
  • Recreation
  • SMS
  • Uncategorized

• Archives

  • December 2010
  • August 2010
  • May 2010
  • December 2009
  • September 2009
  • August 2009
  • May 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008

• Feeds

  • Entries (RSS)
  • Comments (RSS)

• Blogroll

  • Above the Crowd
  • Andrew Chen’s Blog
  • Hack Sushi
  • Sean O’Malley’s Blog
  • Simplytry Dev Blog
  • Startup-Marketing.com