Latitude 40 is a group of experienced business analysts, software developers and general IS professionals dedicated to putting modern technology to effective use in real-world environments. Our desktop, web and mobile solutions utilize the most current technologies available that best fulfill your needs. We put a huge emphasis on the importance of good design and overall quality in the software we write. Our goal is to provide quality software tools at a profit to you and to the detriment of your competition. Currently based in Denver, CO, Latitude 40 has a worldwide customer base.
Latitude 40 was founded by Andrew Anderson and Daniel DeLeeuw, both of whom have strong roots writing software for the agricultural industry where a significant portion of their business continues to develop. First meeting in the 90s as contractors working for Fischer USA, Inc. and its German parent company, Fischer Gmbh & Co Kg, Andrew and Dan continued to work together on projects for Fischer and others. Years later, with many successful projects under their belts and continued praise from their individual customers, Andrew and Dan began to consider incorporating together. They regularly discussed the similarities of problems they found themselves solving for their customers time and time again. They noticed how unreliable and irresponsible individual developers could be as they would regularly just pack up and leave one project in favor of a newer one, leaving their customer with the fallout. They had the mutual experience of inheriting these abandonded projects only to find that the incomplete part was just as much of a problem as the quality of what was left behind. This left the customer with the very tough decision between continuing with the bad product base or starting over for what always felt like a substantial loss. They noticed even worse results while consulting for larger corporations who had their ERP IT work done by larger and more prestigious companies. A 70% success rate seemed to be a generous normal, and "success" didn't mean it worked well, but rather that the company was able to cope despite multiple problems introduced, sometimes indefinitely. ERP software at that level is something that controls the entire business process and can potentially bring down the entire company if it isn't designed well or if it doesn't function properly. So a higher regard for quality of product seemed to be in order across the board. The exposure to these and other common issues led to a vision of a company that could handle the responsibility of providing quality software without all the drawbacks and uncertainties that usually come with the attempt. Latitude 40 was eventually born and is continuously striving for such perfection.
Philosophy: Cooperative Design
Latitude 40's sole purpose is to solve problems in your business through software tools. But how will your product work? What technologies will be used? What will the screens and reports look like? Designing your software so it accomplishes your goals and provides an efficient user experience is not a simple task. On one hand, nobody knows your business domain better than you do. On the other hand, we can't always expect you to know about software design or know what software solutions would best solve your problems. So design should be a joint undertaking by the business experts from your company who know what problems need to be solved, and our software design experts / business analysts who can help guide you to the best solution.
Latitude 40 strives for communication excellence in every way possible. The largest source of failure for all software projects is some amount of communication breakdown. Failure to keep the customer informed on progress or even about complications requiring schedule/budget changes frequently leads to billing disputes and broken relationships. These are all too common in this industry and therefore motivate us to do better. In fact, we insist on having regularly scheduled and frequent meetings allowing us to present a complete status report highlighting recent progress, effects of any recently added requirements on schedule and budget, etc. It also gives you a chance to provide feedback, request a new requirement, change priorities, or anything else. The result is a complete understanding by both parties of where we are and agreement on the way forward.
Philosophy: Quality Please
Latitude 40 is disappointed with the general state of business software currently being built for small and large companies alike. With the prevalence of the outsourcing model and the use of frameworks and tools that have been well marketed but poorly produced, overall software quality is nowhere that it can and should be. Quality isn't generally a subject that is understood and sought after these days and it's become rare to actually have a product delivered that does what you want and isn't laden with bugs. This is simply unacceptable in our eyes. The good news is that great minds have endeavored to solve the software quality problem and have evolved great organizational theory and tools over the decades. Microsoft's more modern tools are a good example as they are themselves designed around such design models. These tools form a great development platform, but a good software system still relies on the human element to provide good design based on good design principles. By putting everything together, you end up with a system of quality that does what you expect, is secure, reliable, maintainable, efficient and aesthetic.
Philosophy: Insourcing vs. Outsourcing
Quality as an objective has diminished as companies have jumped onto the outsourcing bandwagon and subscribed to the idea that this type of ineffective development is actually ok. What you end up with is requirements that are always miscommunicated to the novice developers overseas leaving you to either cope with the result that doesn't do what you expected or abandon your project at a large loss. Abandoning your investment will never be appealing, so generally some kind of coping is what occurs including spending a lot of money for the ongoing support of the buggy software. In the end, you've spent MUCH more money than you should have for an inferior product. If you're lucky, you won't bring your whole company down and into bankruptcy (click here for a famous example
). Looking on the bright side, your competition will probably do the same thing with the same result. Some of these projects do end up being ok, but what you're basically doing is leaving your success up to chance rather than building something that would have guaranteed an advantage over your competition. We hope you'll understand that quality software is still a noble objective and is possible despite a world that seems to have abandoned it for the sake of the "cheaper" outsourcing model.
There is usually a strong inclination on the part of the customer to push the development team to jump quickly into action without good specs and without making sure the requirements and problems domains are fully understood. While we certainly understand your excitement and desire to get the project done rapidly, the best way to do so is to create and follow a good plan that includes all the steps of the software development process. Disappointing results would most likely follow otherwise. A modern agile design/development process is very efficient, however, we do recognize the few shortcomings of pure agile development so have therefore come up with our own approach that combines the best of the agile world with other techniques more commonly used in other industries. Many businesses (usually larger ones) are still skeptical of this approach and favor the traditional waterfall model which is very difficult to manage to a good end product. While it is possible, it takes a vast understanding of the process, great discipline to ensure the process is followed, and tremendous skill in carrying out each step of that process correctly. Any deviation or any poorly executed step causes undesirable ripple effects all the way through to the end. So while we are capable of running this type of project as your company policy dictates, we certainly favor a more agile approach.