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:
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.
]]>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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
]]>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.
]]>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
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
]]>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:
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?
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.
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.
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.
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.
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.
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.
]]>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.
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.
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.
]]>Lets look at each in turn.
This is actually the easiest for us to do. All we have to focus on is to write the software. It is up to the customer to get the right equipment, integrate it into their network, install any prerequisites we ask for and to support and maintain this hardware. We can then come in, install our code and we’re done.
Choose this model when the software is complex, uses prerequisites that the customer’s IT team can handle and when the software needs a ton of iron to run.
This is a great solution. Apple’s Mac Mini Server configuration is awesome. A Unix operating system, open source server components fully integrated and working on a tiny device that does not need a computer room to run. We could set up the application on it, ship the Mini, and all the Customer has to do is plug it in, plug in the LAN and turn it on (and install any client software to talk to our server).
Choose this option if your platform is not one that the customer IT people understand, when they have no IT staff and when you need a really rich environment.
We setup servers and install our software, making the servers available over the internet to our customers. We could colocate our own hardware or use a RackSpace, Linode, Heroku or SliceHost to do it dynamically. All the customer has to do is access our software as a web application.
Choose this option when you expect to have a lot of small customers, when the software is simple or when you want to reach the world.
Most of our customers for this product will be small organizations that do not have IT teams. Hosted is the best solution for them, so that’s what we’ll do. We will need to make the solution very simple and user friendly to make their user’s comfortable in the browser.
Not the bloody ‘Cloud’! Note that I have not used the dreaded ‘cloud’ word above. I’m an experienced and professional systems designer and I have no idea what this mystery ‘cloud’ thing is. I assume its the icon used in network diagrams to represent the Internet. I do know about virtual servers, hosting and colocation. I work in the real world. We’ll use those.
]]>A software designer is an individual who has the vision, passion, communication, understanding, flexibility and process to generate software form; and make the necessary decisions about what, when, where and how in development.
Note that the designer does not necessarily conceptualize the idea. They may do so, in which case they will be designing their own product, much like Indies do. More likely, a client has an idea, and the designer analyzes it, visualizes it and communicates it within a development project.
There are really two things at work here, vision and visualization.
Designers need vision to see whether an idea has merit, whether it’s worth doing or not, and how best to do it. They need take the idea and envision the benefits, usability, popularity, feature set, plan and solutions to come, choose a path and set clear product objectives.
Designers also need to visualize it. A great designer can see the final product in their heads before the first line of code is written. They can see components, structures, themes, and processes; they can see the software running before it exists. If they can visualize it, they can design it. Visualization takes iteration and process to clarify the vision.
Design is not easy. Its iterative, hard work and for many, emotionally difficult. Its easy to stop after a few iterations, avoid the grind or just give up. Good software designers have such a passion for the software that they will iterate again and again until they are satisfied, grind until their backs break and keep on going. It takes passion to completely design a product to pixel perfect looks, perfect functional mix, intuitive flows and rock solid engineering.
It’s no good if the design is locked up in the designers mind. No matter how awesome it is, unless the designer can communicate all aspects of the design to the various teams, it will not be developed. They need to communicate the desired look and feel to the graphic designers, they need to communicate the feature set to stakeholders, users and customers, they need to communicate the architecture and components to developers. They need to speak graphic, business and tech clearly to get it developed right.
Great designers do not design alone. They work with artistic graphic and interface designers, they commune with systems and software craftspeople, they debate with experts in whatever fields impact the idea, and consult with stakeholders, users and customers. With each they need to listen, learn and communicate in order to crystalize the design.
In order to design a great product, the designer needs to have a deep understanding of the idea. They need to feel the flows, get intimate with users and customers, spot the challenges, drill on the details, and most importantly be clear on all aspects of the idea. This clarity will lead to great architectures, simple workflows, great user experience, proper function mix, all in all, a great design.
A great way for a designer to project this clarity is to walk the idea back to the idea’s originator, to present their understanding and to resolve any misunderstandings early.
Good software designs change, great software designs are flexible. As the designer analyzes the idea further, better flows emerge, and these should be communicated. As the designer iterates with the graphics team, the theme of the software will change and evolve. As the designer constructs the architecture, it too evolves. Great designers use these evolutions to improve their designs, learning the lessons from previous evolutions and integrating the ideas and feedback of others.
And if an unbeatable challenge presents, designers need to find a better design, a novel solution or rework the existing design to eliminate the barrier.
Design is all about art and craft but its also about process. Evaluation, combination, evolution and generation are all iterative processes. It takes process to completely evaluate the idea, to combine the input of others and the lessons learned, to evolve and iterate a design and to generate the final product.
It takes process to explore design ideas to see if they are workable, it takes process to build platform and architectural models, it takes process to determine optimal flows. Great software designers understand these processes and work them hard to complete designs. And they also know when to finish the process.
All the vision, passion, communication, understanding, flexibility and process will not lead to a great product unless the designer can and does make decisions. They need to decide on workflows and functionality so they can focus on more detailed design. They need to decide which features to include, what platform to use, which architecture is best, implementation priorities, standards, usability and interface so the developers can get going. They need to decide on theme, GUI, colors and image so the graphic designers can complete their work.
And as issues and challenges arise, as things change, and they always do, designers need to keep making decisions to keep the product development on track.
Many of these decisions are and should be those of the designer, and many are those that need to be made in consultation with others. Flows and functionality decisions need to be made with the client and stakeholders, platform and architecture decisions with the project manager and programmers, look and feel with the graphic designers. Good software designers enjoy regular consultation with all parties involved and make timely, clear decisions.
Software design is often lacking, which is why most software is unwieldy, nonintuitive, bloated and unpleasant to use. That’s because most software is either insufficiently designed, or designed by committee.
Insufficient design comes from skipping design process steps, not looking at workflow, ignoring usability, picking a preferred platform instead of the right one, using the same old architecture instead of designing the right one, and ignoring graphic design outright. It comes from using programmers who have only one platform and language skill to come up with the design, from using business analysts who have no technical skills to write designs, from using project managers with no aesthetic skills to create strategies. Look at the corporate software in front of you next time you are at work, and you’ll see what I mean.
Design by committee is even worse, and just as common. The committee meets to choose functionality, flow, platform, just like a software designer would, but contains as many different visions and understandings as there are members. Combining these disparate visions and understandings leads to compromises and compromised design. And invariably, not all committee members are happy. Passionate members push the others to accept their design forms, practical members push theirs, and uncaring members hold to their favorite tools. The result is often a confusing, incoherent design that is barely communicable and each part of the project runs off on it own.
In the real world, there are many examples of this. Microsoft Windows is the ultimate example, for example the Off switch in Vista (and 7). There are nine of them! Moishe Lettvin describes here how it came to be, up to 43 people were involved! Michael Arrington raves on that Digg’s redesign was done by the largest committee.
He also gives the best example of great design, the iPhone.
“Product should be a dictatorship. Not consensus driven. There are casualties. Hurt feelings. Angry users. But all of those things are necessary if you’re going to create something unique. The iPhone is clearly a vision of a single core team, or maybe even one man.”
That one man is not necessarily Steve Jobs, he has ensured that each software team at Apple has a single fully authorized software designer and decision maker, and he handles the decisions that operate across teams.
Whether you have an idea for a single function widget, an internal corporate system, a consumer application or a massive multinational’s mission critical system, you need a great designer. Someone to create the product vision, has the passion to drive it home, can communicate it to all involved, understands all the niggly details, has a process to iterate and evolve the best design, and can make the hard decisions to create the perfect software form. Then hold on to the designer throughout the development process, to guide the stakeholders, artists and programmers to produce the best software and to correct the design’s course when things change.
]]>With apologies to the movie A Few Good Men, 1992, directed by Rob Reiner.
How many people does it take to develop a Software Product? How big a team will I need to create to tools for my business? I need to migrate this legacy software to a new platform, how many programmers will I need?
These are common questions asked of CTO’s, IT Consultants, startups, techies and, of course, me. Depending on who you ask, you’ll get a different answer. Here’s mine, and why.
Build a small team of smart people, point them in the direction you want and let them loose. They will deliver beyond your expectations.
Lets compare three team sizes, the one man band, the massive outsourced team and A Few Good Men.
Definition: Jackaroo - Jack of all Trades, Master of None.
The Jackaroo is a single developer who does it all. A lot of Indie Developers, like myself, seem to be Jackaroos, but not all of us are. A lot of contract programmers are.
The Jackaroo does it all, they design the software, write it, test it, and deploy it. Great Jackaroos produce great products. But they are rare. Good Jackaroos often focus tightly on a market segment or technology and successful Jackaroos will have special expertise in your business area.
Jackaroos are cheap (there is only one person to pay), fast and focussed. Jackaroos are flexible, jumping from component to component, from programming to support to design like trapeze artists. They provide personal service, which is rare in this day and age, and are measured by their individual professionalism, track record and product history.
For small, quick, simple software, the Jackaroo excels.
But…
A Jackaroo cannot be great at everything involved in software development. Their development style, programming patterns and architecture may not be conducive to later maintenance and modification. They may program well, but do artwork badly. They may not be the best managers of time, or the best communicators.
And since a Jackaroo cannot have expertise in all areas, they will struggle in areas they are not good in, take more time because of it and deliver lower quality results. Over and above the limits of a Jackaroo’s expertise, a Jackaroo is limited to the number of hours in a day they can work for you, often drawing out the project timeline.
And if anything happens to the Jackaroo, you may be in trouble.
If the project is larger than a few function points, not simple, has more than one component (e.g. server plus client plus API), the average Jackaroo will not have all the skills, time or ability to deliver.
When a project is large, complex, has many stakeholders, departments, components and seems daunting, the Army seems the way to go.
An Army has heap of resources available, specialists in any and every area are available at the Army’s fingertips. Need a web team, they have it, need an API team, that too, add an iPhone component, the Army has people who can do that too. If there is one thing an Army never runs out of, its resources.
And for every specialist developing code, there’s another to test it, another to document it, another to integrate it and another to review it. Armies produce large, complex software products that do work, usually.
But at a cost.
Armies need leaders, we call them Project Managers. Armies need scouts to tell the army what to do, we call them Business Analysts. Armies need standards, we call them Programme Managers. Armies need logistics, we call them assistants. The true cost of an Army is not in the number of people (a Jackaroo costs the same as half a dozen outsourced programmers), but in the number of interactions between them. The managers, analysts, assistants, programmers and client have to meet a lot to ensure all parties understand the needs, progress and issues of the project. The Army needs lots of internal meetings to ensure the analysts deliver a consistent message to the programmers, the analysts and programmers have to meet constantly to see that the required software is being built. The testers have to meet the analysts to know what to test for and meet the programmers to point out where the tests fail. The number one reason large projects fail is that the communications network gets just too complex and political.
Besides the time these meetings take up, communications breakdowns cause havoc in Armies. Small misunderstandings between teams can lead to large integration issues, incorrect modules being developed, components failing to complete. Even worse, communications breakdowns between client and manager, client and analyst, analyst and manager regularly lead large projects astray.
To make Armies more cost effective, most use outsourced, offshore programmer teams. These programmers never meet the client, never see the big picture, never understand the design, they just cut code. The result is a lot of code duplication, differing standards, and no-one takes responsibility for issues, performance or quality. And since these programers are not ‘in the loop’, they take their time.
Armies are not agile. Needs change, projects change, software changes and Armies take time to adjust. If the client is not 100% clear that the software required will remain static for the time it takes to write, the Army will be cumbersome.
The Army costs a fortune, even with cheap programmers and reasonable management. The Army produces workable software that may or may not be any good, but it takes time, a lot of time, and is hard to keep consistent.
Army examples: Microsoft has the largest Army out there, as does IBM, Oracle and SAP.
A Seal team in the military is a small team of experts who have had extra training and specialization; work together well and take on the toughest assignments, assignments a single spy or large team cannot accomplish.
If software, a Seal team consists of a small team of professional designers and programmers who take on the toughest assignments. Seal team programmers are seasoned programmers, experts in composing great software and just plain smart people. Seal team designers understand art, architecture, interaction, and your software needs better than you do. Seal teams live and breathe producing awesome software products.
Seal teams can take on large complex projects by simply breaking them down into manageable chunks and getting to it. They have been there before and know what to do. Seal teams produce well designed, well coded, integrated software. There are few meetings (low communications overhead) because the entire team is involved. They are agile, if the needs change or an issue arises, they all get on it, quickly, silently, efficiently. They work in parallel. They work like a family. And they get it done!
But Seal teams are rare.
Finding Seal team members is hard, very hard, but not impossible. There are lots of potential Seals out there who have not been given the chance. I know, I have been hiring Seal programmers for 10 years. I choose people who are smart, passionate, flexible and those I get on well with. They may not have the experience or expertise I need, but a smart, motivated individual can pick up skills insanely quickly. But 19 out of 20 programmers I do interview for work are better suited to Army work.
Seal teams are hard to deal with. They are professionals, and unlike some Jackaroos and all Armies, they are just as passionate about your product as you are. Which means they are going to contribute to the discussion, offer unsolicited advice, point the project in new directions and in many cases, take charge. A lot of clients are not used to this and struggle hand over software design and control into the capable hands of a Seal team.
And Seal teams do not come cheap. Experience, quality and expertise take time to build up in people. And these people are in demand. You will pay a Seal team so much more per person that either the Jackaroo or the Army.
Seal team examples: Google never has more than seven people on a product team. And, the most popular software today was started in Seal teams, for example Bricklin and Frankston created spreadsheets, Andreeson and Bina made web browsers, Thompson, Ritchie, Kernighan, McIlroy and Ossana made UNIX!
You need a small team of exceptional people. Get them and the higher cost per person will be tremendously offset by the quality of the software, speed of development, ease of process and communication, flexibility in design and awesomeness of product.
Footnote: A good indie developer, like Noverse, seems to be a Jackaroo, but we’re not. I may be the lead, but I am surrounded by other brilliant programmers, professional designers and business experts, people who complement my skills, whose strengths are my weaknesses. A Noverse Seal team will form for your project, and re-form for the next.
]]>This question was asked, and answered, on stackoverflow.com 2 years ago, and has been viewed almost 200,000 times. I was one of the people who answered the question (click here).
There are three components in almost every iPhone app: a server component, a design component and an app component.
The server component of an iPhone app usually takes the most effort and chews up the majority of the budget. You need to deal with the physical servers, hosting, networking, security, backups, failover, scalability, reliability. You need to develop databases, servers, API’s, migration strategies, load balancing, and backups. You need an army of people to operate and maintain these servers, support them, enhance them and feed them. Instagram went through half a million dollars just building theirs, twitter has spent untold millions on theirs.
Creating a server infrastructure from scratch is something Noverse can do for you, but it will cost a lot, in the hundreds of thousands of dollars if you outsource the whole lot to us. In return, you will get a server platform to support your needs, that has APIs that are used by iPhone apps, web sites and internally, is scaleable, maintainable, and supported.
But almost everybody already has some server assets. These need to be enhanced to provide the API for the iPhone app, exposed and secured on the internet to make the API available to your users, optimized to perform quickly enough for app usage, reliable enough to deal with the user load as well as gracefully fail-over when things go wrong. Creating the new wrapper interface to an existing set of system is a large project. Analysis needs to be done to see if the data or API needed for the iPhone is even available in existing systems, or whether these need updates of their own. Then the new services need to be designed, implemented, tested, secured, deployed and a support infrastructure created. Cost? Between $50,000 to $500,000, depending on what works. Most clients use their internal IT resources to do this to save money. Most clients also underestimate the amount of time these internal resources will take to get their part completed.
If you are lucky and the server component already exists, is quick, has an API and is supported (like twitter app developers), you’ll be saving 60-70% off the total app cost.
You will be surprised at the time and cost of the design component in an iPhone app. Corporate developers are not used to doing anything more than functional design. Commercial developers are used to doing that plus UI design. All of which can usually be done by developers or great systems architects.
But mobile apps require more than just an architecture and an UI, they need a theme, a look and feel, an interaction model, and a lot of graphics. Third party developers will often quote to create an iPhone app that uses standard Apple widgets, and this not only reduces cost but makes the app look cheap, boring and in many cases, makes it less accessible, intuitive and useable.
Mobile apps need to stand out, need to project your image and themes, and on more practical levels, need to deal with an unconstrained tactile interface. Action feedback idioms are up for grabs, interaction gestures need to planned and the whole interface needs to be trialed, tested, iterated on and often revisited several times.
For example, when the user presses a buy now button on a product in a shopping app, how can one feed back to the user that the product has been added to the cart? Using standard widgets, you change the badge (the red number) on the cart icon. But most users don’t notice it, and most tap the buy now again. Apple’s Apple Store app transitions the user to the cart tab, greys it out, puts up a spinner to show its doing some work and animates the adding of the item to the cart, then ungreys the screen. A lot of design went into that. Amazon’s shopping app, on the other hand, spins an image from the top to the bottom of the screen to simulate an box being added to the cart. That works too. One of my apps peels the product page off the screen and shrinks it down into the cart icon, like the page is being sucked into the cart. Thats another design. Which will work for you?
iPhone app design takes at least a month of designer work which I usually estimate at $40,000 per month. That’s if you already have a corporate logo, image and theme, as well as all the raw graphic assets needed. Add more time to create your image and the app’s image if these do not exist.
Finally we get to the iPhone app itself. Once the analysis and app design is done, a 3-4 function app will take about a month to write the core, and two to three months to polish and release. Add a few months for iterations and testing. Expect to pay $150 an hour or more per developer at at professional firm like Noverse, or about $50,000 to $150,000 depending on number of functions, amount of animations and amount of custom interactions needed.
Assuming the core of the server component already exists, expect to pay between $100,000 and $500,000 to get a quality iPhone app that works with a reliable server infrastructure. No server needed, then look at about $50,000 to $250,000.
You will read elsewhere on the internet that people got apps written for them for under $10,000. That’s probably true. There will be those who used outsourced international programmers and got apps for under $25,000. That’s true too.
But. There is always the ‘but’.
But none of these applications have a server component. None of these applications had any design done or interaction model in them. None of them look good. None of them have more than one or two functions in them. None of them have been updated or modified in any way. None of them have had bugs fixed in them. None of them is maintainable. And none of them have made money for their creators or grown their businesses.
If you want a quality iPhone app, that looks great, is intuitive, is reliable, bug free, maintainable, updateable, and works reliably with a server platform, prepare to spend several hundred thousand dollars on professionals.
]]>I instantly and politely decline these requests.
I don’t ever want to decline work, and when I set up this business, I planned to say yes to every potential client and service them as best as possible. Not only that, the only way to grow a consulting business is to actually bid and win business, not decline it. No engagements, no clients, no business, no money, obviously!
But I still decline requests for proposals on fixed-price, fixed-time, fixed-process based work. Several potential clients have been upset by the instant rejection and have asked why such a response.
Here’s why:
Instead
The only question that comes up, then, is how can the client be sure, given the iterative and open-ended nature of the engagement, that they will end up with the product they expect, in the timeframe they need, at a reasonable price (the implied goal of the waterfall model).
The answers, my friends, are these.
I do not expect to stop receiving requests for fixed-price, fixed-process and fixed-time project proposals, nor do I expect to ever accept and respond to any.
I do hope to receive more interest from clients intent on collaborating to produce great software, software that we can both be proud of, and can enjoy working on creating and delivering it.
]]>Its not easy. Fast coding means faster bugs. Quick coding means rotten quality. Rapid development means architecture is ignored. Cowboy coding produces unmaintainable code. In short, I don’t recommend it.
But, my dear padawan, it is do-able under the right circumstances. Rare circumstances. Recommend this, I do not.
A client called up at the beginning of October and asked if I could produce an iPhone app for them. I can. The app is to represent their brand on the iPhone and allow users to purchase goods from them. Sure. It needs to look great and be bug free. Of course. And it needs to be in the app store in November! Mid-November OK? Hello? You still there?
Mid-November! Assume a 2 week review process and a 2 week beta test, the app had to be written in, yup, 2 weeks.
Possible, it is not!
Unless sprint coding, we do.
I quickly ran through my sprint coding checklist to see if it was do-able:
Possible, it may be.
Remember when I described Sprint Coding as something performed by a skilled programmer? Here’s why.
A skilled programmer never relents on
How I work, this is.
If you’re going to sprint, and your skilled programmer does not do all of the above, the result is going to be an incomprehensible mess, full of bugs and completely unmaintainable.
Sprint code an application using the following steps:
But most importantly
Once the sprint is complete, you should have a fully working app that looks and works great. But no matter how skilled the programmer, no matter how good the API, it will not be ready for prime time.
Beta testing is important, beta testing a sprint is even more so.
During the sprint, the programmer and the client are usually the only people looking at and touching the software. And two people does not a good test sample make.
The speed of sprint means that the code will not be bulletproof. The speed of the design means that the flows will not be idiot proof. Code bugs, interaction issues, flow problems, and things missed by the two primary individuals will abound.
Take a sprint app, throw it at tens of committed beta testers and ride them hard to identify odd behaviors, crashes, bugs and interactions. Send out several beta builds, all fully instrumented, and request logs back from all testers to see what happened, even if it all worked.
And then, two days before submitting it to the app store for review, send out the final build, in release mode, to all beta testers for a final end-to-end test. Once you strip debug and instrumentation, you sometimes get some new oddities cropping up.
In this case, the client and I had all the items on the checklist.
So I took the assignment.
And for the last two weeks, I ran a sprint. I reveled in architecture, I rollicked in the model, I danced on the API façades, I sung the views into existence, I brushed the theme into place and I ran with the coding bulls. I was on the endorphin high of sprint coding. And I loved every minute of it.
And now, the app itself is mostly ready for Beta, just 2 weeks later, sprint over. Back to ground, I came.
But the client API had a few holes in it that we found towards the end of the sprint. The API team is working on it. But each day they work on it, delays the beta and final release. Disappointed, we feel.
And once again, my dear padawan, I remember why I do not recommend sprint coding.
]]>Here are a few screenshots to whet your appetite.
When you start the app, you’ll see a world map with all your guides on it. I am also experimenting with a ‘tag cloud” approach to help you jump to a guide quickly, but it may not make it into the final product.
The guide map page now uses the whole screen.
And the sight details look so much cleaner, now that I have the space to work with.
In the mean time, get the iPhone version. The iPad version will be a free upgrade.
]]>It got me thinking about how I use software, how other people use software, how people tell me how to use software and how I tell other people how to use software.
I am a mouse and GUI guy. Even though I have been programming for over 20 years, I still do not touch type. I did learn, but much of my programming requires me to move my hands away from the home keys and onto the symbol and modifier keys. My 6-8 finger floating typing technique is adequate, and I usually use all the control keys from my left hand while my right rests on the mouse. The disadvantage of a floating typing technique is that I often strike the key next to the one I want, and given that I regularly move keyboards with slightly different layouts and key separations, this is a problem. So give me a GUI any day.
I am also a native application guy. Given the choice between command line, web or native GUI, I go native every time. Part of it is the aesthetic beauty of a great native GUI, part of it is the comfort level using standardized GUI (command lines and web sites are notoriously non-standard) and part of it is because I have spent so long with menus here and icons there and buttons this way that I don’t want to change.
Here’s my morning so far:
And I have paid for each of these apps (Colloquy is donation-ware)!
I love the value I get from each of these products. I love how productive I am with them. And I love how I love using these products. And I know I’m not the only one because all of these products are very successful in the market (and likely why I am becoming an indie developer too).
I never get these feelings or productivity from the command line. I don’t get attached to things on the web either. The command line is as boring as a desert, and the web seems transient, almost like its unfinished, unpolished or just going to change yet again for no apparent reason.
I think a lot of people outside the tech world expect software to be hard, confusing, full of jargon, unstable, continuously changing and requiring of special skills to use. And to use it, they have to learn all the odd commands, weird menus and sequences of steps to get the job done.
I also think the iPad is changing this perception, albeit very slowly.
Well designed GUI applications like the above are great for non-technical people to do technical work. They require no special skills, they have very clean and simple interfaces, they eschew jargon and they make the experience of using the product oh so much more fun.
On the tech side, there will always be those who say the command line is faster, more efficient and the right way to do things. I’m not going to argue with them, it works just great for them, it suits their style and they must love the simplicity and elegance of well crafted commands. I do not. And I will not feel guilty because they feel superior. I can use the command line, I choose not to.
Web GUIs drive me nuts. Great web interfaces are few and far between. But the inconsistency between sites, the lack of a HIG (Human Interface Guidelines) standard, the performance delays caused by round-tripping and my perception that all web sites are like mine, under continuous development and change, make it hard for me to like them. And with net neutrality all but a fiction, reliable internet service a fantasy, I like having my applications and data on hand no matter what.
I have been told by experts and novices alike how to use the software they like the way they like to use it. Listening to them has made me a better developer and has enabled me to create more flexible and useable interfaces.
But some of the things users put up with amaze me. Application restarts, arcane commands, odd sequences of menu operations, manual behaviors because the automation fails, save and reload, step by step processes that add nothing to the document but are required to stave off perceived problems, chicken dances and goat sacrifices all. I had one user who loved his CRM package, but could never find a contact in it and had to shut down all other software before sending out a mail merge. Yet they would not change products and wanted me to use the same messed up system.
I tend not to put up with these things. If an application does not look great, I look elsewhere. That seems superficial, but a developer who does not deliver good aesthetics usually does not deliver good solutions either. If an application is complicated, confusing or full of jargon, I use another. If I have to be trained to use the application (even with domain knowledge), I choose another.
I don’t. Software, at the end of the day, is a means, not the end. Whatever works for you to achieve your ends, do that.
Well, actually, I do tell people how to use software, but only indirectly. By creating well designed, intuitive and easy to use applications that are fun and efficient to use, are bug free and look amazing. I hope they compare my software to others and realize that they have gold in their hands instead of plastic.
Oh, and maybe a little directly in this blog.
I buy a lot of software. I write a lot of software. I use a lot of software. And I regularly replace software with new, shinier and better software.
When I work, I choose to use small, focussed, well designed, native GUI applications because through them I more productive, I enjoy using them, I enjoy doing the things they do for me, I like the way the look and operate, and it suits my style.
And my next OS X application, which will be a Noverse public for-sale one will do just that, replace confusing and complicated web interfaces with an excellent native GUI to help me, and I hope you too, gain the same enjoyment from my software as I do from the software I choose to use every day.
]]>The blues come from two sources, shipping and waiting.
The first version of an application always ships, if you do it right, with the critical core features working, one or two bells and whistles to make it fun and nothing else. Do any more, and you’ll never ship.
But there is always a long list of features that you plan to add to the app, and this list has been staring you in the face since the day you decided on the first release feature set.
But you have to ship, and you have to ship sans all these other features. It would be better with more features. Maybe it would sell more if I just added a few more. Ahh, the shipping blues.
Well I’ve shipped. And while I wait for approval, I’ve gotten started on the next version, adding features from the list to delight my first adopters as soon as possible. Some of these features that I thought would take a long time took no time. And they are ready to go. But I’ve already shipped! What now?
If I update the app in the review queue, I’ll go back to the start of the line. And the review and waiting process will take much longer. But these new features are just so nice, and I think my users (none of whom exist just yet) would love them. And the shipped version already looks shabby compared. Ahh, the shipping blues.
I also have the waiting blues. I have no idea how long it will take Apple to get to my product and review it. And I have no idea whether they may even find a reason to reject it or not. I have no idea when it will go on sale.
So I cannot plan my media blitz (consisting of a press release and facebook update) to coincide with the release date. I cannot tell people I meet now when they can buy my app.
And if it gets rejected, I am not even sure the feature set I’ll resubmit. So, should I be working on this feature of that just in case. Ahh, the waiting blues.
But more than that, I have no feedback. I spent months writing Sights to See, and I hope it will sell well. Maybe this is the lull before the storm when heaps of folks buy it, or maybe this is the lull before the next lull when no-one buys it. Most apps do not sell, most do not make money. But I’d like people, strangers, you to look at it and use it and play with it and buy it and talk about it. And get back to me with you experiences with it, and what you want it to do, and how it could be better, so that more people will buy and use it..
Up until now, I’ve written what I want for the product. I am waiting to hear what you want. Ahh, the waiting blues.
I am dealing with it by barreling forward on V1.1. Taking advantage of the lull before I have real customers with real needs sending me real emails that will take my attention away from real programming. No interruptions, lots of progress.
But at the back of my mind, though, are the blues. Will it get approved? Will people like it? Did I make the right calls on features? Does the content on the app store and web site help people see the value of the product? Or, did I waste my time on making it? Ahh, blues.
]]>For Sights to See, I will release it at $9.99.
Let the wailing begin!
From a customer’s perspective the value proposition is easy to figure out.
If the customer buys a paper guide book, it costs about $20.00 from Amazon. The paper guide book is limited to only the places in it, weighs a lot, is hard to navigate and to navigate with, and is usually out of date.
If the customer buys an electronic guidebook, it costs on average $6.00. The electronic guide is limited to the places in it and are usually just reprints of the paper guide books without any additional interactive features. Want to go somewhere else, thats another $6.00.
For ten bucks, the customer can buy Sights to See and have as many guides and places as they want, the most up-to-date data from wikipedia which is always being updated, no extra weight to carry, the cool maps, the near me feature, and all upgrades to the software included. What a great deal!
In summary, for the customer its
I have spent months of my time writing this application, perfecting it, crafting it and bringing it to market. I have spent money on setting up this business, money on systems and money on web sites and money on tools. Creating the software cost money, so I want to get money back to cover those costs, and hopefully afford a beer or seven.
Further, the App Store store does not enable upgrade pricing. Each sale I make is all the income I will get from the product. All upgrades will be free to my customers. But upgrades cost me time and money, and I know I’ll need more web hosting for some upgrades. But I will not get any upgrade revenue.
If I set the price too low, I may sell more units, but make less money, and with less money, there’s less incentive for me to upgrade the product. If I set the price too high, I’ll sell few units, and make less money too. Finding the sweet spot of sufficient sales and sufficient revenues is the trick. Which is why I look at the customer value proposition first. If it makes sense, the units should be high enough, and the return to me should be too.
One more point, setting the price to value also gives me room to discount the product later on. I hope never to do it, I feel annoyed when I buy a product and then the seller drops the price. But having the wiggle room is nice.
I expect to have to deal with the following
Do I increase the price when the universal/iPad version comes out? Lots of developers do this. Start with the iPhone version being cheaper, say $9.99, then boosting the price higher, say $19.99, when the universal is released as the iPad version offers an even better value proposition. I’ll probably do this.
Do I create a separate and more expensive iPad version instead? I can do more on the iPad screen, which is better for customers and increases the value of the product. But I will also annoy existing customers who purchased the iPhone version because the’ll have to buy the same product again. Personally, I don’t like to buy the same thing twice, so I’ll very likely not do this.
Sights to See will be released for $9.99. The customer value proposition shows that this app will save them money, and the amount saved will grow as they travel to more places.
And I hope enough people buy it and love it as much as I do.
]]>