After a year of discussions, planning, designing, programming, testing and making it happen, we’re about to ship the 1.0 version of Kifu.

But almost shipping is not the same as shipping.

The product is feature complete for version 1.0. It was a hard road getting here, and even harder to say no to features that would have delayed shipping. But it’s done, its almost shipping.

Almost shipping are where you are when there are still hundreds of small and sometimes large details that need to be right before you truly ship a web app. Most are not code related. They include things like:

• Are the databases backed up, and can you restore from them if they fail.
• Do you have redundant servers, in different data centers, on different networks? And do they fail-over properly when one dies.
• Do you have a valid SSL certificate that works on all servers?
• Are all servers and the app properly secured? And up to date? And running only what you need?
• Are all assets served from a CDN? If not, why not?
• Are your billing systems in place? Can you see who has paid for the service? Can you account for all the business you will do?
• What about support? Do all the email addresses work? Is there someone who is monitoring them? Do you have a support web up?
• Can users sign up? Does the sign-up work? Does the subdomain generation work?
• Is the public web site visible? Is there news on it? Are all graphics and product descriptions up-to-date?
• Is your marketing plan in place? And being executed? Do people even know about your product?
• Are the logs rotated? And backed up? Does the server monitoring technology work?
• Can you scale? Can the application scale from single user-developer mode to thousands of users in public? Do you even know how to do that?

You can go from almost shipping to shipping without doing any of the above. But the experience of your first customers will suffer. We all remember the Twitter fail whale, and you still cannot get to your old tweets. We all remember the Tumblr downtimes. In those cases, they shipped before they were ready for the load.

So here we are, almost shipping Kifu, making sure that all the details are working, so our first customers have a great experience.

It’s an exciting moment, waiting to see if all the work done was worth it, whether customers will love the product as much as we do. It’s also the beginning, the beginning of running a business and managing a product. Oh, the design and development work will not end, there is so much to do in future versions. But soon, it’s going to be out there. In front of you. Being used. Being talked about.

We’re almost shipping Kifu and I cannot contain my excitement.

As my hiltmon.com blog takes off, I am starting to get emails from indie developers promoting their wares. This is great, I love getting them, looking at new products and helping out where I can. But many of them fail on the basics of presenting themselves as the professionals they are.

In this article, I will present a checklist of all the things you need as an indie to present yourself to strangers via email with some credibility.

Start with a Product or Service

You are what you do, not what you say. – C.G. Jung

The first thing we strangers want to know is what you do. If you make a product, we want to know all about the product. It needs a name, a one paragraph elevator pitch and a screenshot. That is what hooks us. Follow up with point-form details. Answer the question why I would want to use your product.

If it’s a service you offer, we want to know all about that too. Same deal, package it as a product. Give it a name, a one paragraph elevator pitch and follow with some great benefits of your service. Answer the question why I should want to use your service.

Present the pitch professionally, using good grammar, fonts and limited color. Then provide a link to your site for more information. Chances are, we’ll click it.

Have a Company or Trading Name

Who would you rather purchase something from: Hilton Lipschitz (that’s me) or Noverse LLC, A New York Company? The company, of course. A company name presents a professional image better than a personal name. If you have spent the money to establish a company, you are already telling people that you are serious.

Get your Company Domain Name

Having a company name is all good, but if your email comes from gmail.com or worse aol.com, you do not look professional. Hosting email on Google Apps is free, so there is no excuse not to do it.

Web Site

Run up a web site on your domain. If you make products, put them on the home page. If you provide services, put them there first. Don’t use a canned web site if you can help it, people are sick of seeing the same Wordpress or Tumblr sites.

Make sure that there are at least the following other pages:

• About: We want to know who you are, what your company does and why you set it up.
• Contact: Give us the ability to contact you via email, phone, twitter, etc. We may never use it, but its nice to know we can get in touch.
• News or Blog: Have an updated feed of news about your company, product or services. One thing that always looks unprofessional is if your web site looks abandoned.

In the case of Noverse.com, much of what I do unfortunately is not publicly available, or if it is, it’s under the banner of another company. That’s why I decided to put the blog front and center and make the Services and Portfolio links be the first two at the top. The Hire Us link comes next, because it gets people to contact us.

Blog

We’re indies, we’re a community. We’re all learning, making mistakes and gaining experience. One of the great thing about indies is that we also share our knowledge and experiences with each other, through blogs and tweets. You may not think it, but your trials and tribulations, your failures and successes when shared help us all. So create a blog. If you write about your products and services, put it on your company web site, if you write about your passions or hobbies, create a personal blog.

Blogging not only tells us that you are still in the game, it also creates your voice, your personality, your image on the web. Your company may change, but you remain the same. People will remember you as you chop and change, having a consistent blog will help people move with you.

Do Support Right

Many indies focus on product, then on marketing and forget about the most important people they do business with, their existing customers. These people have already paid you money, use your product or have benefitted from your services. They deserve the best royal treatment. They also happen to be the best pool of people to spread the word about you, your company and your product.

So do support right. Have a prominent support link on your page, establish a support email address or use a third party site like fogbugz or desk.com to manage the process. Make sure you respond to every email and support call promptly and clearly.

One of the first things I look for when I see a new indie site is whether there is a support link or not.

The Social Thing

Grab your company and product name in all the social networks (if you can). Tweet your new articles and product releases. Share them on LinkedIN, Google+ and anything else that matters. You may not start out with many followers, but you need to build the history.

One thing I do is use twitter lists to monitor indie twitter accounts. These tweets do not appear in may main timeline (it’s busy enough) but I get to look at them at least once a day to keep up.

Why wait?

Get started now, register your company, grab a domain, setup your email and write your “Hello World” first blog post. Then share it with all of us.

Noverse is sad to announce that we have taken down Emergency List and Sights to See from the iPhone App Store.

What? Really? Why?

• These apps were developed two years ago, for old versions of the iPhone, and no longer represent the best we can do. We were learning iOS at the time, did not have access to the right designers and did the best we could back then. It got us the business we did the last 2 years. But they are not good enough to keep alive.
• They were not selling. We had ~4,600 downloads of Emergency List and about 50 sales of Sights to See over 2 years! Neither were volume sellers, nor profitable in any way.
• The app store itself it getting overcrowded. We don’t want to add to this overcrowding with our early apps. We would rather spend our time focussing on a few new products (including iOS) and have a small set of awesome apps in the store instead.
• We’re not motivated to enhance or maintain them anymore, again, because there are too few customers. If we were, we’d rewrite and redesign them as we know so much better now.

To our Existing Customers

The Sights to See server services will continue running, however we will no longer be adding or updating the data.

The applications will continue running on your iPhones, but make sure to back them up, because you will no longer be able to re-download them from the app store.

If you have any questions or comments, send us an email to comments (at) noverse (dot) com.

You may have noticed less activity on this site. Or not. I have consolidated all my old blogs, and begun writing a more controversial and wide ranging blog at my personal domain http://www.hiltmon.com. Expect that one to get new articles more frequently and on a wider range of subjects. I am not sure what to do about this blog yet, so I’ll leave it up for now. But check out http://www.hiltmon.com for all the new and more interesting stuff.

When it comes to software, there should be no such thing as ‘good enough’ software. Yet most software fits this bill, it does something ‘good enough’ to get the work done or even sell. Even though the user has to jump through hoops to do so, or create workarounds to make the whole thing work.

At Noverse, we don’t make ‘good enough’ software. Our products must be brilliant, they must be flexible, they must be proven correct, they must get the job done without workarounds, they must be fast and easy to use, they must be amazing.

So how do we do this? We have a process, a set of software quality levels that must all be achieved, and we follow this process every time

Get it Designed

Get it Architected

Get it Working

Get it Right

Get it Fast

Get it Intuitive

Get it Out

Lets walk through each level

Get it Designed

When it comes to software, most scribble a list of requirements and start programming, spitting out classes and racing ahead.

Programming is not good enough!

Before we even start on any software project, we design. In order to design, we need to understand the needs and the flows that the software must implement. We need to understand what needs to be done, why it must happen, how it is being done and when it gets done.

And then we design. We design a better what, we examine all the why’s to see if they should be done, we find better ways to do the how’s and we look to see if we can make the when’s happen faster.

And then we design some more. We design a better workflow, we design out steps that are unnecessary and design in automations, we design in flexibility and scaleability.

Get it Architected

Designed is not good enough!

A good design will only hold together if it is properly architected. We choose and plan the structure of the programs and components to ensure that they will all work together, that they can be maintained and scaled, and that we can build and test them independently. We architect in the ability to flex the design, to maintain the software later and to even switch out components.

There are always things that are unknown at the start of a project. Will this algorithm work? Can these components interact? Can this library handle the volume? Before we start banging out classes, we identify the unknowns and create spike solutions to test them. If the spikes work, we know the architecture will hold. If they do not, we get the chance to find better solutions before we are too far down the development path.

Get it Working

Architected is not good enough!

All code we write must compile. It seems obvious to say this, but its not uncommon for others to work on code-bases that do not compile for days on end, hoping to get to a compilable state. Our code must always compile. But that does not mean it works.

All code we write must pass tests. Not only must it pass tests for success, but also pass tests for failure and where necessary, tests for stress. If code passes all the tests we can think of, we know it works. If we change the code and the tests still pass, we know it works.

And we release early and often. Daily if we can. Which means we expose our customers to changes in the software as it happens. And its pretty embarrassing to release non-functional software when the customer is watching.

Get it Right

Working is not good enough!

Our software must also be right. All calculations, all validations, all algorithms, all integrations, all formats, all reports, all deliverables must be right.

How do we know if it is right? We check. And re-check. We compare the results of our calculations with other systems, we compare our results with the manual processes we are replacing, we compare our outputs with external parties, we compare our results with the design and we embed these comparisons in even more tests.

We are rigorous about this, but this rigor pays off in being able to trust our software. If we see a number on the screen, we know that number is good.

Get it Fast

But right is not good enough!

Our software must also be fast. It’s no good if our software gets a calculation right if it takes too long to calculate it. It’s no good if our software executes a workflow impeccably but takes so long that it was easier to do the same flow manually.

Our users want an instant response wherever possible, that is why they are investing in software. Our users want to get more done in the same time with the same or fewer resources. And our users will not use nor enjoy the experience of using slow software.

Get it Intuitive

But fast is still not good enough!

Software that creates the right outputs quickly but is hard to use is just as likely not to get used and to create user frustration.

Our software has to be easy to use, and to be easy to be used by our target market. What’s easy to use as programmers is not the same as easy to use by retired people.

So we make our software simple. Making simple is hard, but it makes it easier to write and easier to use, and importantly, also easier to learn. We make it intuitive, using the language and norms and flows that are familiar to our users. And we make it focussed, taking away distractions, extraneous choices and processes that have to be remembered by our users.

And we try so very hard to make the software state clear, so that after every interruption by the real world, our users can quickly remember ‘where was I and what was I doing’ by glancing at the screen.

Get it Out

But intuitive is still not good enough!

We get it out. Releasing early, releasing often. As soon as the customer, the user and anyone else for that matter starts playing with the software, we get feedback. We quickly learn where our design assumptions were maybe off base, or where our flows can be improved, or where there are ways to make the software better by watching how they interact with it.

By getting it out, we catch errors and misunderstandings early enough. By getting it out, our customers and users become part of the development process. By getting it out, and by listening to and watching our users, we get to become better programmers and make better software.

And we ship. We finish the product. We get the final product out into the client or into the market. Until we ship, our software is not good enough. Until the customer and our users say so, our software is not good enough.

The Process

So next time you need software, follow the process to get brilliant software, until then its just not ‘good enough’.

Get it Designed

Get it Architected

Get it Working

Get it Right

Get it Fast

Get it Intuitive

Get it Out

Everybody talks about Beta testing, unit testing and integration testing, but there is little on Alpha testing out there. At Noverse, we do them all.

What is Alpha Testing?

If you follow the Wikipedia definition, Alpha testing happens when the product is incomplete and yet still handed over to a testing team inside the organization. And Beta testing happens when the customer gets to test pre-release versions.

For us, a small indie developer, we have no separate testing or Q&A team, so our Alpha testing is done with our customers as well.

How do we run it?

We follow the agile software practice of release early, release often. As soon as we have sufficient framework to run the application and as soon as the first features emerge, we release the product for Alpha testing to our customers.

We tell our customers what we are doing and what to expect. Incomplete software, workflows that only have the first steps, links that go nowhere, forms that do not save data and buggy software are all part of Alpha testing.

Every time a feature is added or completed, and its automated test components added, we issue a new Alpha release. We email and publish release notes to point out what’s new and needs to be looked at. And we solicit feedback on it.

Why do we do it?

Alpha testing is as much about testing as it is about feedback. With ‘release early, release often’, the goal is to bring the customer deep into the process of development and to give them a platform to comment and feedback upon. For customers, having an incomplete process or half-done screen to point at and prod makes all the difference in being able to communicate with us Vulcan developers.

By calling it testing, we give more and we get more back. We start to track feedback as bugs, and document the fixes and changes in source code control and in tests. We solicit feature requests and changes earlier in the development process so we can plan future work and directions better. And we provide the tools and practice to our customers to look at the application closely and critically, enabling them to provide better and more meaningful feedback.

I always say that the best response we get from our customers on each Alpha release is “This is great, where’s the next step”. But the truth is that the best responses we get are clarifications on our misunderstanding of the needs or flow, changes in terminology or naming, or the identification of new and unique bugs that we did not see so early in the process that they are easy to address before they become structural.

What do our customers think?

Most customers feel pressure when it comes time to test. They have no experience with testing or accepting software, know not where to start or what to do. With Alpha testing it’s a lot easier on them. There are fewer features to play with, fewer screens to look at, and the release notes guide them where to play next.

And they love it. They jump on each release, work their way through the flow to the new features, poke and prod at them, ask questions of us and give us awesome feedback.

And when it comes time to move on to Beta testing, they are already familiar with the product, with testing, with reporting bugs and requesting features. Nothing to fear here.

Right now

Over the last 10 days, I have published the first 3 Alpha releases of our new product to the team. And they are happily going at it, finding features, discussing flows, thinking about naming and asking where the next feature is. As it should be.

So in your next project, instead of waiting until you think you have a full, bug-free and complete product, try Alpha testing. Send out the screens and flows as you develop them, the incomplete and unstable, your customers will be more involved, will learn to test better and you will get better feedback. And build a better product.

The early stages of a software development project are brilliant for a designer/developer and painful for a customer. For the developer, the challenge of design, the joy of programming the core functionality, and the absolute bliss you get from making something great keeps the developer engaged. The customer sits and waits. And waits.

Traditionally, that wait lasts a long time, all the way until Alpha builds are available. Even with agile programming techniques, there really isn’t much to show the customer during the early stages. Even in iPhone development, you rarely send out builds until late-Alpha stage. And it’s hard for customers to remain excited and engaged when they cannot see, touch and feel the product.

A lot of developers, including myself, alleviate the customer’s boredom with weekly project status reports. We write about all the new features we added this week, the design changes applied, the bugs wrestled and defeated, and all the other things we developers find exciting. To customers, it’s just a pile of text that means very little to them. Oh they do read it, and they do discuss it. But, its just text.

What is needed is ‘Show and Tell’, not just ‘Tell’.

To create the ‘Show’ we invested in ScreenFlow, a screencasting application. Not only do we send the weekly report, but we also regularly attach a screencast showing the application in action in the development environment. We show the new features, we run the workflows, we point out the changes made, we show the bugs that have been squashed.

And customers love it. They watch each screencast several times, they call up to discuss scenes and things they saw on the screen, they give feedback, question decisions, and get heavily engaged in the product development. They show the screencasts to their colleagues, showing off their proud new software as it grows. They keep the screencasts long after the application has been delivered to show others how the application evolved.

Screencasts also help when trying to explain a feature. We’ll often create a single scene video and send it out to help clarify a point or to explain our thinking. If the customer can see what’s happening, they find it easier to understand it, discuss it, question it and provide feedback on it.

It does take you away from developing to create these. But with practice, and the fact that we’re not making a Hollywood production, we have managed to get the production down to a few easy steps:

• Create a point form list of features to show. Its easy, since this already exists in the status report.
• Use Screenflow to capture the a scene for selected key points.
• Use Photoshop to create the static pages, like the introduction slides, scene breaks and the end credits. This is easy since we have a template, so we just change a few words and export to PNG, change a few more words, export again.
• Assemble the scenes and images in Screenflow, and add a few transitions, to produce the initial movie.
• Load the movie into a new Garageband podcast project and record the voice-over (We do it in one take - remember, not Hollywood), add a few zingers, and we’re done.

Up until the moment you can hand over the first build of the application for the customer to play with, sending them screencasts is the next best thing. They can see the product, see how it looks and works, show it off and be part of the evolution of their software. They can save the video to review later.

An engaged customer is a happy customer. An engaged customer makes us better designers and developers. An engaged customer leads to a better product.

So next time you write a boring project status report, make a quick video as well.

You’re welcome.

Call in a contractor to fix a hole in your roof. On a fixed price contract, they will rush to the roof, staple a plastic sheet over the hole and be done in 10 minutes. On a time and materials contract, they will wait for permission to go onto the roof, and sit up there for hours texting their mates, then staple the plastic sheet. On an equity share contract, they will move in, and place a bucket under the hole.

Noverse LLC always uses Time and Materials Contracts for engagements, never fixed price or equity share agreements. So why is that?

Why Contracts?

Seems like a silly question, but many, many indie businesses do work to a verbal agreement or handshake. And both parties usually get screwed. The client often feels that they did not get the work they asked for, or it took too long and should not pay (nor do they have to), and the indie feels they did do the work and should get paid (whether or not they deserve to). There is disagreement on rates, payment schedules, deliverables, timing, you name it. Since no contract is in place, both parties are aggrieved, but there is no solution.

At Noverse, we love our clients and we love our contracts. This is a business after all, and the contract ensures that both parties, us and our clients, know exactly what the business is, what payments are agreed, what deliverables are acceptable, what timeframes are due and what do do if things go wrong. With a contract in place, we can all get onto the real fun stuff like actually designing, developing and delivering awesome software together. With a contract in place, everyone knows the what, the when, the who and the how of the engagement.

Why Fixed Price

Fixed price contracts are those where an agreement is reached for a stated set of deliverables for a single given invariant price. Fixed price contracts often include payment schedules, time limits and strongly worded penalty clauses.

Fixed price contracts are great when the deliverables are well known and understood, where the service has been done before and where the supplier and client are both confident that it is achievable. Fixed price works great installing swimming pools, where the supplier has installed hundreds and knows the work involved because they have done it before repeatedly. Fixed price works great when the supplier is delivering a manufactured item, like airplanes or other machinery, or performing a service with known parameters like mowing the lawn every week, or when the supplier can provide the same service or product to multiple clients without changing the service or product.

Fixed price fails when there is design, creativity or a lack of clarity in the deliverables. No one knows how long it will take to design a new advertising campaign, or create a web site where the content has yet to be defined. Fixed price fails when the scope of work is unclear, such as when asking an architect to design a building or asking a research team to come up with a new medicine.  And fixed price fails when the process requires iteration, which is why contract lawyers never use fixed price to handle negotiations.

Fixed price is generally good for the client, especially if they can nail down the deliverables clearly. The client gets a predictable product or service for a known price in a known timeframe.  It’s not always good for the supplier if high client involvement is required as the client is not incentivized to achieve the same timeframe.

Why Equity Share

Equity share contracts are those where an agreement is reached for a stated set of deliverables in return for an equity stake in a company instead of payment.  This is common in startups and in single purpose businesses (companies created for a single engagement).  The client does not have to fund the product or service and the supplier gets a share in the long term income of the startup or completion income for the business.  This works great if the startup is successful.  This works great of the single purpose business wins the deal.

But most of these deals fail.  Startups are invariably not successful.  For each success we hear of, there are hundreds if not thousands of failures.  Single purpose businesses, like startups, rarely make money, but when they do, they do well.  Since the client does not have to fund the work, it’s good for them.  Since the supplier is carrying the risk of no return in the deal, its usually bad for them.

Why Time and Materials

Time and materials contracts are those where an agreement is reached for a stated set of deliverables while reimbursing the supplier for their fixed and variable costs with a markup.  These contracts are great where fixed price contracts are terrible.  Contracts to create new products, design new things, do stuff that has never been done before, or even just see if something can be done, are perfect candidates for time and materials.  The deliverables might be known, but the time and effort required to achieve those deliverables are unknown.

This is not as good for the client.  At the start, they have no idea what the total contract cost will be, and it sure is hard to get budget for a variable contract.  The client also has to trust the supplier not to waste their time and money when, technically, there is no incentive for the supplier to work quickly or efficiently.  Its good for the supplier as they can work without pressure, iterate and spend whatever time they need to get the deliverables done to client satisfaction.  Of course, a lazy supplier still gets paid under this contract (although they will never get another contract with the same client).

Noverse does time and materials contracts because we never know the true scope of work.  Oh sure we know what the end deliverables should be, but how to get there is usually unclear.  Software design is a learning experience for both us and the client, and there is no way to know how long for sure it will take to do it properly.  Software development is also unpredictable, no way to know what problems and issues will arise.  And invariably, the client environment is not static, their needs do change as they learn more, as their business evolves and as the software starts taking shape.

How we make Time and Materials palatable

Since time and materials contracts are generally supplier (that’s us) friendly, here are the things we do at Noverse to make sure that these engagements do not get away from us and end up costing our clients more money.

• We start with a Statement of Work, that expressly defines the deliverables and limits the scope of work.  We agree up front, and attach to the contract, what the deliverables will be.  This limits the scope of the engagement to achieving those deliverables and nothing else.  Often, our Statements of Work also state things that may be assumed deliverables and explicitly remove them from scope.  This protects the client in that they will only be spending money on us delivering that which they want us to deliver.
• Then we make an estimate.  Its a guess in many respects, but the best we can at the start.  That estimate is used as a basis for the engagement time and payment schedules.  And we apply ourselves as if that estimate was a fixed price agreement.  We report weekly on time consumed against estimate, trying to match or beat the estimate.  We continually retune our work and focus to get back on track.  Clients like this as they have set their expectations on the estimate and we are continually trying to beat those expectations.
• Release early and release often.  Sometimes daily.  As each new module grows, Noverse releases it to the client.  This is great for the client because they have something to play with, something to discuss and they can objectively watch our progress.  This is great for us because we get feedback early when its easy to change and fix things, and it keeps our clients very involved in our work.  It also helps in cases where we have misunderstandings in functionality or direction as these are made apparent early and are fixed early, enabling us all to remain on track.  The best response from our clients on a release: “This is great, where’s the next bit”.
• Spike the critical areas.  One of the things we do early in an engagement is try to identify the areas where we have the least understanding or perceive the most risk in implementing.  Maybe there is an interface we are unsure about, or a calculation that we’re not sure what it should be or how it works, or a data set that may not be clear. In these cases we start with a few spike solutions to implement those problem areas. We’ll write a small program to do that interface, implement that algorithm or load that data set.  In doing this, we spend a little more time at the start of the engagement tackling the big and nasty problems.  This is good for us as once the nasty problems are solved, the rest of the delivery is easy (usually).  This is great for our clients because any issues and clarifications are dealt with early, and any changes are identified early.
• Value and manage change. We’re all learning as we design a product, as we develop a product, as as the client gets their hands on the growing product.  And as we learn, so the scope and nature of the deliverables changes.  Sometimes this makes the engagement longer and cost more, sometimes less.  Since we have an estimate, Noverse ensures that all changes are reported and the estimate is continually updated to reflect the new changes.  That way, clients are happy because the variation is known and agreed, and expectations are adjusted.
• We sometimes say no.  That’s right, we say no to implementing features we believe are unnecessary, we say no to designing and developing modules that are not needed.  Noverse has the same passion to create a great solution for the client as the client does, and we apply all our knowledge and experience to achieve that goal.  But many clients add features (and therefore time and cost) to engagements when these features are not needed.  Noverse advises our clients when we think these are extra’s, bells and whistles, or unnecessary features.  The first time it happens, the client is shocked and surprised.  But after that, we always get appreciation.  And it helps us both rein in time and materials contracts.

So next time you are offered a time and materials contract, look at the process.  Look at how the supplier tries to make it work for you.  Look at how transparent the supplier is. Time and materials contracts, coupled with a great process, are the best solution to independent software design and development for both clients and indies, and thats why we do it at Noverse.

One of the biggest things missing in the iTunes App Store is the ability for the developer of an app to respond to complaints raised in the reviews section of their app.

We all know that the purpose of a review is to document an honest experience with a product. We all also should know that every app on the store has a support link, where customers are supposed to go to report any issues, errors or problems, or to ask questions of the developer.

In reality, customers don’t deal with support, they document issues as reviews on the App Store. And potential customers who read these reviews assume the app does not work, or is fatally flawed, or that the issue has not been dealt with, and do not purchase the application.

Reviews are a one way street in communication, customer to public. There is no way for the developer to respond that the issue may have been temporary, or that a server-side fix has been implemented or that the next version has been submitted that corrects this issue.

I know Apple ‘clears’ out reviews for each version release in a half-hearted attempt to sweep this under the version number carpet. I also know that several developers change their description top-lines to respond to reviews, but that usually puts potential customers off as they read about bug fixes first and not about the product.

So I ask, Apple, please add a feature that allows the developer, and only the developer, to kindly respond to the customer that they have heard their complaint, and are working diligently to fix it.

And if you are worried that some developers may abuse this feature, feel free to provide only a limited set of canned responses (We’re looking at it, fix is on the way, …) and a generous thank you to the customer for reporting the issue.

One of the most common scenarios I see is companies using Excel to run their core business. Whenever a new report is needed, new analysis, new form, data conversion, no matter the task, they turn to Excel. They make everything look like a nail, and the only tool they understand is Excel, so they use it like a hammer. The result? Manual processes, inconsistent data, key-person dependencies, inflexibility, pain and suffering. They call Noverse LLC in, but fear using other platforms, because they only know Excel. There is hope.

I write a lot of software for hedge funds and other corporate clients. Whenever I design a new piece of software, I also recommend which tools I prefer to use for that project. No matter what I recommend, the client always rejects it in favor of the tools they know.

If they cannot get it in Excel (and we do not offer Excel), then it’s C#, SQL Server, always on Windows.

Their reasoning makes sense. They usually have a small IT staff, they are calling Noverse LLC in because they do not have the time or skills to get something done, and they have to maintain it later. They know C#, they know SQL Server and they know Windows. And when they do need to grow their IT team, they can easily hire single-skill workers, who are easy to find, reasonable cheap and easy to hire.

It’s not a Nail

I, on the other hand, believe this is the incorrect approach. Each task is possibly quite different, requiring the right tools. I believe companies should embrace new platforms, tools and technologies. And here is why.

Speed of Development: It can be written faster. C and C++ are great for compute intensive tasks. Javascript is great for in-browser scripting. Ruby, Python and Perl are excellent for file manipulation and delivery. You can use C# or Java for all of the above, but it takes longer to write than using others (except may be C), is usually less maintainable because the code size is so much greater and getting the architecture right is that much harder. Since programmers are almost always under deadline, using the right language for the right the component can get it done quicker. And on modern operating systems and processors, the execution performance difference is negligible. In one of my previous funds, we replaced a huge amount of manual work and integrated the processing in a risk management system with a bunch of Perl scripts. They had tried to do it on C++ and failed.

Better Programmers: It can be written better. A programmer who knows more than one programming language, who is skilled in several scripting technologies and main-line languages is, by definition, a better programmer. They have a larger set of programming patterns to design and develop from, a wider range of skills that can be employed and know a wider range of libraries to improve their deliverables. Knowing multiple platforms enables the programmer to understand the strengths and weaknesses of different platforms, choose the right platform for each job, and maintain a wider range of systems. It makes them more productive and more valuable.

Better Flexibility: It can be easier to change. Business changes every day. Your company needs to be nimble and respond quickly, or opportunities may pass you by. In the hedge fund game, it is not unusual for IT to tell the business it will take weeks to add a new interface or process a new data set. In reality, it’s the tools they use that limit them. In a previous fund, I used Perl to write all file moves and transforms, which enabled a single programmer to part-time add, maintain and change all our file and data processes, with turnaround times in the hours, not weeks. In a later fund, I did use C#, but to create a meta-data driven file fetch and transform process (instead of writing each file transfer and processor individually), which made us even more nimble and flexible.

Platform Cost: It can be cheaper. Windows costs money, SQL Server costs more, even the C# developer tools cost money. Linux? Free. MySQL? Free. Ruby on Rails? Free. No matter what Gartner and CIO Magazine say, open source is cheaper to buy, cheaper to run and cheaper to maintain. Even more extreme, I ran Macintoshes at my last hedge fund and they were net cheaper than their Windows counterparts, even though the hardware was beefier and more expensive up front. If you need to go compute intensive, or large memory, or run lots of threads, look away from Windows. MySQL is blitzing fast for small to medium sized databases, and free. High performance web services look the same from the client whether written in Ruby on Rails or ASPX.

Security Infrastructure: It can be more secure. Based on empirical evidence, what is more secure, IIS on Windows or Apache on Linux? Answer: Apache has more documented vulnerabilities, but is way more secure. Yet most companies remain on the Windows monoculture. I have noticed a trend in the super-large companies moving away from Windows, but they still remain stuck on Java. If you are going to have a public facing server, and do not want load up on firewalls, intrusion detection systems and funky router configurations, why not use a Linux server out there.

Scaleability and Load: It can handle it. A common argument against using the newer scripting technologies or platforms is that they do not scale, they can’t handle the volume and stresses of a true corporate data workload. Rubbish! Apache runs the largest and busiest web sites on the planet. Ruby on Rails runs Twitter. PHP is Wordpress. In terms of platform maturity, C# and Ruby are about the same age, as is JavaScript to Java, and both Python and JavaScript are more ubiquitous.

Support: It will stick around. The final argument against using non-Microsoft or non-Oracle (Java) platforms is that companies are afraid that the platform they choose will not be supported, what if something goes wrong. Well, Red Hat makes a supported Linux, Apple makes a supported Unix (OS X is an excellent Unix), and both support the open source components on their platforms. Oracle offers a supported MySQL. Open source software is supported by the community, there are thousands of people out there finding and fixing bugs, documenting workarounds and patches, and improving these platforms. And there are some serious players, like IBM and Facebook, depending on these technologies, they will not let them fall.

Use the right Tool

In my experience, about half of corporate computing is moving and transforming data around, between systems, between companies, and the rest is actual computation, reporting and email. If you wrote the moving and transforming half in a scripting language, you would get it up and running quicker, it’s easier to maintain, and easy to change. Do it in C# or Java, it will take longer, require more architecture and become inflexible.

So consider, on your next project, the opportunity to use a different tool or platform. Learn it, study its benefits and weaknesses, grow your skills, improve your flexibility. It will make your business more flexible, responsive and dynamic.