Software and advice that’s not of this verse

Hiltmonisms for Hedge Funds

This post is another part in a series on Hedge Fund Systems, a series of posts based on my experience in the design, implementation, issues and thoughts involved in crafting an end-to-end platform for a complex Hedge Fund.

One of the things I have been writing about on my personal blog over the past few years is a set of Hiltmonisms - a bunch of maxims based on the collected experiences of my mentors and my own - on how to best create software and systems for businesses.

In this series on Hedge Fund Systems I have referred to these maxims in passing. In this post I spend a bit of time looking at the Hiltmonisms most applicable to Hedge Fund systems software design and development.

A Hedge Fund Technology Architecture

This post is another part in a series on Hedge Fund Systems, a series of posts based on my experience in the design, implementation, issues and thoughts involved in crafting an end-to-end platform for a complex Hedge Fund.

This is a modified version of my original 2004 architecture plan for a Hedge Fund. See The Opportunity for how it came about.

In this post I cover the objectives of the architecture, walk through the architecture itself and provide an overview of The Greeks, our implementation thereof.

The Opportunity

This post is the first part of a series on Hedge Fund Systems, a series of posts based on my experience in the design, implementation, issues and thoughts involved in crafting an end-to-end platform for a complex Hedge Fund.

The year was 2004 and I was being offered a new job to be the Chief Technology Officer of a brand spanking new Hedge Fund that would trade everything and launch within 6 months. Would I be interested in creating and managing a completely new technology platform to handle the end-to-end business needs of this new Wall Street firm?

Would I? You bet I would!

This is the story of how I got the chance to design, create and grow a new financial business’s technology platform from scratch. And as amazing as it sounds, it all happened, it’s all true.

TimeToCall Released to the App Store

Noverse is very pleased to announce that TimeToCall v1.0 has shipped and can be downloaded on the App Store.

TimeToCall is a universal iPhone and iPad application to help you choose the best time to call people in other countries based on timezones.

  • Over 4000 locations to choose from
  • Multiple Times to Call to lots of places
  • Choose a Time to Call from different places
  • Get a feel for when they are awake or asleep
  • Play with Time to find the best Time to Call
  • Available in Japanese as そっちは何時
  • Universal: iPhone or iPad (iOS 5.1 required)

Download it now from the App Store on your iPhone or iPad.

Read all about how the app was created in a series of articles on the thinking, effort and decisions that went into the making this iOS app.

We want to thank all our beta testers for testing TimeToCall and helping us make such a great product.

If you have any questions about the product or the series of articles, please do not hesitate to email us at

Noverse LLC is a New York independent software designer and developer, established in 2010 by Hilton Lipschitz (@hiltmon) to craft brilliant web, iOS and Macintosh software. If you are looking for someone to craft a product as well thought out as TimeToCall, feel free to contact me at

Time to Call - Coming Soon

“Ring Ring”

“Hmmmm Hello”

“Er Hi Mum”



“Do you know what the time is?”

“I know it’s after work in Sydney, but it’s 3AM here in New York”

“Yes I was sleeping”

“No, no, I’m awake now”

“Just please check the time before you call”

Never know when is the best time to call people overseas?

TimeToCall is coming soon for the iPhone and iPad.

Follow the author as @hiltmon on Twitter or @hiltmon on App.Net.

Hit by a Bus

What would happen to my clients and my products if I got hit by a bus?

It’s a fair question given that I am an indie, and not part of a large company full of backup resources. These are things my clients do worry about, and a question all indies need to be able to answer.

Well, firstly, if I am going to get “taken out”, I’d prefer something better than a dirty old MTA bus. Being kidnapped by a Time Lord would be more fun, forced on to a yacht to sail the world would be a better adventure, or made CEO of a Fortune 500 company would be a great way to give up the indie life. But I digress.


There are many things I do in order to ensure that there can be product and development continuity if I am no longer able to perform. These include:

Popular Platforms

I develop all products using common and popular platforms. For example, for servers I use stock standard Ruby on Rails on standard CentOS Linux boxes, running Nginx and Passenger. There are thousands of applications using the same stack, and thousands of competent programmers who can take over the product code base with ease. The same goes for Windows Apps (C#) or iOS (Objective-C). I do not use edge versions of development tools or undocumented API’s. I always use the most popular libraries. And I ensure that I use all the same naming and structural conventions for each platform to make it easier on others (and myself) to read.

The benefits of popular platforms are many, including:

  • Easy to set up, develop for, deploy and transition.
  • Easy to take over a standardized code base.
  • There exist many, many documented solutions to issues with the platform.
  • There are many, many programmers who can take it over.

External Source Code

All source code I write these days is hosted on Github in either my own private repository or on client repositories that I set up as part of the project. Each and every commit I make for each and every component is pushed to Github. The client can access this code at any time, and any other developer authorized by the client can look at it and start using it.

Any configuration files, settings, and other files required to make the product are included in the source repository, for both development environments and production environments. For example, the Nginx configuration file is always included so the client can set up their own Linux box to run their own server, or their own computer to enable development.

I also leave a copy of the source code on the production server, in case anything happens to Github.

Readable Code

I assume that my code is going to be read by others. I further assume that the code will be looked at by people who do not know the product and are probably under some pressure to change things. As a result, I work diligently to ensure my code is readable and maintainable in the extreme, including:

  • Using very descriptive names for each item, so it’s easy to know what each variable or class is and does.
  • Using a lot of local variable assignments to ensure the logic of each function is clear.
  • Filling the code with comments as to what each block of code does, even if it’s obvious to me.
  • Ensuring the code is formatted for human readability, clarity and understanding.

Maximum Developer Documentation

Before kicking off a project, I document the work to be done in a Statement of Work. It defines what the product will do, and is written in such a way that it can and is attached do the contract and is readable and unambiguous to the client. It also makes a great starting point for any replacement.

I write very detailed assembly notes and technical notes that I do not share with clients, but do include in the project folders (See Project Folder Layout). They exist so I can remember what I did and why I did things, but makes a great resource for those who take projects over from me.

There are notes explaining design decisions, server build processes, development environment setups and weekly notes on all programming done. I even copy in the command lines I use so that anyone can follow them. (See Assembly Notes for more).

Releases and Deliverables

For all product and client work, I issue regular, detailed project status reports covering the decisions made, changes made and features added. I also release all products early and often so the client grows with the product as it does. It makes it easy for the client to know exactly where everything is in case of interruption.

I also deliver an additional copy of the current code to clients in a zip file every quarter. This includes quarters where no new development was performed, but support or patches were made.

Off Site Backups

All project folders, notes and code is also backed up automatically off-site. Should the bus run over my primary computer too, I can always get back to where I was in seconds on a new device. And of course, clients can get the data from these backups if necessary as well.

For a very few clients, I run a sync of their Project Folder to their servers, putting my current data on their file servers and into their backup processes as well. Most never seem to even open these folders, but are confident that they are there and up-to-date.

Learning from Product Transitions

Several products that I developed have been taken over by the internal staff of clients. In each and every case, the transition was smooth and tranquil. In fact, many of the things I do for continuity came out of transition processes where we found information was missing or difficult to find.

No more.

That’s why I document everything.

In transitions, I work with the replacement team to:

  • Access the source code
  • Review the available assembly notes
  • Set up their own development environments
  • Discuss and answer any design, architectural or implementation questions

But if I had been “taken out”, all the answers are already in the project folder and assembly notes.

The M100 Bus

So if I am personally unable to perform for a client, there is little to worry about. Just grab another programmer, give them the code and the notes, and they will easily be able to catch up and take over. They may not have my experience or expertise, and will not be as quick and efficient as me, but they will be able to maintain and possibly even complete the product.

And anyway, I work from home, no busses here.

Follow the author as @hiltmon on Twitter or @hiltmon on App.Net.

Thank You for 2012

We at Noverse wish to thank all our wonderful clients and partners for such a brilliant third year in business. Unfortunately, most of our clients prefer to remain private, as in:

The first rule of Fight Club is: You do not talk about Fight Club.
The second rule of Fight Club is: You do not talk about Fight Club.

No matter, you know who you are.

Thank you for taking a chance on a growing business to service your needs. We have taken great pleasure in working with you, meeting your needs, delivering the best products to you and handling all your support queries. We look forward to helping you out in the future.

The big news this year is that we released Kifu, our first of our own publicly available commercial products. We also created and released several web applications for international clients and local partners, and really enjoyed creating several leading-edge in-house applications for our Hedge Fund clients. We look forward to helping our new Hedge Fund clients in the new year.

So join us, onwards and upwards into Noverse’s 4th year, 2013.

Thank You.

Follow the author as @hiltmon on Twitter or @hiltmon on App.Net.

Doing Software Demos Right

Over the past few years, I have been regularly demonstrating the huge complex end-to-end software platform that I developed in my last hedge fund. Before that, as a CTO, I sat through hundreds of software demonstrations.

If you have complex software that requires a demo, and if you are going to demo it, here are some software demo do’s and don’ts that I apply in my demos to others, and expect in demos to me


Do demo the software live, from your laptop, via projector so the potential clients all can see it. These days, all conference rooms have projectors, but bring your own just in case. Feel free to use remote access or a browser to connect to a running production system to demo it.

Do have a version of the product running on a Virtual Machine on your laptop in case the internet is spotty or unavailable. In fact, it’s preferable to do the demo off your VM unless your laptop is too slow. I run multiple SQL Servers, Web Servers and clients on VM’s in my demos, live!

Do tell a story, do make the demo enjoyable. Walk your potential customers through some applicable typical use cases or workflows that show off your software’s best features. Don’t just list all the features while pointing to their menus with a mouse.

Do demo the top ten (10) best features of the product, then stop. Don’t even try to show every feature. If you need to demo it, your software is already complex and has a lot of features. Tailor the demo to show the best ten features for that client.

Do demo using relevant data. Showing equity trades to a fixed income fund is a waste of everyone’s time. Using obviously fake data is also a big no-no.

Do allow the potential client to interrupt and ask questions. Do answer those questions and do demo the features that support your answers. Once the topic has been covered, take back control and move on to the next demo feature on your agenda. And do be flexible in changing the demo agenda to meet their needs.

Do a face-to-face demo if possible, else have a series of screencasts available for the client to see at their leisure. If your software requires a demo, it’s big and complex and expensive enough to afford the face-to-face. Don’t do a webex or tele-demo, you’ll never see the client’s reactions to your points; and you show them that you really don’t care enough to do a face-to-face and don’t expect to get their business anyway.

Do leave some collateral, a brochure or some screen shots. Don’t have your collateral hidden behind logins or email requests, that drives potential customers away.

Do point out what the software does not do. Not all products do everything, nor are they expected to. A good demo will show the best features of a product, but also leave the viewer with a feel for what it does not do.


Don’t come to a demo with a Powerpoint deck and no live software. It’s a software demo, show the software! I have sat in too many meetings that were supposed to be demos but landed up being slide decks only. If you only have a deck, it tells the potential client that you have no software, or that it does not work, or that you are embarrassed to show it off.

Don’t show more than five (5) slides before switching to the live software. Use the slides to give the 10,000ft overview, then dive in. I only use 1 slide in my demos, one! A single picture showing the overall architecture and components. Show any more than five and the viewer who came to see a demo will get bored.

Don’t read from a script, or worse, read the Powerpoint deck. Other people in the room can read the screen a lot faster than you can vocalize it. If you have a script, memorize it and be flexible enough to skip sections.

Don’t demo a beta if you can help it. Betas are usually incomplete, they crash and make you look bad. Demo the current production release. If you have to demo a beta, don’t hide the fact that its beta. I use a big red beta stamp on all beta screens when I demo.

Don’t get flustered if the demo gods decide this demo is the one that a new error or failure happens. Files get corrupt, data gets messed up between demos, odd things happen in VM’s. Deal with it and move on. But don’t ever walk into a demo knowing that the application will crash and try to avoid that area, chances are the next viewer will want to see that feature and you do need to demo it.

Don’t ever declare that functionality exists in a product unless you can show it there and then live. Failure to do so makes the viewer suspicious. If you say it exists, show it! Even if it’s not pretty.

Don’t make any promises on future features or capabilities. You are demoing the software as it is now, and the purchase decision is based on how it is now. Demo what you have, not what it could be.

Don’t ever walk in blind, not knowing who the potential client is or what they do and what they want to see. If you do that, you’ll demo the bits they are not interested in or bore them or waste time trying to find out their needs.

Don’t spend time booting up or setting up, have it all ready and running before you walk in. All modern laptops can sleep with applications running and return to the right state quickly when the screen is opened. The time spent booting, logging in, finding the files, launching the VM’s, connecting to the projector is time better spent introducing yourself, your software and getting to know the potential client.

Don’t have anything else running during the demo, and do have a clean desktop with a plain or logo background. Other applications and notifications and icons distract viewers and may interrupt the demo. One option is to have a special demo account on you laptop with only the slides and software VM’s and nothing else (and be logged in to it before you enter the room).

Great demos

Great demos happen when the potential client sees the live product in action, performing the tasks that they need for their businesses using data relevant to them. Great demos happen when the potential client starts asking questions, drilling down and walking down paths in the software that are not on the agenda.

Great demos tend to be interactive discussions around live software, not presentations.

I love doing great demos right, and I love seeing great demos done right. If the demo is done right, you’ll see the light come on in the potential customer’s eyes.

The Hedge Fund CTO Role

In this article, I intend to describe what a Chief Technology Officer does for an Asset Manager. Its not a comprehensive list, but will give you a feel for what I used to do in my previous jobs. I created this document as part of a presentation to a client and thought it may be useful to publish parts of it.

At a very high level, the CTO’s primary job is to make sure that the company’s technology strategy serves it’s business strategy. The company’s technology should enable the processes the company wants to implement, the company’s technology should enable growth and change, it should never inhibit the business, the company’s technology should automate where possible, and it should create opportunities for the business.

CTO’s therefore are responsible for creating options for the company. New technologies emerge all the time and the CTO should continuously review and evaluate these, their benefits, costs and risks and present these options to management. The CTO needs to look at the big picture and use these options to create, prepare and manage the technology strategy to maximize the use and alignment of technology with the business’s current needs, growth needs and change needs. This strategy may involve new platforms, new software development, upgrades or business process changes.

What’s becoming more common these days is the CTO’s new secondary role, to present the public face of technology for the company to investors, counterparties, vendors and regulatory groups. Ten years ago, CTO’s sat in corner offices and were never seen. Nowadays, CTO’s are called out during due diligence and investor reviews to work with the CFO, CCO, COO and Principals to answer questions and present on the company’s use of and controls in technology. CTO’s are involved with the CFO and COO in counterparty credit reviews to show how the company’s systems align. CTO’s are involved with the CFO in the regular audits to ensure that the systems comply and that the data needed by auditors is available. CTO’s are involved with the CCO in regulatory reviews to deliver data for reporting. And more and more, CTO’s are sent out to help market the firm.

CTO’s leverage technology to adapt, modify, replace, optimize and automate the workflows of the business. They actively seek out bottlenecks and stress points and apply technology to relieve them. In short, they are the chief firefighters and problem solvers in areas where technology can apply. They re-examine all business and data flows to ensure that they meet the current and future changing needs of the business. They ensure, using technology, that all processes, workflows and data are traceable, auditable, correct, subject to the appropriate controls, are secure, and will continue to work in a disaster situation to ensure business continuity. They track and manage errors and failure rates to identify new issues, new controls and better processes. CTO’s may strategize at the high level, but also apply themselves to the details and minutiae to solve problems and ensure all is well.

CTO’s also focus and manage the technical team, and grow these people into technical leaders. A technical leader is a technical person who understands the business so well that they can provide new ideas and opportunities as part of their day to day activities. CTO’s scope, plan, initiate (or reject) and manage all technology projects, and set the standards and tools to be used. CTO’s also have the problem of deciding which projects to execute given limited resources, deciding, with management buy-in, which projects to undertake and when. Some CTO’s even get their hands dirty and program.

CTO’s choose the company’s technologies, platforms and architecture. Since the CTO is closely involved in business processes design, and is aware of new and changing technologies, CTO’s recommend whether to buy software or platforms to improve these business processes, or build technology to do it, or leverage existing technology to do it. On a build decision, the CTO often designs the architecture and manages the project; on a buy decision, the CTO manages the vendor relationship and implementation process; and tests and validates the new technology before releasing it to the business.

More and more, CTO’s are being tasked with ensuring data consistency, accuracy, quality, correctness and timeliness. As the business grows and the number of systems grows, the number of integrations and interactions between systems, data sources and vendors, counterparties and third parties grows exponentially. The issue that emerges is that there is commonly no “one version of the truth” (See Hiltmonism - One version of the truth) for the data in an Asset Manager. This “one version of the truth” however is required for investor and regulatory reporting, as well as for quality, trusted internal reporting and risk management. CTO’s decide which integrations are needed, and which are not, which systems and data sets are ‘gold’ and which need to be integrated from the ‘gold’ source. They choose when to consolidate systems, when to reconcile systems and when to just drive one system from another.

CTO’s also

  • Plan and set the software development methodology used
  • Ensure data across all systems is comprehensive, is correct, can be trusted and grows to meet reporting needs
  • Track and manage all vendor relationships from systems vendors, network vendors, and phone vendors, scheduling and tracking their contracts, budgets and performance.
  • Track and manage all technology assets and licenses, plan replacements and upgrades and manage maintenance.
  • Works with the CCO to ensure network and system security and controls are active and effective.
  • Work with the management team to create, present and, where necessary, enforce technology policies relating to physical plant access, company assets, company data, internet access, remote access, mobile computing and “Bring Your Own Device”.
  • And a whole lot more.

The role of Chief Technology Officer in a Hedge Fund is a broad mix of business skills such as vision, strategy, leadership and coaching, mixed with a varied mix of technology skills, such as evaluation, architecture, development and testing, applied to the ongoing strategy and processes of the business. A good CTO provides technological opportunities to a Hedge Fund to improve differentiation, competitive edge, accuracy, growth and flexibility in a changing market and regulatory environment.

Note: Noverse LLC does provide outsourced CTO services to smaller and fast growing Hedge Funds that cannot afford a full time CTO or require quick access to CTO skills.

Kifu v1.0 Released

Noverse, via the The Shukai Company LLC, is very pleased to announce that Kifu v1.0.0 has shipped. And our first customers are already happily using Kifu in production. We want to thank all our beta testers and beta clients for testing Kifu and helping us make such a great product.

But we’re not stopping or even slowing down. We have the core platform, and we know it works. We also have many, many ideas and features we wish to add to help you maximize the value you get from Kifu in your small non-profit. We’re starting on the v1.1 tasks today, we have a v1.2 plan and lots, lots more to come.

Over the next few weeks, we’ll be bringing the remainder of our beta customers on board, and adding new customers that registered during the beta. We believe that it’s important to ensure that all new customers have a pleasant first experience with Kifu, so we’re doing the migrations for them first. Once that backlog is cleared, we’ll enable online sign-up for new clients.

If you have any questions, please do not hesitate to email us at or

Noverse LLC is a New York independent software designer and developer, established in 2010 by Hilton Lipschitz (@hiltmon) to craft brilliant web, iOS and Macintosh software. If you are looking for someone to craft a product as great as Kifu, feel free to contact me at