Welcome to the Attivio.com blog! Our goal in blogging is to provide interesting and useful information for those interested in the next generation of information access solution - the Active Intelligence Engine (AIE) - and our plan to enable the enterprise to correlate what people do (in structured data) with what they say (in unstructured content) by querying with the precision of SQL and the fuzziness of search - among other applications.

Unlike some corporate blogs, content here will not be the product of one or two authors. Many of our staff members will be posting. Topics will range from high-level to moderately technical, focusing both on technology and applications.

Let me start by introducing myself as the first poster. I am the CTO and co-founder of Attivio. My background includes work at two previous search companies, both of which were successful (though in very different ways.) Attivio is my fifth startup company and definitely the most exciting - at least partly because I get to continue working with brilliant people from several of the previous ventures.

One thing I am extremely proud of is our success in building and shipping software to customers. We have delivered two generally available releases in less than one year, both on schedule. People often ask me how we do that. Some of them intimate that we must be getting "burned out" because of all the "100 hour weeks" we must be working. The short answer is that we try to work smart. (I admit that I hate that cliche - but no good alternative comes to mind.) Or, to put it another way, we have a very deliberate approach to building software. To wit:

• We have never written an exhaustive specification for any version of AIE. Instead we designed and implemented a superb, SEDA-based architecture that removes uncertainty from the process of designing, implementing and scaling features. There are really only three ways to add features to AIE: workflows, components and services. All of them have base classes which are used as a starting point for implementation.

• The architecture included a model supporting customization of the product via overriding the system configuration - not modifying it. This ensures that customer implementations don't suffer during upgrades, and, conversely, that product development doesn't get tangled up with customer-specific modifications. (I'm sure many readers have faced this challenge before - it was a common problem at some of my previous startups.)

• We represent features, capabilities, etc, as tickets (in Jira) with supporting stories. All tickets are prioritized with respect to our technical and business goals, and customers’ needs. In other words, we do agile development. (For the record, we have our own model based on past experience with multiphase, SCRUM, XP, AUP, no method at all, etc.) Implementation is done via time-boxing - three week sprints followed by a week of reflection. We have effectively aligned the entire company around this cycle, to the point that all company meetings, training sessions, etc, are scheduled during reflection weeks.

• We emphasize collaboration instead of top-down design. (The architecture is the obvious and logical exception to this.) Beyond that, and especially when looking at a feature, we try to provide just enough guidance so that the objective is clear, then let our staff members interact (amongst themselves and especially with customers) and build consensus around the implementation approach. We try to support this in a variety of ways, including our office layout. The floor plan is open, with desks arranged around the edge of our largest space. Collaboration tables and movable whiteboards are in the center of the room. During the day, especially in the morning, it's common to see groups of two or three sitting together, working on interesting problems. Later in the day people typically stay at their desks, coding the consensus solution.

• We try, at all times, to allow for self-selection of work. It's not always possible, but when we connect someone with a challenge they WANT to solve, the results are always better. This is probably just common sense ... but, at least in my experience, not a sufficiently common practice.

• We don't have any standing meetings during the implementation phase - except for a daily standup. (Meetings are not necessarily the same thing as collaboration.) Ad hoc meetings to reach consensus do occur infrequently, but overall, the result is that most engineers spend most of their time ... writing code! (Some staff members consider this a refreshing change.)

• We are borderline religious about automation, and especially continuous integration. Every check-in sparks a build and a ton of related tests, including performance benchmarks. Large flat-panel displays at the corners of our work area display the results throughout the day. It's a wonderful reality check - there is never any real question as to how we are doing, what progress we are making, and what work remains to be done. In the event that we get behind, we can make accurate reductions in scope. (And when we are ahead, we can add features!)

• To support the automation goal above, we are very careful about selecting tools that support our goals. You will find the entire Atlassian Software stack - JIRA, Bamboo, Clover, FishEye, etc - in use at Attivio.

• We subject most every implementation task to a rigorous build/buy decision. Bluntly, if it's a commodity, or something that requires deep domain expertise we don't have in house - we will do everything we can to avoid building it. We'll license it, incorporate an open source version of it, etc - whatever it takes. We want to focus on implementing new capabilities that solve problems for our customers. If you have an Attivio Developer Network account, you can view the list of 3rd party products here.

(Interestingly enough, I heard a lot about build/buy when I worked for a highly successful financial services company. They were actually pretty smart about technology - it wasn't their business and didn't need to be, so they got good at evaluating technologies and buying them. I rarely heard about build/buy at startups until after the dot-com era. Historically, startups have wanted to build everything because buying capability doesn't translate into "IP" and thus valuation. Today as open source changes the world for the better, build/buy is a no-brainer.)

• As part of the build/buy decisions, we are extremely careful about correct use of open source. Black Duck Software's superb Protex/IP product makes achieving that goal easy. We also view the open source communities as a key part of the eco-system that enables our rapid development. We've submitted patches to several projects, and recently began sponsoring some specific goals in the POI project. And this is just the beginning ... we will have more to say on this topic in a future post.

It's safe to say that we combine all of this with hard work. No software company can accept less than that in today's ultra-competitive environment. But we don't do 100 hour weeks. That's also not acceptable. At Attivio our goal is to build a strong, independent company - a long-term goal that requires endurance. To put it another way - building a great software company is more marathon then sprint. Burning out is not an option. And neither is being late with software.

Of course it's easy to ship software "on schedule" if you forget about quality. In my view being on-time is far less important ... we have an equally deliberate approach to quality which I will detail in my next post.
I would love to hear about how your company develops software, along with your comments on what we're doing. Please feel free to write me directly and thank you for visiting the Attivio Blog.

Sid Probstein, CTO

Click This e-mail address is being protected from spambots. You need JavaScript enabled to view it to email Sid your comments.

TrackBack URI for this entry

Comments (0)