Category Archives: software

IEEE Offshore Panel Discussion

Today’s engineering managers need to be able to manage projects where some, or even all, of the engineers are located offshore. While the situation is becoming more common, the challenges and opportunities are still not widely understood. On the evening of March 6, the Silicon Valley IEEE Technology Management Council is bringing together 4 panelists, with diverse backgrounds and experience, to answer your questions about managing with offshore engineers.

Richard Danielson is Founder and President of PlanV Software. He has been a consumer and a provider of outsourced software development services since the mid-80s, working with offshore engineers from India, Russia, Israel, Taiwan, Korea, and Vietnam. One of Rich’s projects was helping Honeywell set up their Bangalore development center. In early 2007 Rich founded PlanV Software which provides Vietnam-based web and mobile device application development services to small and young companies.

Rakesh Gowda is the Director of Software Development at QuinStreet, a provider of online marketing and media services for nearly 600 clients, headquartered in Foster City. In 2005, Rakesh traveled back to his home country of India to set up QuinStreet’s development center in Pune, outside of Mumbai. He is pleased to report that the Pune team no longer requires his direct supervision for day-to-day operations. Rakesh holds a MS in Computer Science from Stanford and BE from the University of Mysore in India.

Accelerance CEO Steve Mezak has more than 25 years of software development experience and is a veteran of six Silicon Valley startups. He has served in a variety of management and technical roles, including CTO and CEO. Steve is also an internationally acclaimed speaker and author. His most recent book is Software Without Borders: A Step-By-Step Guide to Outsourcing Your Software Development. Steve holds a BS Degree in Computer Science from Worcester Polytechnic Institute, where he now serves as an advisor to the Electrical and Computer Engineering Department.

Dmytry Mykhaylov is a software engineer and project manager who has been working on geographically distributed projects for over 6 years. As a project manager he specializes in helping small to mid-sized projects in the Bay Area effectively incorporate offshore engineering talent. Dmytry firmly believes that an agile approach to project organization on all sides of a distributed team is key to a project’s success and profitability.

Chris Sims, founder of the Technical Management Institute, will moderated the panel.

Full details and registration can be found here.

Share it!


I occasionally still get calls to do software development. Recently, a potential client indicated that they would like a Windows shell extension created in C#. I’ve never built a shell extension, nor done any C#. Before meeting with the client, I decided I should take an hour or two to see how hard it would be for an old-school C++ and COM guy like me to get up to speed.

I downloaded the ‘Express’ version of C# and started playing with it. Pretty quickly, I had a command line app that worked like Eliza, but got the response text from Google searches. Fun!

Next I searched MSDN for information on using C# to create shell extensions. I found this article, which starts out like this:

This article illustrates the process of creating custom shell namespace extensions using C# and the .NET Framework. The author dispels some myths about the difficulty of writing such extensions, and shows that it is easier than it was before .NET.

Sounds good!

Until you get to here:

Because shell extensions are loaded into arbitrary processes and because managed code built against one version of the runtime may not run in a process running an earlier version of the runtime, Microsoft recommends against writing managed shell extensions and does not consider them a supported scenario.


Reading up a bit more it seems that COM, not .NET is really the right technology to use. It’s nice to see that my C++ and COM skills aren’t obsolete yet.

Share it!

Patterns of Agile Adoption

Mike Cohn has a great article in the Agile Journal in which he describes ‘patterns’ of agile adoption. The basic premise is that there are 3 choices that an organization needs to make about their agile rollout:

Small vs. All-In
Do we start with a small number of projects or do all our software projects go agile all at once?
Technical Practices First vs. Iterative First
Do we start by adopting things like test driven development and pair programming, or do we start by adopting short development cycles?
Stealth Mode vs. A Public Display of Agility?
Do we keep quiet about it until we figure out how to make it work or do we announce an ‘Agile Initiative’ with great fanfare?

Each decision should be considered in terms of the people, culture, customers, resources, and risk.
The result is 8 possible approaches that an organization might take in adopting agile software development methods.

The model isn’t exhaustive or perfect. I’m not sure about the ‘All-In’ / ‘Stealth Mode’ combinations, for example. But I think that it is a useful tool for thinking about how best to introduce agile practices into a given organization.

Share it!

Lunch With Joel Spolsky

I’m sitting in a Starbucks in the ‘Multimedia Gulch’ area of San Francisco, having just shared some fine San Francisco Burritos with Joel Spolsky. It’s been a few years since we last chatted, and much has changed. Joel’s company, Fog Creek Software, has more than doubled in size. They have mostly filled their recently expanded office space and Joel is busy figuring out how much space they should get to accommodate future growth. A new version of FogBugz has just been released and Joel is doing a demo tour. I think he still has space available in a few of his Bay Area demos. If you get a chance, check it out. I’ll be there tomorrow morning in Mountain View.

We explored the question of how big can an engineering group get before it needs formal leadership and management structure. Fog Creek is still below the threshold. When I joined FactSet, we were just getting there. I remember fondly the time when all the projects where single-person affairs. It is a much more efficient way to work, as each person that gets added to the team adds exponentially to the communication overhead. OK, exponential is really more theoretical (think fully connected graph) than practical, but the point remains that as the team gets bigger, more time is spent communicating.

We posited that very often, a company bumps into the need for more ‘management’ or leadership when they take on the task of building the second product. While the company’s original product may have evolved organically over time, starting as the brainchild and fruit of one person and growing head-count slowly, companies often try to accelerate the process with subsequent products. They have the bodies now, so they should be able to build out the product faster by assigning 10 or 20 people to the project from day one; right? Maybe, but such an effort takes leadership. Put 20 brilliant software developers in a room and tell them that the company needs them to build a snazzy new product and you will often get 20 radically different ideas about what that means how they should proceed. This is a perfect recipe for a bunch of thrashing, but not much progress toward a good product.

We sparred a bit over the value of agile development methods, especially Extreme Programming (XP), but that conversation quickly ended with us both agreeing that good teams can use such practices effectively and that dysfunctional teams can abuse them. In the end, it’s the people that matter the most.

Share it!

Agile Development Resources

Tonight I’m a guest lecturer at USF Cupertino, thanks to Juan Montermoso. Juan is an instructor as well as being president of Montermoso Associates, a marketing and training consultancy based in Silicon Valley.

Tonight’s talk is a subset of the material that I cover in my Agile Overview class.

Here are some links for those who will be at the class:

Wikipedia on:

Methodologies and Such:




Share it!

Paper Prototyping

LinkedIn has a cool feature that let’s you ask a question of your whole network. This morning, someone in my network asked this question:

Tools for visualising interactive prototypes? What do you prefer?

Powerpoint, ConceptDraw, Omnigraffle, Flash, Ruby on Rails?

We are reviewing the tools we are using to help visualise interactive storyboards and concepts for our clients. What are other people using? How important is it that the tool supports experimenting with real data and conditional branching in order to explore with the development team the consequences of their design decisions?

My reply:

Consider Paper Prototyping.

It is low cost, easy to do, and will quickly teach you how a real user will react to the system. With a paper prototype, a human acts as the computer, so your prototype can support some very sophisticated logic without the need to create code. Modifications are trivial, encouraging experimentation, discovery and improvement. I was skeptical at first, but after using it a few times I have become impressed with the power of this tool.

Photo courtesy of

Share it!