Welcome to our Blog!

We are 60East Technologies and we’re the creators of AMPS, the world’s fastest real-time streaming analytic database. A product like AMPS isn’t born overnight, but rather grown over years of development and discovery. In this first blog entry, we’d like to introduce you to our core beliefs and philosophy for building high-quality software that’s not only resilient to rapidly changing technology but also benefits from it.

Nurture Your Code

Software wants to run fast. As developers, it’s our job to show it how. At 60East we take great care making sure our code is properly nurtured to be the very best it can be. The 4 things we’re continually teaching our products:

1. Reduce complexity: Developers are reluctant to change complex code. Reduce complexity and you reduce reluctance. With proper controls, code should only get better by changing it, so making developers feel comfortable changing the code is critically important. Given the same performance and functionality, the simpler code always wins.

2. Increase Performance: We’re always experimenting with ways to tease out more performance, whether it be a new type of lock-free data structure or trying to get a O(log n) algorithm to run in constant time.

3. Simplify maintenance and support: We know customers adopt us for the performance, but they stick with us because of our commitment to quality and their success.

4. Be Fit!: We don’t like fat, lazy code. That’s why we’re always kicking our code off its idle-state loving butt and sending it through the obstacle course. We don’t test to show software is working. We test to show that it’s BROKEN! Run it until the wheels fall off. All software has a breaking point and we always want to know where ours is.

The “Cutting Edge” isn’t a Band-Aid

It’s tempting to use technology on the “cutting edge” as a Band-Aid for the software of yore. After all, it’s easy to get a 10-20% performance bump by just buying new hardware. Unfortunately, not all software is capable of taking advantage of the capacity offered by the newest hardware.

We know that the next generation of hardware could yield us a modest gain for very little work. However, we know from experience that if we spend a bit of effort we might find performance that is orders of magnitude better than the effortless, “Just Upgrade It” path. That’s why you’ll see us “unwrapping” a new vendor spec with the enthusiasm of a small child opening their first gift. Behind that cheesy grin, we’re thinking: Can we use that new SSE instruction? How could we use that new futex() flag? Which calls bypass the OS kernel?

Expect and Embrace Technological Change

When we first started building AMPS, dual-core CPUs were all the rage and enterprises were spending a fortune on 15K RPM hard disks. Now we have dual-core cell phones in our pockets and flash storage technology that makes spinning storage seem silly.

Knowing that the next best thing is just around the corner, we do our best to write elastic code that takes full advantage of increasing hardware capacity. Sometimes we nail it and end up with an algorithm that works well for generations of technology change. Occasionally we get it wrong. Either we didn’t plan for such a rapid improvement in technology or we need to refactor to make full use of new vendor APIs. Regardless of how often we’re correct, we always write code in a modular way so that we can be nimble and “upgrade” the code when the next greatest thing comes out.

Develop Meaningful Relationships

Developing quality relationships with our customers and vendors is just as important as developing the best code. We think of our customers as partners and will do everything we can to help them succeed in developing high-quality solutions for their own customers. We also have great relationships with our vendors because we have genuine enthusiasm for their technology and our plans for using it.

We work closely with vendors to experiment, evaluate, test and report on their, sometimes “bleeding edge”, technologies. We get a lot from these relationships as well, because we use these technologies as a “crystal ball” into the future. This helps us build software that fully exploits the capacity offered today as well as being capable of unlocking the gains of the future.

Remain Positive

Even though the future has always been riddled with vaporware and products that don’t deliver on their performance promises, we value the lessons of what doesn’t work just as highly as what does. Sometimes we’ll drool over a product specification for months and when it’s finally released it doesn’t meet our expectations. This can be frustrating, but we know that something better is just around the corner and we’re going to be ready when it gets here.

We’re always working on perfecting our craft and exercising the utmost discipline in enhancing our products, whether it’s documentation, testing, or writing lock-free data structures. Whether it’s ripping through online blogs to learn how others use “fuzzing” to test their products or reading up on the latest instructions supported by a CPU, we’re doing all we can to be responsible stewards of our code.

We hope this introduction gives you some insight into our methodologies and philosophy. We’re looking forward to sharing lessons we’ve learned and going into more detail on the methodologies listed above in the coming months. If you’re interested in getting future updates as soon as they’re published, please subscribe to our mailing list and/or RSS feed.

Until next time, happy coding!