Understanding Web Development Resources

March 10, 2010

You have a great new idea.  It’s a Web site or a product or some technology that can become the foundation of other solutions.  What kind of team do you need?

Outsourcing removed the interview process from setting up your team.  For many start-ups, that change normalized the resource pool as many outsource providers simply assign a team to the project.  In reality, there is a big difference between a developer who knows how to build an online Web store versus someone who can make Twitter scale or conceive of Ruby on Rails.

Let us help explain the difference between these types of resources.  First, we need a pyramid!

Companies have different levels or terms for engineers.  Here’s how I define them:

Web developer — A Web developer is good at creating sophisticated Web sites that have limited back end functionality.  His tools of choice are HTML/CSS/Javascript or Flash.  He loves walks in the park and open source CMS’s.

Software engineer — Software engineers are comfortable building more complex functionality that includes objects and business logic.  Ruby on Rails is the language Du jour for the hip and trendy alternative scene.  PHP is the blue collar worker’s hammer.  Java is the choice of old school guys who think the country has gone to the dogs.

Software developer — We don’t use objects, we are objects.  Pearl Jam is the new Grateful Dead.  If you haven’t modified a Unix kernal or developed in native C, then you are a poser!

Software architect — The architect is smarter than most of us, and you should avoid the ones who know it.  He spends his weekends looking for quasars or trying to eliminate a contradictory systemic anomaly from what is otherwise a harmony of mathematical precision.

For most of your projects, your team will likely be a collection of software engineers and web developers.  The more complex the project, the more you will need developers or possibly a seasoned architect.  The pay scale rises with qualifications obviously so we tend to look for one or two smart senior guys and then back fill with a cost effective pool of highly motivated individuals.

We took a look at our some of our projects from last year and charted them against the pyramid.

Understanding the type of project you have will help when selecting your team*:

Website or application – A Web site project in this case is a project that is mostly user interface with either little or standard back end functionality.  The site might have e-commerce, user sign-ups and dynamic content.  Back end functionality is supported by existing open source tools or by integration with other sites.

Product – Product development generally includes sophisticated back end functionality along with more complex interfaces.  The project often is based on some “secret sauce” that is protected IP, under a patent or otherwise considered a market differentiator.

Framework or foundation – Framework or foundation projects are projects that create technology upon which other solutions are created.

We’re product developers and like to produce complete solutions for our clients.  Framework projects are fun and challenging though there are simply less of them.  Of course, we love a good Web site project as well.  It’s just that they tend to be shorter and require more customization work than software engineering.

Next time you start up your a new project, it might help to classify the effort within this pyramid.  You can use the classification to define what type of engineers you should be asking for.

* A complete discussion of resources should include specialists and other disciplines including designer, tester, project manager and so forth.  I am working on a follow up post to help that aspect of your resource planning.

Leave a Comment » | Development philosophy | Tagged: , , , , , , , | Permalink
Posted by bbenedict

Design Lessons Learned Example

February 27, 2010

One of our top posts so far this year is our post about design lessons learned in 2009.  We provided suggestions that might help you successfully complete your design project along with examples of our work.  The key tips we presented were as follows:

  1. Start from a creative brief
  2. Use multiple visuals
  3. Plan to start over at least once

At the end of the post, we showed a hint of a work in progress.  We now can say the mock-ups were from our new product hinventory.com.  You can learn more about our launch in the hinventory.com blog.  We thought we’d go through the design steps in more detail to help illustrate the tips presented above.

hinventory.com started from a real need in my own life.  I had previously gone through the painful process of cataloging everything I owned in excruciating detail. The process was time-consuming and I soon gave up maintaining the list as do most people.  Late last year, I was thinking about the simplest way to get this done when it hit me that all I really wanted was take photos and mark the significant items in the photo.

First, we wrote some specs and did a creative brief to better define the product.  I can honestly say I am addicted to the creative brief at this point.  There’s nothing like collecting your thoughts to focus what you are trying to do.  I may even start doing them for house projects or working in the garden!  The graphic below is our proof of concept piece that went with the creative brief to help define the product.

Once we understood the direction, we set about developing the product.  The first version was intended to be a working prototype or beta that we hoped to get some users testing.  The interface is presented below.  Feedback on the product confirmed the market opportunity. But…

… the interface faced some challenges.  When developing functionality you sometimes make design compromises in the name of productivity you later regret.  This interface looks like it belongs on the TV show Romper Room for those of you who remember that.  The logo and banner are straight from a 3 year old’s bedroom.  It doesn’t work, I know.

Lesson learned.  Start over.  Get some fresh eyes.  Maybe hire a graphic artist.  We did.  We used one of our favorite artists in Costa Rica and she didn’t disappoint us.

The above interface is the one we selected over the examples in our lessons learned post.  The interface is clean, intuitive and aesthetically pleasing.  Putting the content inside boxes though can lead to problems later on.  If I had to list a fourth lesson learned from last year, it would be to design for functional expansion and page growth.  We did another round of mock-ups using less restrictions on the actual page content.

We selected number 3 as the final design and then moved on to the logo.  Here are the samples we created before sending a few select ideas to our artist.  Using multiple visuals proved key for illustrating to our artist what we liked and what we did not.

We ran into one final design issue during the course of development.   Take a look at our iPhone application mock-up below and see if you notice the issue.  We created the mock-up ourselves.  We’re launching the app next month so keep your eyes and ears open.

Do you see the issue?  The problem was the markers.  They are barely visible.  The same issue existed in the Web version, but we hadn’t noticed it as much until we saw the photos on the iPhone.  Marking items is essential to both applications.  We moved to a red marker inspired by what you see on a map.  The final interface markers and all is displayed on our product page.

You can see the product yourself by signing up on hinventory.com and using the product.  We hope you do.

Cheers.

Leave a Comment » | Development philosophy | Tagged: , , | Permalink
Posted by bbenedict

Design Tips from Lessons Learned in 2009

December 9, 2009

We had some fun and rewarding design projects this year.  Open Mountain has a new logo and Web site, and we executed a new ad campaign.  We also designed sites for our clients and were involved in many creative projects throughout the year.  I think it’s time for a little retrospective.  Before I take you through some of work, I thought I would provide some lessons learned from the year.  Assuming you are following a healthy design process, here are some tips to help you achieve success with your creative endeavors:

1) Start from a creative brief

A creative brief synthesizes the desired results or impacts of your project.  I recommend a single page brief that has 3-5 words that describe the emotion you wish to evoke, a sentence describing the impression you are trying to create or message you are trying to communicate, and then 5-10 bullet points listing everything that should also be considered.  We skipped this step a couple of times only to find out later that our lack of alignment was driving the design in different directions.  Resist the temptation to dive right in creating images before you collect your thoughts.

2) Use multiple visuals where ever you can

This one seems obvious.  Of course you are going to create visuals of your design.  We recommend using more than one as much as possible and use existing work for inspiration.  We started our logo project by creating a page of logos we liked from other sites and a page of logos we didn’t like.  Our Web site went through many prototypes before we started working in HTML.  Our design partners deliver 3 to 5 design choices per deliverable and that gives us plenty to discuss as we strive for something creative, intuitive and unique.

3) Plan to reset or start over at least once

All our best design projects hit the inevitable “we’re stuck” moment at some point in the project.  The current trajectory has run its course.  Where do we go from here?  Starting over allows you to dump the bad parts of everything you did while retaining the best of your brainstorming and thinking.  For our logo project, we liked the two-tone nature of the images but couldn’t converge on colors.  We realized that using brown to represent the strength of mountains was putting a damper on our brand.  Hills in California offer other choices such as green for spring or gold in fall.  The logo design direction was good but we dumped our color palette and started over.  You’ll see that progression below.  We recommend you embrace the set back as a healthy part of a creative process.  Try not to resist just because you are under deadline.  It may take you longer to make a bad design better than create a new design that works.

Here now is a trip down some of the design projects from our year and how we came to learn these valuable lessons.

Open Mountain Gets a New Brand

Our first project of the year was a new logo and Web site.  As I mentioned above, we did the logo ourselves starting from a creative brief.  Open has strong connotations for approachable and transparent but also open in the open source sense implying community and knowledge.  Mountains are strong, substantial and impressive.  The image below shows our progression from earthy colors toward what we have today.  This project benefited from all 3 tips listed above.  We used a brief.  We created mountains of visuals to consider different options, pun fully intended of course.  Our earth tones palette was replaced by something green, open and fresh.

We tackled the Web site next.  Below is our first attempt starting from our existing creative brief.  Do you see any major issues with this perhaps after reading our previous post about design?  You see a guy in a kayak against a mountain range exactly where the eye looks first on the page.  How informative is that?  We had hoped that the serenity of the lake we create a peacefulness when perusing the site.  One reviewer thought we were a travel Web site.  Furthermore, most people didn’t even look at the content at the bottom because it appears secondary to the overall page.  Time to start again.

Our new design started by utilizing our own advice and putting meaningful content in key positions.  We decide to use Flash animation to make the experience more engaging.  Below is our first shot at the flash panels for the animation.

Next we played with color and attributes to encourage the users toward different sections of a page.

In the end, we feel we created a site that is informative and engaging, and delivers the right message about our company.  Take a look and tell us what you think.

We Have Ads Now!

Our next project was creating advertisements for our business.  We procured several 250 by 250 spots on various Web sites through pay or partnership.  Due to timing constraints, we were forced to create something quick and dirty to meet a deadline.  This is what you get when you don’t follow good process or utilize any of the design tips we mentioned above.

Is there anything in this ad that is the least bit engaging?  What incentive do you have to explore this company?  What service do they really offer?  Right, you get the point.

We reset the entire project and thought hard about what were trying to do.  An expert gave us some advice on how to think beyond our current approach.  She talked to us about advertising and about how you create something like a “Got milk” or “Just do it”.

We have said from the beginning that we wanted to be different from what customers have come to expect with outsourcing.  We strive to overcome the separation between organizations and instead work to provide insight into what is really happening with the remote development team.  Working with Open Mountain should not feel like typical outsourcing.  It should feel like your own team.

Outsourcing never felt like this!

That was it.  We knew right away this was our “Got milk”.  When you outsource with Open Mountain, it should not feel like any previous experience you might have had.  Below is our first concept piece with the new approach.

Happy smiling people.  People actually enjoying outsourcing.  Exuberance.  Feedback from our experts confirmed this had appeal and communicated the right message.  We created 4 ads.  Here are the two favorites and we also used the one in the upper left corner above.

If you outsource with us, you’ll be as happy as a kid sledding or a crazy guy eating a huge lollipop.

These ads still crack me up.  They are quirky and unique and communicate our core message.  Of course, we rejected some ads as well.  Here are the two most controversial.

Outsourcing should feel like you are about to eat a huge hamburger, right?  People said he looked constipated or nervous.

Reaction to the woman eating cake was truly mixed across woman and men.  At the time we rejected the ad, one woman reviewer was saying this degrades our business while another said this would get the attention of our target audience.  Let’s just say that the ad did not fit well with our corporate values.

Clients Restart Projects Too

Design tips were learned working with clients as well.  Our client ThriveOn.com launched their site based on the design below.  As we added features to the solution, we soon realized that the design was creating some challenges.  This design is more consistent with a Web portal such as iGoogle or my.yahoo.com, and didn’t fit well with upcoming product changes.

The client went back to the drawing board and created a design more suited to the long-term growth plans of the product.  Below is an interim step from when we experimented with different color schemes.

The final site is presented below.  You can read more about our work with ThriveOn in our case study on the OpenMountain.com.

A Look at a Work in Progress

The year isn’t over yet and we’re designing new products all the time.  We strive to follow good process and utilize the tips mentioned at the start of this post.  Here now are two final mock-ups from a product we are working on.  The project is in stealth mode and some content is redacted.  Overall, the design process has gone very well.  Our favorite approach is not displayed below however.  You’ll have to wait until launch to see where we ended up.

3 Comments | Development philosophy | Tagged: , , , , , , | Permalink
Posted by bbenedict

Developing on a Platform Creates a Dependency

November 2, 2009

Companies are finding real benefit from starting on a platform that provides functionality and existing customers.  More and more developers are launching products on the iPhone, facebook and SalesForce.  We definitely encourage our customers to use existing technologies and services to expedite time-to-market.

A few months back, we were proposing to build a facebook application using some other technologies as well.  In our proposals, we like to think ahead to point out issues that could arise and we stated that any changes to these technologies could impact the schedule.  At this point, the customer emailed me an interesting question.

How do we mitigate the risk if facebook or the other technologies change?

Our customer was asking a pretty good question.  If facebook changes their API or markup language, we may have to re-factor significant amounts of code.  Don’t think this could happen?  It already did.  Here’s how it impacted some developers.

At first I was tempted to say that is the nature of the beast.  If you are building a house and it starts to rain, construction will be impacted.  Materials will get wet.  You might have a major disaster if you just poured the foundation and the cement hasn’t cured.  We can’t stop the rain.

I then realized this is a profound question and that I needed to give it some thought.  We develop for start-ups all the time and a significant delay from outside influences could prove disastrous.  I started thinking through the possibilities.

First, we need to consider if companies we are depending on actually appreciate this risk.  How often does the facebook API change?  How does SalesForce improve their platform without breaking existing applications?  It’s reasonable to conclude that if Apple, facebook and SalesForce care about their business they wouldn’t adversely impact people making a living off their technology.

I did a little investigation to see how well these companies keep their developers informed of changes.  Everything I discovered was as of the writing of this post and may have changed before publishing.  I certainly welcome anyone from facebook, Apple or SalesForce to comment on this post and provide information I may have missed.

facebook clearly embraces developers as a community.  Their WIKI is comprehensive and includes a link to view the latest changes to the platform.  A proactive developer could sense changes were in the air for sure.  I was hoping to find a way to subscribe to emailed changes.  I’ll keep looking for that.

Apple’s developer site feels very polished.  They clearly focus on information presentment making it easy to find documentation.  That said, the site seemed to offer less insight into what is happening with the platform.  By way of contrast, WIKI community sites are easy to edit and therefore updated more frequently, but often contain posts that are not completely accurate or have become out of date.  A good editor solves this problem of course.

SalesForce.com is definitely going the community route.  The developer site includes documentation, news, events, updates and discussions.  An active developer can stay abreast of changes for the most part.  After looking at the site, you can see that the company is making a good effort to keep the developer community informed.

Back to the question, how can we mitigate the risks of a key technology or platform changing mid-cycle?

Here are some the techniques we recommend for staying informed and managing the risk from developing on existing technologies and platforms:

1) Subscribe to all change lists – The best way to find out if an API or technology is changing is to have the company tell you in advance.  Trust me, you don’t want to find out from users your site is broken.

2) Avoid developing functionality that has a shelf life – Some times, it is clear an API or functionality may have limited long-term viability.  Certainly privacy and security issues won’t stand over time on any site with significant usage.  Developers love to exploit a loophole or over reaching function.  Your business might be doomed if this loophole is core to your success and it gets closed.

3) Plan for scenarios in the business – The corollary to point 2 is plan for the unfortunate or unexpected.  You should certainly utilize any advantage you reasonably uncover.  Just don’t bet the farm on anything that may pose a long-term issue for the platform without a backup plan.  Spend time thinking about how your business would need to adapt.

4) Create a business that is truly platform independent – Try to see each technology used by your product as a component instead of a necessity.  facebook could be swapped out for MySpace or Twitter for example.  If you use an open source product for your shopping cart or CMS, consider having a backup choice in case you find a bug that can’t be fixed.  Ask your architect to present an alternative technology stack that changes all third-party technologies just to prove it can be done.

Experienced teams use existing platforms and technologies to enhance products, speed up development and create forward-looking solutions.  You should too!  Just don’t get caught depending on something that would hobble your business if it changed.  Have a plan to get back up if the rug is pulled out from underneath you.

Leave a Comment » | Development philosophy | Tagged: , , , | Permalink
Posted by bbenedict

Success And Failure Contribute To The Experience It Takes To Succeed

October 23, 2009

Experience matters when it comes to advisers, vendors and employees.  A recent post by Eric Ries on gigaom.com challenged the conventional wisdom that people who worked at previously successful start-ups hands down have the solid experience you need in your employees and advisers. If you had a good run at a Google or an Amazon or an eBay you are without a doubt the person a start-up should bring on board. The problem is that founders and companies get so caught up in the name that they don’t look behind the curtain.  How do you choose between employee 100 at eBay versus someone who did time at HP and Apple but the one start-up they worked at hit the deadpool after two years?

We can’t discount the impact of having big name success in your company pedigree.  We see it all the time at Open Mountain as we work with start-ups and investors.  We had one prospect use the pedigree of advisers to a consultant he briefly hired in his pitch.  Sort of like his company hired the guy who dates the sister of the guy who walks Steve Job’s dog if you know what I mean.  Another case the person with the pedigree had joined one of the Internet giants after the battle had been won and during the time the business plateaued.   In both cases, we observed first hand that the viewing audience accepted the pedigree on face value.

Remember Webvan?  Webvan was one of the high flying companies of the first Internet boom that spent obscene billions on grocery delivery infrastructure only to go belly up at first sign of trouble.  Who would ever hire a person with that on their resume?  If you were to hire that person, the first thing he or she would tell you is don’t over build and make sure you have ways to reduce  costs during economic down turn.  That seems like really valuable advice to me.  If you hired someone who had been at Amazon, he or she might tell you to build like crazy and run up huge debt because it’s a land grab and we’re playing for keeps.  This is exactly what Amazon did and it certainly worked for them.  Which approach would be better for a start-up in today’s market?

Let’s dispel a few myths of our own.  With the exception of the leadership at the top, the job done by most people at say etoys, Webvan or uBid was not much different than the same people at eBay, Yahoo or Amazon.   There were plenty of good people at the first three companies just as surely as there were bad people at the success stories.  We tend to assume that everyone who worked at a runaway success was a home run hitter.  Yet we all know many great lessons are learned by failure.  Your experts need to know how to succeed for sure, but they also need to know how to avoid failure.

Here are 3 tips on how to get the best people and avoid the glossy eyed acceptance from talking to someone who worked at a runaway success story:

1) Don’t hire anyone who doesn’t have at least one significant failure they are willing to talk about.  The failure means they have learned.  The “talk about” part means they are being as honest as reasonably possible in the vetting process.  Here’s an interview tip.  After hearing about the failure, ask them for the name of someone else who also went through the failure with them that they still like. Then ask the candidate to describe their impressions of the themselves from perspective of the other person.  In an excellent interviewing class I had a while back, the teacher explained that the possibility you may actually know or contact the third person increases the chance your candidate will give you an honest answer.

2) Go rent season 4 of the TV show House.  In season 4, House is forced to build a a new team.  The process is entertaining but also valuable if you are interested in characteristics of a great team.  You should probably watch some of the earlier seasons so you understand the show.  House understands that to build the best team, you have to hire people who compliment your skills, who are not afraid of failure and who are willing to look for the best solution no matter the cost or process.  Most importantly, don’t just hire people who think like you if you want to benefit from the unique experiences of individuals with different points of view.

3) Hire people with great pedigrees in their past too!  Yes, I know the focus of this post was about how not to let pedigree cloud your thinking.  Simply put, experience matters and working with people who have done great work and achieved great success makes a difference.  My point is that you need to look beneath the surface and make sure the experience is real.  That is also the point of Eric Ries in his post.  He provides all the ways people with pedigree experience may not have earned that experience or learned from that experience.  I would suggest you review the post before the interview and do your best to determine if the person in front of you fits one of his profiles.

Any day of the week, I’ll take the person with substantial experience that includes brand names and failures over the person with only one great success story in their past.  I like to see some start-up experience, but I like that most when it is balanced with large company experience too.  After all, I’m not saving people’s lives like my good friend Dr. House, but I do want to have a team that can save a company in need and to do that they must know what to do when things don’t go as planned.

Leave a Comment » | Development philosophy | Tagged: , , , , , | Permalink
Posted by bbenedict

Virtual Corporations are Accepted Practice in the New Economy

September 8, 2009

We were meeting with a new client this week discussing how we cost effectively deliver products and technology.  Low overhead is a key part of our strategy along with near-shore resources for development.  We’re a virtual corporation and that means our work force is distributed.  Office space is limited, and we use other strategies to achieve collaboration and a sense of company.  We explain our strategy in our post on being a green company.

We did not take any initial investment to start the company and that mandates we watch our expenses fastidiously.  In an upcoming post reviewing our predictions for 2009, we think our prediction about back-to-basics business principals has proven true in the new economy. Young companies that thrive in 2009 are often profit drive and bottom line focused.  Open Mountain is no different.

That said, there is a risk staying virtual.  Will customers be more impressed if they walk into a well decorated office with large conference rooms and amazing views of the San Francisco bay?  Or will they understand if we meet using rented conference room space that is nice but not part of our headquarters?  Does this really matter?

The good news is more and more of our customers understand the virtual concept.  Customers are in fact virtual themselves including the new customer we met with and many of our existing customers.  We no longer have to explain that working remote and having a work-space only head quarters does not hinder our ability to deliver.

A virtual company structure is becoming a sign of forward thinking and smart money management.  Companies grow more cost effectively and avoid the risk of expensive leases or even worse having to move.  This approach beckons back to the original Silicon Valley garage start-up and the lore that turned the garage of Bill Hewlett and Dave Packard into a historic land mark.   Spend your money where it matters and preserve your cash until you have money coming in.  As developers, we like working for smart companies as that increases the chance the fruits of our labor will live beyond the challenging launch phase.

I’ve spoken enough in the past about remove collaboration strategies like this post.  I thought I would add some other ideas to help create a sense of company for people who primarily work together yet separate.

Meet periodically face-to-face

We try to meet once a week in a common location.  When we do, we often include lunch, dinner or social activities.  If our near-shore developers come to town, we do our project work in-person as much as possible even if it is not necessary.

Become friends on facebook

Sharing photos, links and comments on facebook is like putting a picture or comic outside your cubicle and having people stop by.  My business partner posts his runs and other actives online and in my mind I hear him telling me I need to exercise.  Sharing life experiences contributes to the sense of company and community.

Use video conferencing

I’ve talked about the benefits of using video in collaboration often enough.  Next time you have a remote Skype session, fire up that Web cam that probably came free with your laptop.

Send weekly status reports

A great way to keep everyone connected is to send and read status reports from everyone in the company.  Reading status reports takes the place of weekly or monthly company meetings and creates a more effective way for employees to feel part of a larger whole.

As you start your company or plan your growth, we highly recommend you consider a virtual strategy.  The cost benefit is significant.  Online tools, status reports and other techniques help you ensure your work force is connected and engaged even if you can not see for yourself.  Interestingly, we are seeing the same evolution with online computing resources.  Companies are saving the cost of building expensive hosting infrastructure by deploying applications on virtual resources in the cloud.  While you are at it, how about considering a virtual development team too!

1 Comment | Development philosophy, Industry happenings | Tagged: , , , , | Permalink
Posted by bbenedict

Understanding Engineering Management Through Shipping Metaphors

May 31, 2009

We completed our first release with our new client ExpertCEO and were pleased to read the blog post of CEO Ken Ross about the update and the role our team played.   Open Mountain experts work as engineering management to oversee development and guide near shore teams to successful releases.  Ironically, we sometimes find ourselves explaining engineering management to companies even when their own experiences tell them software teams need leadership.  I’ve joked that you don’t know what engineering management is, but you know it when you have a good one.

Ken described our leadership as “oversight services to ensure that all of the technical, architectural and operational aspects are synchronized.”  Mario Chaves, CEO of our development partner Avantica, described Open Mountain another way, “[Open Mountain] experts improve communication, refine requirements and ensure all parties work seamlessly as one integrated team.”  These explanations certainly help to clarify our duties.  Perhaps a metaphor might help explain things better?

Developing software is like shipping cargo

Developing software is like loading a ship with cargo and navigating calm or rough seas to get to a final destination on time.  The captain puts together his best crew hopefully using seamen he has worked with before.   The navigator is the architect planning the journey.  The helmsman is the lead engineer and has the best sense for how the ship is handling.  The crew maintains the engines, cargo and supplies.  The captain, of course, is in charge of the ship and crew.  Let me provide some examples of how this metaphor is useful.

I took over a project in trouble at a previous job and described the project like this.  The ship was on a trip from Hawaii to San Francisco and right now they’re half way to Alaska.  We need to make a hard right turn and we may lose some of the cargo and crew overboard to get there on time.  This translates to making some decisions to change the direction of the project and that may include changing the team and cutting features.

Prioritizing features is like loading cargo.  We need to be in San Francisco within 3 months and you still have cargo on the loading dock.  You need to make some decisions fast and get this ship going or we’ll have no chance to arrive on time.  Load the ship too full and the ship will travel slowly.  Let’s quickly decide what needs to be loaded and shove off.

Agile development is like using a small, fast ship.  The client need not decide all the cargo he wants right away because the ship will be back in a month to pick up the next load.  It’s easier to select some items to load on a ship returning soon than trying to decide the only cargo you can bring in one shot.  As you can see, shipping works quite well.

Engineering management is like being the captain on the ship

The job of engineering management is to act as the captain of the ship.  The captain’s first job is to get the ship underway.  He helps the client decide what cargo to bring while selecting the crew and loading supplies.  The captain reviews the plan with his navigator and helmsmen, and manages the team to get the ship to sea as quickly and efficiently as possible.

If your development leader is pushing you to decide what is in a release, that’s because he knows the decisions you make start the journey.  He still needs to navigate the boat out of the harbor and across the ocean.

A good captain watches the early part of the journey intensely to verify his decisions.  He makes sure everyone knows their job, that the course is clear and the weather is known.  Making major course corrections in the middle of the ocean is definitely more difficult.  He makes sure the cargo is tied down and the supplies are sufficient just to be sure.

The role of the crew is clear to the client.  The navigator did the navigation, the helmsmen steered, and so on.  But if you refer to my earlier comment about engineering management, the captain was in charge but the client can’t say for sure what he did unless he was on the ship or talks to the crew.

Most captains I know are fine with this.  If the cargo arrives on time, the client is happy.  A well managed crew walks off the ship content.  If a captain made good decisions early on and tracked progress with an experienced eye, then the job was well done and the cargo is on its way to the final destination.

Had enough of this metaphor yet?  How about one more time?

Weather is unpredictable

Like it or not, projects get in trouble despite the best laid plans.  You’ll find out the hard way if you have a good captain when this storm hits.  An ocean storm can loosen your cargo or create a leak in your hull.  At that moment, the captain is the only crew member not assigned to a specific task and this probably is not his first storm.

A good captain will know that the leak is the most serious.  He’ll make sure that the navigator and helmsmen have their marching orders and put his best men on the leak.  The rest of the crew will be assigned to battening down the cargo and doing other less critical tasks.

By having the knowledge and leadership from experience, and the freedom to asses and assign, the captain is in perfect position to restore order and get the ship under control until the storm clears.  Most captains will simply confirm for the client they hit the storm and apologize for the damaged cargo.  He might ask for an extra long furlough for the guys.  And that’s really how you know you have a good captain!

So you see, a good engineering manager will do his best to create a project that runs on schedule and without hitches.  He’ll work with the team to define the work and make sure the engineers understand what needs to happen.  Throughout development, the manager tracks the progress of the team validating his decisions just like the caption of a ship checking in with his navigator and crew.  If things go awry, the engineering manager is the one team member with the experience, bandwidth and responsibility to get the project under control and manage it through to completion.

Three rules for selecting a good captain

Here are a few guidelines for helping you assess if you have an experienced and reliable engineering manager:

1) Has he been to many destinations encountering different weather patterns and obstacles along the way?  Is he an experienced manager and can he describe projects that were challenging to manage to completion?

2) Does he know how to build a good crew and does he bond with them and treat them well?  What does the team say about him?  Do they respect his experience and leadership?

3) Is he familiar with the most common and reliable boats used for shipping?  Is he familiar with the latest technologies?

These guidelines should help you select the best engineering manager for your project.  If you can’t find a sea worthy captain, a good leader will work provided you pair him with an experienced navigator and helmsmen.

Whatever you do, don’t head out to see without a captain.  If the ship hits rough waters, someone is going to have to step away from the job they are doing to get the crew under control and he may not have the experience to get the ship to port with cargo and crew intact.

Here’s to calm waters and white sandy beaches!

DSCN0636

Leave a Comment » | Development philosophy | Tagged: , , | Permalink
Posted by bbenedict

Facebook Should Use Feedback Loops During Development

March 23, 2009

Many facebook users are unhappy with the new interface that launched recently.  A poll of facebook users showed 94% of users do not like the changes.   Just search for “facebook interface” on the site and you will see what people are talking about.   Finally, we can all see the benefit of online software with the possibility of immediate feedback!

How do you end up making changes to a site that so many of your users don’t like?  This question is hard to answer without more insight into the organization.  One way to reduce the chance of producing unwanted changes is to create healthy feedback loops during development.  Users love to give feedback if you provide the opportunity as we can see through the numerous responses to the new interface.

How to gather feedback

Here are some ways developers can gather feedback on their ideas and proposed changes.  I must say up front that I am not connected to facebook and have no idea if any of these processes were used:

Do usability testing – Usability testing is simple and effective.  Put your new site in a protected location online that users with permission can see.  Ask your approved users to do a series of actions on the new site.  Most importantly, ask them to speak their reactions out loud even if the reaction is negative.   You will hear and see first hand what changes you are making are good and what changes are perhaps not so good.  Here’s an online service to do usability testing that some of our clients have used.

Use focus groups – Find users who live within driving distance of corporate HQ, bring them in for pizza and project the new interface on the wall.  Start asking questions.  Take a lot of notes.  Repeat.  There is actually a methodology around focus groups, but an unstructured approach can also be very effective.

Prototype – Long before you code anything, create simple graphic mockups and email them to prominent users, bloggers (provided they are willing to hold their posts until launch), family members and employees.  Ask participants to email you their reactions along with any suggestions they might have.

Have a REAL beta! – Create a group of a thousand or so users who are willing to actively participate in a beta.  By “real” beta, I don’t mean putting out incomplete software for all users to play around on (gmail, your beta period is over!).  Let your beta users directly access the new site for a few weeks so they can get a feel for the workflows and functionality.  Provide a simple form for them to email you feedback.  Make sure you find users willing to try new features who will make the effort to email their comments to the team.

After reading about these various processes for gathering feedback, do you think that the developers at facebook might have been able to determine that users might have issues with the new interface?

If you want to avoid making similar mistakes, make sure that gathering and responding to feedback is an integral part of your development process.  Leave time in the schedule to make product changes.  One of the top reasons feedback loops fail is development teams don’t have time to address highlighted issues.

Let’s talk brass tacks

One of the top complaints about the new interface is that users are confused and often have to hunt around to find areas that should be easier to locate.  Some basic user interface elements might improve usability and decrease this confusion.  I have listed a few ideas below.  After all,  what good is pointing out issues if you are not going to offer solutions:

- Provide a consistent site wide bread crumb trail to help users see exactly where they are.   For example, how about showing something like Home > Photos > Albums > Napa Fall 2008 > Photo 2 of 18  on the page?  With a bread crumb trial , users can see exactly where they are and how to navigate back.  Some areas on facebook have a bread crumb trail and some don’t.  To be effective, this needs to be consistent and present everywhere.

- Provide site wide navigation that is always available.  Would it be so bad to have a menu bar or left side navigation or some other common control to access the entire site?

- Use labels and hints to help users understand what they are looking at.  For example, take the word “Highlights” on the home page.  How about a little helper text like popular updates from friends or something like that?  Labels with hints set the context for users and help reduce confusion.  I suggest reading Don’t Make Me Think by Steve Krug.  I had my own don’t make me think moment a few months back.

A real example – Events

Let me provide an example of what I am talking about using the Events feature.

I see more and more people putting birthdays into facebook.  Current birthdays shows up in the upper right corner of the home page.  I’ve never used the Events feature before and had thought these were just notifications.

On the current site, you have to click twice in that corner to get to Events.  That seems to be the only way to get there as Events don’t seem to belong anywhere.  I don’t see them in the menus or as links in other places.  These next changes would help users navigate Events, which would hopefully increase site usage as well as improve user satisfaction:

1) Put the label Events on the home page above the daily events.  This tells me this is an actual area of the product.  Heck, go crazy, even put small hint text like where you see birthdays or create your own events.

2) Provide general navigation to get to the Events area.  If you put them under your Profile, which may or may not be the best place, then have a sub-navigation under Profiles that lists Events and the other sub-areas that are part of Profiles.   This needs to always be available to users through the primary navigation I suggest above.

3) Show Home > Profile > Events when users go to the main Events page.

These changes reinforce Events is a feature and that it is located under Profiles.  Overall, users won’t feel as lost when they come to understand the layout of the site.

With a little bit of development process to support integrated user feedback, developers can determine the changes users want to see, which should in turn lead to a happier and more productive user base.

4 Comments | Development philosophy | Tagged: , , , , | Permalink
Posted by bbenedict

Collaboration Tips for Near Shore Development

March 11, 2009

Near shore development has a major advantage over outsourcing to locations around the globe for US companies.  The advantage is that all parties work in relatively the same time zone.  Teams collaborate more frequently because everyone works the same hours as opposed to being hindered by 24 hour communication delays.

GlobeLet me illustrate the point more clearly with a simple picture.  Look at the globe to your left.  You see North America where  Open Mountain is located and you see Latin America where our near shore partner Avantica is located in Costa Rica.  Now let me ask you, what countries are NOT visible? When it comes to real-time collaboration, countries that see the sun at the same time are at work at the same time, which means that issues can be discussed when they need to be and without delay.

In my posts about my experiences working with Avantica, I talk about collaboration a lot, but I don’t really define where it helps.  Nor do I provide any guidance on what we do based on years of near shore development experience.  Here are a few areas where we collaborate along with tips for enhancing the experience:

Product definition

The first step in the software process is to define what we’re building.  Product owners define requirements.  Interface designers provide graphics and work flows.  Everyone works together on user stories and functional specifications.  Our experience is that it helps to push the various parties to think through as much of the details as possible before we  start coding.  This ensures the engineers are working on valuable functionality and reduces the risk of re-work or of missing important aspects of a feature.

We find the best way to collaboratively manage product definition is through online document tools such as Google docs or Zoho.  Everyone references the same user stories, which is important for keeping everyone aligned.  The team avoids issues that come from developers reading an earlier version of a specification they saved on their desktop.  When we review documents in meetings, we see changes being made real-time and that validates we all have the same understanding of the decisions.

Tip: Use Google sites or some other online Wiki tool to collect information in addition to online document tools.  Some documents will come from designers using desktop tools like PhotoShop and FireWorks.  You will need a central location to store all your product documentation and an online Wiki serves as a functional central repository.  For the documents that are created online, you can embed a link to those in the Wiki.

Tip: If you are the project manager or SCRUM master, you should periodically save important information locally.  Online documents are easily changed by others and not all providers support tracking changes.

Project Management

Managers must know what each team member is working on and how long that work is taking to see how well the team is tracking to schedule or the burn down.  Tracking is harder to do when everyone is not working in the same building.  Project management software such as Rally Software or Version One enable teams to collaboratively track progress in a central location that everyone sees.  These tools support Agile processes well and enable all team members to contribute status updates in an organized fashion.  Basecamp and Zoho offer good general tools for project management as well.  Our teams find that making updates part of the process keeps everyone well informed  and allows management to see what areas need attention.

Tip: Track bugs in the same tool you use to manage projects.  In the beginning of a development cycle, features drive the work.  But at the end of a cycle, it’s all about bug management.  Using the same tool for both gives you oversight for the entire life of the project and also encourages developers to communicate bugs during development using a familiar process.

Team SCRUM

Our development teams tend to meet 3 times a week.  True Agile development zealots will tell you that you should meet every day if only for 15 minutes.  Either way, nothing beats regular discussion for managing a project.  Near shore makes this more possible. Far shore teams tend to limit meetings to once a week, which then turns the meeting into a status report, or they meet more regularly by extending the working day for the US team members.  We recommend meeting with Skype at least 3 times a week to allow the team to ask questions and reveal what they are working on.  In fact, if you achieve this, you will find all your other collaborative efforts are enhanced and supported by these regular discussions.

Tip: Use a low cost screen sharing product such as Acrobat ConnectNow or GoToMeeting to encourage code walk-throughs and interface reviews.  Start the Web conference each meeting so that if an engineer has an inkling to share, he can do it right then and there.  Imagine that, working with an outsource team and yet still talking to the engineers on a regular basis and still having the opportunity to review code.

Leads Meetings

Discussions with the team lead remind me of those back room discussions from political arenas.  You know, the meetings where all the real decisions are made.  That’s not really the case with software development, but often critical issues can be effectively resolved with a quick meeting of the key minds.  Some managers set up a regular time each week for this.  If that works for you, great.  We save leads discussions for escalation.  Leaving them off the schedule means they happen only when they need to and that makes sense since issues should in general be discussed openly with the entire team.

Tip: Use video with lead discussions to enhance communication.  Facial expressions and visual cues are extremely helpful when reviewing difficult issues.  Plus, when your lead delivers a snarky response, it helps to see if he is genuinely not happy or just yanking your chain.  Believe me, both happen although some leads aren’t as funny as they think they are (sorry guys).  Skype with video on a MacBook is awesome for this.   There is no setup and starting the video is as simple as clicking an icon.  Below is a chat from just this morning where we reviewed a few last minute changes to our release.

Video tip: When you speak, look at the green dot on your computer and not at the video of your lead.  This is like looking at the camera, and not the monitor, when you are on TV.

collab

Thanks Christian (guy in the larger image) for letting me (guy in the baseball cap) post your picture!

2 Comments | Development philosophy | Tagged: , , , | Permalink
Posted by bbenedict

Is 2 Months Reasonable to Launch? Or even Doable?

January 19, 2009

We see a very interesting pattern for launch dates in requests for proposals (RFP) that we receive. Nearly everyone who starts development from April to August wants to launch in October. The trends makes sense when you consider seasonality. The difference between April and August is obviously significant. Yet, companies seem to want the same amount of functionality regardless if development starts in April or August:

“Why can’t this be done 2 months? How hard can this be? Can’t you just use some open source products and customize them? We don’t need to start from scratch here. My expert says…”

Customers bring up many salient points during these discussions. Can the team work longer hours or can they work smarter? If a set of features requires 6 months to reasonably develop, can it also be done in 2 months with about the same size team? In this previous post, we point out that coding is physics and that we can’t simply reduce the schedule to meet a deadline.

Have you seen those home improvement shows where the contractor blows the schedule and the budget because of some unforeseen factor or change in the plan by the home owner? The home owner looks at a set of materials, imagines in his head the work to put them together, but never quite understands that it is never that simple. With software development, it’s the same principle. People look at a set of features and think in their heads, sure, this is doable in 2 months. They rarely consider that the implementation may not be as simple as they think, or that they might see the product and decide what they wanted is not what they thought.

Let’s look at a simple feature example of implementing sign-up and login. You can’t do much in a product if a user can’t create an account. An experienced developer using PHP or Java could do these features in a few hours by creating an HTML form and writing some SQL to add or look up a record. If features are that easy, why do we even need 2 months?

A good team thinks about the best way to implement a feature above and beyond the mechanics needed to create a form or put a record in a database. The developer must define a user object that has properties like email and password and functions like saveUser and validatePassword. The team must define objects smartly, otherwise you may have longer term problems maintaining your code base.

The page must be properly formated to match the mock-ups and overall aesthetic of the site. Color and font attributes are centralized in CSS files. If these are the first two features of the site, then the login and sign-up pages created will be the ones that define the styles for the rest of the site. Usually, the team needs a graphic or two from the designer as well.

The developer must also understand the client’s login and sign-up business rules. Do users login with email, login name or both? Must users validate their email before accessing the site? Should the developer check to make sure the email address is valid on input? We had 3 customers launch or hit beta in fall 2008 and each one had subtle differences in their business logic for sign-up and login.

You can now see how something as simple as sign-up and login might take a day to implement and another to test and validate.

With a new code base, the team must define the infrastructure of the code. Developers consider scalability, security, exception handling and a host of other services to make your product secure, robust and scalable. The best teams use existing technologies or frameworks to solve the infrastructure problems, but they still need to customize the code to meet specific needs. We no longer have to cut down trees or mill wood when adding on to your house, but we still need to cut the wood to size.

The good news about objects and infrastructure is that they both solidify over time and the effort to implement new features reduces. Economies of scale start to kick in once you have your solid foundation. You can hook into existing pipes when adding a bathroom on the second floor so to speak.

When you consider how much design work, object definition, and infrastructure is needed to create a scalable product, you just may find that 2 months is only enough time to get a small collection of features working. I told one client recently that after 2 months, the product will look like an unfinished house. Showing the product to their customers would be like walking on to a job site and imagining where the living room will be. After 3 months, you’ll see walls and after 4 months you’re painting them.

We suggest avoiding the 2 month launch for the simple fact that the best product comes from gathering feedback and re-thinking core problems, which is hard to do when the people providing feedback have to imagine where the walls of your hypothetical house will be. A development cycle of 6 months provides enough time to implement a robust feature set for launch, and to make improvements based on real feedback. This seems like a good idea to us. You’ll see this theme along with our predictions for trends in 2009.

My final point is this. If you launch with something that took you only 2 months to build, how defensible can that be if you happen to uncover the next new market like blogging, social networking, software-as-a-service or some new island in the Pacific? In 6 months, you can have something better, with more ingenuity and functionality, that has validation from your target market, and is not something a competitor could replicate in time to rain on your parade.

So back to the original question. Is 2 months doable? Maybe it is. Maybe, if we all stay focused and implement a minimal feature set, and if we don’t seek any feedback on what we created, it’s doable. But is it a good idea?

2 Comments | Development philosophy | Tagged: , , , , | Permalink
Posted by bbenedict

« Previous Entries