Teams Need More Than Technical Leads To Succeed

July 10, 2010 2 Comments

Managers love a good lead.  Your “go to guy”.  Your problem solver.  She can collect a random set of inputs and come back with the right thing to do even if not a single one of the inputs hinted at the true problem.

I had two calls today with different types of leads (hence the pronoun switch in the opening paragraph) and both of them impressed me with their understanding of leadership in the team context.  The goal of the lead is to get to the right answer for the tough problems using the best information and resources available.

Some leads are thought leaders.  “Let me go off and think on this one a bit.”  Other leads are researchers and consensus builders.  “Let me get with our UI developer and designer and see if we can’t find a solution.”  Still other leads are coaches, which is one of my favorite types.

I am familiar with the recruiting practices of some of the larger software companies in the valley and have noticed that several of them seem to be only recruiting leads and leadership personalities.  Some top-notch engineers slipped through the cracks because the process did not account for teams and different leadership styles.  Put another way, while I love a good lead, the best teams I have managed were great because everyone executed their role well.  Michael Jordan starting winning championships when he started passing more.

I created the follow graphic to illustrate what I mean.  Please, no jokes about this not being a pyramid though I do love a good pyramid too!

The image shows various roles on a project.  Typical challenges, issues or areas of functionality you might encounter are listed in the center.  This team might be used to develop and deploy a large-scale application in a hosted environment. Your team make-up might be different, for example, smaller development teams often have one lead/architect/data architect.

Take integration in the lower left as a good example for how this chart works.  Programming interfaces can be very detailed and time-consuming to learn. Server engineers tend to be more disciplined and focused. Also, you should use the same person who designed the integration to implement the solution to limit the learning curve to one person. You need the system admin to work on protocols and security issues. As another example, user stories often come together from a collaboration between design and development teams.

You now see the challenge if you hire only leads for your teams.  We can set aside all the comments like “too many chefs spoil a meal” or “too many chiefs and not enough Indians” if you like.  Simply put, the best people to solve problems might be those who actually prefer not to be in leadership positions.  You’ll end up with a treasure trove of people who might be really into the minutia of data or very interested in understanding how systems communicate with each other.  The best teams are filled with diversity and overlapping interests.

The lead is essential and the best ones form the foundation of a strong team.  Once you have that person, your best bet is to surround him with specialists, experts and code jockeys who all understand their role in the team dynamic well.

Filed under Development Management Tagged with , , , ,

An Honest Discussion About Adding Features Late

March 16, 2010 1 Comment

Let’s have a good honest discussion about adding in features late.  I don’t mean late like the schedule is already set and this may or may not have impacts.  I mean late like the release is just around the corner and are you crazy!  If you work at a start-up, then yes, you might actually be crazy.

The problem with adding features late is that there never is a guarantee the feature will work out.  A last minute change could make the release and get you on TechCrunch.  Or you could put in something that doesn’t matter only to find you broke something that does.  Release management is a guessing game simply because companies never have enough time and resources to test everything a user might do.

Repeat after me.  It’s always a judgment call.  It’s always a judgment call.

We use software development processes to manage decisions like this.  Two of the most dominant development philosophies in use today are Agile Development and SCRUM though some people incorrectly think they are one in the same.  In fact, there is even a book called “Agile Development with SCRUM”.  However, there is one interesting difference in the foundation of these two approaches that illustrates my point:

SCRUM by definition:

During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. (a sprint is typically a 30 day period)

From the principles behind the Agile Manifesto:

Welcome changing requirements, even late in development.  Agile processes harness change for the customer’s competitive advantage.

SCRUM manages the risk by locking things down at some point and avoiding the conversation.  After all, the next release opportunity is only 30 days away.  Yet Agile foundations encourage a certain amount of flexibility and consideration. Being customer focused means sometimes taking the risk.

Make sure you check at the Agile Manifesto.  I would have given anything to be a fly on the wall during that discussion!

How late is too late?

We can certainly agree that if the software is going live tomorrow, responsibly we should only fix critical issues that render the product not releasable or worse yet that might corrupt customer data, right?  Other than that, there isn’t enough time to re-test everything and even the best guys make simple mistakes.  But what about embarrassing spelling errors or showing a login name with a poster’s comment?  The team can fix something as easy as that, can’t they?

Assuming the feature truly is important enough to consider, here’s what you should ask yourself:

  1. Is there enough time to do the change and test the change?
  2. Do we have someone we can free that we trust?
  3. Is the impact of not having it worse than the impact a mistake could have?

If you can get a yes to all 3 of these, then the risk is worth it.  If not, then you are pitting customer satisfaction against customer confidence if you make the wrong call.  Technical leaders in general would not proceed.  Individual changes are rarely that important in their eyes.  Product managers and execs almost always say go for it under the guise of “we can’t afford to wait.”

Breaking this problem down might not be as hard as you think. Put your late feature decisions into one of these buckets:

No brainer in – Yes, yes, yes to all three questions above.  We can get it done and tested and we have a guy we can free up.  It’s safe so let’s go for it.

No brainer out – The answer to most questions above is no.  There isn’t enough time, no one is available or the risk of mistake is far greater than the benefit to the business.  Don’t forget that customers often don’t miss what they don’t know about.

Hard calls – The answer to at least one of the 3 questions above is no.

The only bucket to keep you up at night is the hard call.  For me, the decision almost always comes down to the code base and the team.  Is the code base solid enough where I can take risks?  Is the team good enough where I can trust them with this risk?  I have been at companies where the leadership doesn’t understand why we don’t go for it.  The blocker is often that we are managing some level of legacy code that can’t be rushed.

I think that’s the hardest part.  Leadership and investors want companies that can release every two weeks.  Even with our own product hinventory.com we are following a release frequently strategy and it is working well. But if the product or team is not set up for quick releases, then I am sorry the answer is probably no…

…for the hard calls anyways…

…we can put the change into the very next sprint…

…are you crazy…

…do you really think that feature matters that much to risk the release…

…we’ll keep the change isolated and release it a few days after…

…maybe we can go for it but if we see any adverse effects we are reversing the change…

…it’s in the product but we’re going to keep testing after release and stay ready with a hot fix…

…see you all Saturday, at least the company is buying dinner…

I did say it would be an honest discussion.

Filed under Development Management Tagged with

Understanding Web Development Resources

March 10, 2010 1 Comment

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.

Filed under Development Management Tagged with , , , , , , ,

Design Tips from Lessons Learned in 2009

December 9, 2009 3 Comments

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.

Filed under Development Management Tagged with , , , , , ,

Understanding Engineering Management Through Shipping Metaphors

May 31, 2009 Leave a Comment

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

Filed under Development Management Tagged with , ,

Is 2 Months Reasonable to Launch? Or even Doable?

January 19, 2009 3 Comments

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?

Filed under Development Management Tagged with , , , ,

Engineers Discuss Philosophy, But Only Late Nights in Skype

July 27, 2008 Leave a Comment

It’s 9 pm at night and I am chatting with my Ruby on Rails architect in Argentina who is working late to prepare a demo server. I know just how late it is in Buenos Aires because I have multiple world clocks set up on my iGoogle home page.

One of the things I like most about near shore development is getting to know people all around the world. This month, I have projects with team members in Argentina, Peru and Costa Rica. As a person interested in both technology and the world, I am grateful to have found a way to combine them both. And by the way, I am showing it is 1 AM in Argentina and the guy is still going. What a rock star!

While I wait to look things over, I am playing poker in facebook, perusing contacts in LinkedIn for business where I just requested to join the Intuit Alumni group, and started a download of the first season of Lost into my iPhone for my upcoming trip to see my sister in NY.

My engineer wants an iPhone. I tell him the quality is not so good but we agree the device is cool anyways. Then he introduces me to the Jawbone Blue-tooth borg ear phone and the video alone convinces me I need to have it too. Turn about is fair trade so I point him to thinkgeek.com and the 2 Gig USB drive watch I bought the other week for $30. Looking around my desk, in addition to the multitude of computers, I observe a sea of thumb drives, USB hubs, think geek devices, and wonder if maybe I should admit I have a problem.

I decide I need a new movie for my trip and buy Cloverfield instead.

While he’s waiting for a job to finish, we discuss github which he wants to use for source code control. I am open to considering this. So he sends me a YouTube link to listen to Linus Torvalds discuss his creation. We like the idea of combining EngineYard, github and RallyDev (we’re not exactly in agreement on this last one so he tries to persuade me to look at Lighthouse) in one suite of Software as a Service tools for managing a project. This seems like a very effective approach to me. I agree to look at it later.

In case you are not keeping track, the technologies and related topics we have hit in just the last 30 minutes of our Skype session include: Ruby on Rails, iGoogle, facebook, LinkedIn, Blue-tooth, Jawbone, Apple, iTunes, iPhone, USB, Intuit, YouTube, Linus Torvalds, EngineYard, github, RallyDev, SaaS, Lighthouse, and Skype

I have two minds about this (I am a gemini after all): first, this is really fun to be in the middle of such a dynamic, evolving and exploratory industry; second, how can we all possibly stay up on everything that is happening in all this industry???

I guess the answer lies in late night Skype sessions waiting for builds. But I know in the next week, a client or prospect will ask me about the latest JDK, virtualization, cloud computing, Ning, something like that, and I will be back again Googling the Web trying to keep up on the latest trends and changes. That is what I think defines a geek. Not if you do this, but do you enjoy it?

After finishing this post, we had a really funny exchange in Skype I thought to add. It really captures the essence of my point this evening:

ARCHITECT
java isn’t full oo language
you allways fall on the primitives
and all oo goes to the hell
with generics java adds some dynamic
but still you need to write to much code

ME
Yes. If you get just wood, you really need a good architect to build a good house

ARCHITECT
yes, but, you cannot build a house of ice at africa

ME
Now THAT is funny.

Filed under People & Places Tagged with , , ,

Follow

Get every new post delivered to your Inbox.