Understanding Development from a Day In the Life

November 23, 2009 Leave a Comment

Monday morning is the time when our teams interact the most about projects and the coming week.  I’ve decided to capture events typical of Monday to provide insight into our work developing products for clients.  I’ll do my best to include everything warts and all even if that means sharing something I would not normally share.  In support of full disclosure, I took sparse notes over a period of time and came back later to clean up the text and add commentary.  Here goes nothing!

Our high-tech revolution has plunged us into a state of continuous partial attention.

iBrain by Gary Small, M.D. and Gigi Vorgan

- A typical Monday starts by pulling my canoe out into the various communication streams.  Logging on to Skype is the watershed event.

- Skype is running.  Firefox is open with tabs for email, calendar, several Google docs, WordPress for this post and YouTube for a side project I am working on.

- I check in with my lead on Skype.  I have the same guy across a few of my projects.  This certainly streamlines the communication.  He’s in Costa Rica.  When I worked at Adobe, we used IM all the time as people worked on different floors and at different locations.

- I am acting as the product owner for one project and I clarify something about a feature we are implementing.

- On another project, our client provides detailed specifications and we review the documents to make sure we are in sync.  We are, which is good.

The new promise of collaboration is that with peer production we will harness human skill, ingenuity, and intelligence more efficiently and effectively than anything we have witnessed previously.

WIKINOMICS by Don Tapscott and Anthony D. Williams

- Our newest client jumps on Skype to validate the release, our testing and the schedule.  There is a lot to discuss so we move to a Skype call. He does a good job managing his business to create an active and valuable community.

- Another issue comes in about how a feature should work that requires some thought.  I ignore chats and emails for the next 30 minutes and open specifications in Google docs and mock-ups in Preview.  We clarify the issue.

- By late morning, the major communications have been completed.  Projects are moving forward and our teams seem to understand what needs to happen this week.  I am responsible for a couple of releases that are in full swing.

No matter how clever the idea or great the implementation, an invention typically lives or dies depending on how well it can be integrated into a larger social or technological context.

Juice by Evan I. Schwartz

- The marketing text for our Web site update is long overdue.  Some tasks on the docket this week are for corporate business.  But I decide to focus on that side project and YouTube.

- I started a project called ReachGivers.org to help charities and non-profits get their message out over the Internet.  ReachGivers.org uses Ruby on Rails and has Twitter integration.  I added a poor man’s blog a while back as well.  This week I want to add video support.  Side projects help me stay connected with technology.

Economics is above all a science of measurement.  It comprises an extraordinarily powerful and flexible set of tools that can reliably assess a thicket of information to determine the effect of any one factor, or even the whole effect.

Freakonomics by Steven D. Levitt and Stephen J. Dubner

- Off to Starbucks for a Mocha and a blueberry scone.  This happens so often that people know me by name there.  The Ethos water billboard reminds me I wanted to blog about that on ReachGivers.org after finishing the video work.

- My brain stumbles on some concepts for the marketing text and I jot down some ideas.

- I was working on a product a while back and was not that impressed with the end user documentation.  I sent a book proposal out to a technology book publisher, which turned into a series of titles, and I have been writing every since.  I love it, I really do.  I even enjoy working on marketing text and ads.

Execution is not a one-time event.  Nor is it a process where you check off goals as if your sixth-grade teacher were looking over your shoulder.

The Art of the Start by Guy Kawasaki.

- Shorty before noon we get a curve ball. Mid-cycle, our client needs to shift direction on a project to change the prioritization and the release date.  I’ll spend the next few days updating user stories and validating the new plan. Sometimes I feel like we’re actually better at hitting a curve ball.

- The Agile software process, which is intended for flexible development, actually advocates against this type of mid-cycle change.  Release cycles are purposely shorter so that a direction shift simply influences the next cycle.  For start-ups, next month can be years away.  We have to be more flexible.

- A site we monitor generates an alert right before I can escape for lunch.  I used to get a little rush on these mini-emergencies like working as an EMT. Now I am the ambulance driver who knows that most pick-ups are not at all like the show ER.  Still, up-time is important and so we resolve the issue as quickly as possible.

- It occurs to me that this post demonstrates why people Tweet.  Expressing myself effectively with 140 character didn’t work well for me.  I decide to try it again because I am enjoying creating this running dialog.

- We’re trying to send large Photoshop files with mock-ups.  Some days technology just seems to work against us.  We’re hitting proxy issues and time out issues.  Eventually we solve the problem and remind ourselves yet again we should standardize on an approach.  Problem is, email and Skype are so convenient and work well enough most of the time.  I guess this would be one of those warts.

Agile software development methods should be able to survive in an atmosphere of constant change and still emerge with success.

Agile Management for Software Engineering by David J. Anderson

- After 40 plus years of eating sandwiches, I still love a good sandwich.  The best sandwich in town is from the deli in Vallergus and the people at the cash register all know me by sight.

- I never get back to the post after lunch.  Clients and partners all eat at different times and issues were waiting for me when I got back.  That is definitely a typical Monday.

- I didn’t finish the marketing text either.  The text I came up with was not remarkable.  I made some small updates to our corporate site instead and also finished my changes on ReachGivers.org.  Perhaps I will think of something while winding down for the night.

- My iPhone sits by my bed.  With several releases in play, there is always a chance a developer is still working and will fire off a question.  Of course, I can’t just let the device sit there, now can I?  I pull my canoe back out into the stream and see what else I might have missed during dinner.

Filed under People & Places Tagged with , , , , , ,

Integrated Outsource Partners

November 16, 2009 Leave a Comment

Open Mountain software projects succeed because of our tight integration with our primary development partner Avantica in Costa Rica.  This connection sets us apart from most other outsource providers.  After all, who can provide a local contact with significant career experience in the US and also deep experience with cost effective resources in another country?  You need two partners who spend the time and effort to remain tightly integrated.

How do you know for sure we are as integrated as we say?  Have a look at the photos below from some recent trips with us going to Costa Rica and our partner coming here.  Open Mountain and Avantica work well together because we make the effort to become familiar with each other.  We know the teams in Costa Rica and nearly everyone in the Avantica has been on one or more of our projects.

Leaders GG bridge

The leadership of our partner Avantica at the Golden Gate Bridge.

Better Leaders Napa

The Avantica team at Rubicon in Napa.

Teams Napa Improved

Open Mountain showing Avantica engineers one of the oldest wineries in Napa.

Team Costa Rica

One of our newest clients meeting with Bob and the team in Costa Rica.

Costa Rica

Where Bob and Tom stayed over the weekend in Costa Rica.

Napa

Avantica and Open Mountain enjoyed wine over lunch with this view of the vineyards.

After you look these over, you’ll have to tell us who visits the better location.  I do like my Costa Rican beaches and Imperial beer.  But how about the Golden Gate Bridge and wineries of Napa?  It’s a tough call that I am glad that I don’t have to make.

Thanks to all the travelers who donated images for this post! – Cheers.

Filed under People & Places Tagged with , , ,

The Funny Side of Web Development and Multiple Languages

November 9, 2009 1 Comment

I was adding a few features to a product the other week when I contemplated that often times the simplest change takes forever and adding major features can be a snap.  The inconsistency comes from the complexities of Web development.  To illustrate the point, I am going to borrow material from one of my favorite comedians Robin Williams.

Robin did a routine a few years back about the invention of golf by the Scottish using a conversation between the drunk Scotsman who invented golf and an interested player:

Drunk: We’re going to make a game.  We’re going to make you put a ball in a gopher hole.  It will be really fun. (hiccup, burp)

Player: Sort of like bowling?  We roll the ball into the hole?

Drunk: Heck no.  We’re going to make you hit a tiny ball with a stick.

Player:  I guess if we are not that far away from the hole-

Drunk: Heck no, we’re going to put you a couple of hundred yards away.

Player: Hopefully, you’ll at least make the thing straight so we just-

Drunk:  Heck no, we’re going to curve holes left and right.

Player: Just don’t put anything in our way.

Drunk: Heck no, we’re going to put water and trees in the way and even sand.

Player: We can try it once to see-

Drunk: Heck no, you’re gonna do it 18 times…

I think you get the point.  Different holes and sand traps certainly make the game fun, but these obstacles also make golf challenging to learn and harder to master.  Web programming feels the same way to me.  There are many reasons why it has become so complicated from humble beginnings.

Just for your edification, the essence of any Web site is a URL which looks like this http://www.openmountain.com/hello.html.  Somewhere on a server, there sits a file named hello.html.  All the other stuff on the URL before this file name helps the Web browser on your laptop locate this file on a central server and download it to your laptop for display.  I know, I know, this is so 1997.

The file hello.html contains HTML which is a simple display language.  The browser understands this language and can turn HTML code:

<html><head></head><body>

Hello <b>Robin</b>! How <i>are</i> you?

</body></html>

into this:

Hello Robin! How are you?

If only Web programming was that simple.  Here now a conversation between our fictitious Web creator Lee and our programmer Marc:

Lee: I have created the Web for you so you can put all your information and data on a central server and everyone can share it.  To display your information, you just need to create HTML files for people to download.

Marc: That’s fabulous!  I love it.  Can’t wait to start.  Can I add If statements and For loops so I can do real programming?

Lee: Good point.  OK, I will add Javascript in the file.  You can code loops and stuff using <script> tags and do display with HTML.

Marc: That works.  But wait, if all my data is on the server, do I have to download all of it all the time?  How do I get only the data user’s want?  Use Javascript on the server?

Lee:  Heck no.  We need a completely different language for that.  It will execute on the server where your shared data is.

Marc: OK, we’ll execute all the code on the server.  We don’t need HTML and Javascript anymore.

Lee: Heck no.  The output of the code on the server will be HTML and Javascript.

Marc.  So our code will output code?  Seems complicated.  Well at least the server side language can collect data and do processing all in one language.

Lee: Heck no, you have to use SQL language to extract all the data and then another language to process it and create the HTML and Javascript.

Marc: Wow, that’s a pain.  I guess so long as there is only one server side language in addition to SQL that’s not too bad.

Lee: Heck no, there’s Java or PHP or Ruby on Rails or Python or-

Marc: I get the point.  So let me get this straight.  I have to learn 4 languages 2 of which execute on the server and produce output that is comprised of the two other languages that run on the client.  Is that right?

Lee: So far so good.

Marc: I was expecting another response.

Lee: Which was?

Marc: Never mind.  OK, so now my users want more interactivity and less download times.  If I pull down all the data they want at one shot, then every time they request something else I have to go collect a bunch more stuff, right?

Lee: Heck no, but this “heck no” is one you’ll like.  You can use something called AJAX to go back to the server and just pull a little bit of information.  Users love it and it uses Javascript and the server side code you already have.

Marc: Finally!  OK, that’s cool.  So I just have Javascript, my server language and SQL and I am set.

Lee: Well…

Marc.  Don’t say it!

Lee.  Um, well, hmm, heck, um, no.  See the X in AJAX stands for XML.  Now XML is a lot like HTML so it’s not exactly a new language.

Marc: Lee, did you ever think about what would happen if I had a bug in my code?  Like a user clicks a link that does an AJAX call and it does something wonky?

Lee: That could be a problem.

Marc: Yes it could.  The bug could be in the server side code in the SQL or the server side language that is executed when I first download the page.  Or it could be in the client side code in the HTML or Javascript that is generated.  Or it could be in the server side code that gets executed when AJAX is called which also has the server language and SQL.  Or it could be in the result that comes back from the AJAX call which has HTML and Javascript and XML.

Lee: Did I show you how easy it was to create a page to say hello to Robin Williams?

In case you were wondering, the feature that inspired this post was your standard geo map integration.  Creating a map on a basic HTML page should take you no more than an hour at most.  Our product uses toolkits with the Rails framework and the nuances from using both combined caused the delay.  In the same amount of time later that week, I created user profiles with custom fields and modified the product to show the thumbnail of the user’s photo with comments.  I guess some holes you par and some holes you double bogey.

Web development truly is comprised of server side code operating on shared data and client side code running on your local computer.  The client code is primary about presentation and analysis.  Server side code manages shared resources and data.  If you think about it, optimizing languages and development processes for each scenario seems like the correct approach for creating a well-functioning solution.  The complexities of engineering are a necessary outcome of distributed systems and data.

Although, we think it is entirely possible to create a single integrated development environment that separates organically upon deployment.  You should then be able to standardize languages and processes.  We’ll add that to the list of other ideas we may never get to.  Would it be cheating if your golf club used a robotic arm with laser sighting?

You can find Robin’s original routine at the link below.  I am warning you that it is filled with tons of profanity.  This should be no surprise to Robin Williams fans.

Filed under People & Places Tagged with , , , ,

Developing on a Platform Creates a Dependency

November 2, 2009 Leave a Comment

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.

Filed under Development Management Tagged with , , ,

Follow

Get every new post delivered to your Inbox.