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

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

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

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

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

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

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

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

“Ring Ring”
…
“Hmmmm Hello”
…
“Er Hi Mum”
…
“Mum”
…
“MUUUM”
…
“Do you know what the time is?”
…
“I know it’s after work in Sydney, but it’s 3AM here in New York”
…
“Yes I was sleeping”
…
“No, no, I’m awake now”
…
“Just please check the time before you call”

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

TimeToCall is coming soon for the iPhone and iPad.

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

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

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

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

Continuity

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

Popular Platforms

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

The benefits of popular platforms are many, including:

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

External Source Code

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

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

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

Readable Code

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

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

Maximum Developer Documentation

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

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

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

Releases and Deliverables

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

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

Off Site Backups

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

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

Learning from Product Transitions

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

No more.

That’s why I document everything.

In transitions, I work with the replacement team to:

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

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

The M100 Bus

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

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

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

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

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

No matter, you know who you are.

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

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

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

Thank You.

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

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

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

Do’s

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

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

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

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

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

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

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

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

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

Don’ts

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

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

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

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

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

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

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

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

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

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

Great demos

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

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

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

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

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

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

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

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

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

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

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

CTO’s also

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

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

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

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

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

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

If you have any questions, please do not hesitate to email us at contact@kifuapp.com or contact@shukaico.com.

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

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 “”)
• 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 n