Software has bugs, yes, even ours. Since programmers are human, and humans make mistakes, ergo bugs. When you come across a bug in our software, or anyone else’s for that matter, you need to email in a bug report. The developer can use this to identify the problem, replicate the problem and fix it.

But most of the time, we developers find submitted bug reports to be incomprehensible. This is because the submitter has no idea what we need, how to communicate with us and how to write one of these bug report things.

In this article, I am going to teach you about how to write a good bug report so that the developer can understand, replicate and fix the issue.

Download a text template for a bug report.

Why send a bug report

Bug reports help us developers in a myriad of ways:

• They tell us about issues we are not aware of
• They help identify new features that we may not have thought of
• They help us get a feel as to how our customers use our software, so we can make it better

Without bug reports, we have no idea things are going wrong, or acting slowly or not working for you. We need these just as much as you need the software to sing and dance.

When to send a bug report

Short answer, always and as quickly as possible. Longer answer, when:

• You see an error message, send a bug report
• The screen is blank or data is missing, send a bug report
• When the program does not behave as expected, send a bug report
• When the program crashes, freezes, becomes non-responsive or is slow, send a bug report
• When the program gives an incorrect answer, send a bug report
• When you don’t get what you need from the software, send a bug report
• If you cannot figure out how to do something, send a bug report
• If you don’t like the way it does things, or the software annoys you, send a bug report
• If you have to implement a workaround in the system, send a bug report

What should it include

A bug report should contain a lot of information, the more you supply, the better. Some developers, like me, offer a plain text file template for you to fill in and email. Others have a web form. But most expect you to make one up and email it. Here is what it should contain and how to write each section:

Title: Create a short title for the report, and please be clear what the issue is. “Application crashed” is a horrible title as it gives no information on what is included in the report. Instead, title it with the error message and code, or product name and thing you were doing when it failed. For example: “Error 402: Access denied when clicking ‘Send Email’” or “Kifu reports error when generating Honors Report”. Both of these provide context for the bug report.

• Bad: “It crashed”, “Saw an error”, “Bug”
• Good: “Error 5C79 when printing from Kifu”, “Kifu honors report is blank”

Product: Identify the product, by name and say which version you are on. Almost all software has an about box with version information or it’s in the footer on web applications.

• Bad: “Your application”
• Good: “Kifu v1.01”

Classification: We need to know how serious it is, is this a feature request, minor annoyance or a full blown show-stopping nuclear-reactor-melting-down armageddon bug. Most forms have a set of these to choose from, but if they don’t, try one of: “New feature”, “Minor Annoyance”, “Crashing Bug”, “Serious Bug” or “Minor Bug” for those you can work around.

• Bad: Leave it blank
• Good: “Serious Bug”, “Annoyance”, “Feature Request”

Platform: Tell us what you are using to run the software, especially operating system name and version and web browser name and version, they are all different, and it’s important for us to know it – especially for web applications.

• Bad: “Windows”
• Good: “Windows 7, Internet Explorer 9”

Can it be reproduced?: Some of the most annoying bugs are intermittent and cannot be reproduced. We’d like to know up-front if we are dealing with an oddity or an every-time bug.

• Bad: Leave it blank
• Good: “Every time”, “Occasionally”, “Unable to Reproduce”

Description: This is the area where most people struggle, how to describe what the issue is. Try to include all of the following in the description:

• Summary: A quick natural language overview of what you were trying to do when the bug appeared. Start with context, where in the application you are, then focus on the “what” you did and “what” the software did. Try to describe it like an old school news reporter would call in a story from a phone booth, just the facts.
  • Bad: “Application does not work”
  • Good: “Clicked on ‘Print’ button on ‘Honors Report’ screen, but the report is blank”
• What happened: Describe step-by-step what you were doing when the bug appeared, and why you think it’s wrong. Be specific, type out the menu names, screen titles and the full wording on buttons or links clicked. If you do the same steps, does the same error occur?
  • Bad: “Blank report”
  • Good: “I clicked on ‘File / Save As…’ and the ‘Save’ dialog came up. I then clicked on the ‘OK’ button but the file did not save.”
• What’s the error: If an error message does come up, copy and paste the whole thing in. It makes it really easy for us to track these down.
  • Bad: “There was an error, but I clicked it away and did not read it”
  • Good: “Error 403: Access denied”
• Supporting Information: If this issue happens on a specific login or on specific data or at a specific time, provide that too. Specify the record you were on if you can.
  • Bad: Leave it blank
  • Good: “This error happens for all event records that are fees, but works for event records that are campaigns”.

Steps to reproduce: If you can make this bug happen again, great. That’s a huge help. Describe step-by-step how to reproduce it, from as far back in the process as possible. And again, be specific. “I clicked on X” is different to “I double-clicked on X” is different to “I tabbed to X and pressed return”. All three trigger X, but what did you do?

• Bad: “I tried to print, but it did not work”
• Good: “From the ‘Honors Report’ screen, click on the ‘Print’ button”

Expected results: Describe what you expected to happen when the bug occurred. This section is especially useful if the program does not behave as you expect it to, or if you would like to change the way the program works because it’s annoying.

• Bad: “I expected it to work”
• Good: “I expected to see a PDF of the Honors Report.”

Actual results: What did happen when the bug occurred. What was wrong, why is it wrong or if an error was thrown, what was the error.

• Bad: “It did not work”
• Good: “I received a blank PDF file”, or “Error 403: Access denied”

Workaround: If you have found a way to continue using the software by working around the bug, explain it. We may fix the bug, but the workaround could be causing other problems. Many people think this should be included in a bug report, I’m not sure as it does encourage workarounds instead of bug reporting.

• Bad: “I have a workaround”
• Good: “If you restart the application, and go straight to the report, it works the first time.”

Attachments: If you know how to make screenshots, do it. Attach a shot of the error, and of the screen just before the error and the one before that. We developers can then see what happened and what you see. If the application issues a crash log (or has any kind of log), attach that too.

Contact Information: Add your name and email. So we can keep you posted on the investigation and repair, and to enable us to ask you any questions about the bug that we may not understand. If you forget this, we may not be able to contact you and fix this bug.

Hints and tips

• Show stoppers: If the bug is stopping you from working or has a deadline by when it needs to be fixed, let us know up-front. That’s what the class field is for. We developers understand showstoppers, we know how it feels when the software does not work and you need to get things done. We will drop everything to fix these.
• Be specific: Use the exact same words as the application. If you see something, write it as is. If you click something, write it’s exact name.
  • For menus: Follow the sequence of menus separated by the ‘/’ character, for example “File / Save As…”
  • For screens: Look at the top of the window and type exactly what is there
  • For buttons or tabs: Copy and paste the exact text shown
  • For links: Copy and paste the whole URL (including the “http://”)
• Don’t ignore error dialogs, ever!: It is a hassle to report every time an error comes up, and it’s just too easy to click it away instead of reading it. But if you ignore these, and don’t report these, we’ll never know. We don’t know when you see an error, and even though we have logs, it’s hard to find errors in them.
• What was happening before: The problem is that a bug is the end of a workflow. To reproduce it we need to reproduce the whole workflow. Which means we need you to tell us what you were doing before the bug appeared and what the software was doing too.
• Report the first error you see: Oftentimes, people get so used to an error that they become tuned to ignoring it. So when a new error occurs, they report that as the “first” error they saw. Not true. If a part of a system has failed, the next error may be a result of the first failure and not a real error in itself. We need to know if you ignored a crash before you got this error.
• Attach or Copy and Paste: Copy and paste whatever you can into the bug report, attach as many screens and files as you can. The more information we have, the more likely we’ll find the issue and fix it.
• Workarounds are Bugs: If you cannot get something done using the expected process, but can with a workaround, you have a bug. Report it. Workarounds cause huge problems later on so its best to get the expected process fixed than rely on the workaround.
• More is better: I know I am repeating myself, but the more you put in the report, the less we need to do to find the issue.
• Stay on topic: A bug is something that happens in software, its a “what” or a “how”. It does not help us to know what else you were doing, or why you were doing it (unless we ask), or what you are wearing. We need to know what you did that triggered the bug so we can fix it.
• Don’t get personal: You are reporting a bug, not discussing the developer’s nature or the quality of the software. Bug reports that contain offensive or emotional language will be ignored. I don’t suck, nor does my software, so lets discuss the bug.

And my biggest tip of them all:

• It’s not you: You did not create the bug. You did not break the system. It’s not your fault. You are not stupid. There exists a bug, the system broke, now lets find it and fix it. It’s not about you, its about the bug.

We do want to hear from you. Seriously we do. We want you to send bug reports in, we need to you bother us, and we know how hard it is for you to produce a bug report. A lot of people don’t report bugs because they do not want to bother the developer. That is the wrong attitude. Send us your bug reports and ideas. Barrage us with them if you can.

Feel free to download my plain text template here.

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.