Several years ago, a few of us were working on a project for another company. The goal was to introduce a new way of doing chip design that was so simple that a new grad from college could tapeout chips. The project was obviously challenging, but management would ask questions like: “This product is supposed to be very simple to use, why is it taking so much effort to get it all put together?”. This confusion is common: simple to use must mean it’s simple to build. The reality is that making something easy-to-use is even more difficult to build.

Most technical software in our industry requires weeks to get installed and running using your data. The vendor chalks this up to the slogan, “It was hard to build, it should be hard to use.” Yet there is a very real sense that when tools are complex, we assume they are powerful. Complex tools may be powerful, but not because of their complexity. When we sought to build Pinpoint we were forced into thinking through this tradeoff.

The first alpha version of Pinpoint was not friendly to use nor simple. Just ask the first few alpha testers. The journey thus began, how can we architect this tool to be simple, yet powerful. How can we make the tool so that teams can measure whatever they want to measure no matter how their flow is configured. We broke the tool apart into component pieces: a server and a client. The server to display the pages and a client to collect data. The client would run as a commandline tool so that it could be easily added into the flow. We developed a high level API for both in TCL, Python and Perl. We worked with a user-experience designer to design the web version to be both flexible and have good defaults.

The result after many iterations has allowed customers to get up and running with their data in the tool usually within a couple of hours. We’ve had people bring up the tool with very little interaction in India, Japan, France, Germany, and the US. Within a day they can have the tool integrated into their flow and start capturing data. If you’d like to see how easy it is, check out the How-To demos on our demo page.

We’ve made a lot of progress, but we’re not done. Our goal is to make things easier. Easier to communicate, easier to visualize, easier to track. This is a never-ending quest for us to continue to improve the overall experience.

Our products encourage collaboration for our customers, and at Tuscany we are reaping benefits internally by taking our own advice: Build the strength of your team by regularly practicing frequent, small-scale collaboration.

Earlier in our life as a company, our practice was to assign each engineer the responsibility to deliver what were essentially independent features.  This worked okay, but it had several big drawbacks. First, it isolated the engineers into their own thinking. Sometimes there would be some coordination between a couple of engineers where features overlapped, but mostly each engineer worked independently and developed isolated solutions that only he or she understood. Helpful feedback between peers could be a big challenge.  Second, the engineer who took the longest, delayed the overall release.

We got the job done, but over the last six months we’ve changed our approach, and it’s increasing our productivity and strength as a team. By breaking each major feature down into it’s component pieces, and then assigning the various engineers to work on parts of those pieces, the team is working better than ever. Besides minimizing the two costs above, we develop better code faster.  Since people can pick up slack for each other, and since the team shares a more global understanding of each feature because essentially we all work on many parts of many features, the excitement of everyone involved increases.

Visiting our Fort Collins Engineering office, you can sense the enthusiasm of the team.  They work fluidly, collaboratively, and together get a whole lot done. We also see it happen with our customers, Physical Design teams who have the tools they need to better collaborate and share their work. And when a team is working together toward a common goal, it’s 1+1 = 10 (not just in binary thing, either).