“Bob”.

And Bob worked on their solution.  He was always there to add functionality or resolve issues. But then Bob died suddenly of a stroke or heart attack or cancer or being hit by a bus.  Or, to put a more positive spin on it, won the billion dollar PowerBall lottery and moved to Tahiti where he is now sipping frothy rum drinks out of a coconut.  Even in the case of the gentleman who had cancer, he thought he had 6-9 months and was gone within 3 months.  Far too ill to worry about the software support.  He truly did the best he could, but it wasn’t enough.

These poor fellows left a complete mess with their clients. Unintentional but a crisis nonetheless; causing these companies to call us in a panic. “Can you help us?” Of course, the answer in all things technical was “Maybe. It depends.”

Turns out, we could, and did, help these companies, ultimately writing an entire custom business solution for each of them. But there were several painful lessons.

1. Going with the proverbial one-person-show – While there are wonderful, well-intentioned developers out there who do a great job, the danger is always that something horrible may happen to them, as in the case of our clients. Or maybe something wonderful like a winning Powerball lottery ticket. Although in the case of the latter, one would hope that there would be some time for a hand-off of information and processes. Regardless, your business likely cannot run efficiently or even at all without your computer systems. You wouldn’t have the operations of your entire company held solely in the palm of one person, so please don’t put your information systems in such a precarious position.
2. Maybe not bleeding edge, but at least in the current decade – It’s extremely difficult and time consuming to stay on top of the most recent technologies. This is especially true when you are the only one doing all of the work, leaving little time for research or attending classes, etc. In a team environment, people do research and share it with their colleagues and often have lively “debates” (well, sometimes actual arguments) around the topics. Regardless, it opens up everyone to new ideas and methodologies. Working alone, and I am speaking from first-hand experience, is a very lonely time and doesn’t leave you much opportunity to gain exposure to new ideas and techniques which benefits your client in improved systems and streamlined methodologies.
3. You are NOT stuck with the situation – Often when we’re called in, the company says they felt “stuck” because the one person knew so much about the systems and they felt that they needed to retain the relationship, if only to show loyalty. That is a fallacy. There is no system that can’t be figured out although it may be an expensive undertaking. We have had multiple situations where we’ve not had any help on the system functionality and code and we’ve managed to work our way through it. Sometimes there is “documentation” comprised of some old dusty notebook printed on green-bar paper (remember that?) that hasn’t been updated in 20 years. Be aware that your company isn’t ever “stuck”. If you are working with a company or person that you’re not happy with, you can always change the situation. Find someone to work with that you like and trust.

So, don’t let your company get into a situation with one person holding the keys to your information systems. This can happen in companies of almost any size.  No one is irreplaceable and, if they are, you likely aren’t paying them enough. Get someone else brought up to speed, whether it’s internally cross-training the team or bringing in a consulting group like InTune to help. It doesn’t have to be perceived as a threat to “Bob” and, who knows, he may live longer if he’s not under so much stress.

Long live Bob…. And let’s hope your company survives it.

The post Alas, Poor Bob – The Weakest Link appeared first on InTune.

The post Could Your Development Team Win a Championship? appeared first on InTune.

Use these 6 questions to help identify to make it easy to spot the right software vendor and keep your project out of the custom software development hall of shame.

1. How will you personalize your service for my project?  You deserve customized service, so if the vendor looks surprised by the question, your interview is over.  The vendor should ask you things like, “How often do you want to get status updates?”  Depending on your project size, you may want weekly, bi-weekly, or monthly updates.  Another good question to hear from your vendor is, “How do you want us to communicate with team members?”  You may want emails, but your technical team members may prefer an instant message.
2. What are your standard processes?  A software development firm should have an established methodology for requirements, coding, testing, and project management, and they should beexible enough to fit their standards to your business needs.
3. How have other companies used your services to improve the way their business works?  With this question, you’re determining whether the vendor understands that software is a business tool.  If your prospective vendor talks more about technology than about business, tell them goodbye.
4. How long have you been in business, and how long have your employees been with your company?  You’re making an investment in a software partnership; ideally, you’ll be talking to the same people next year when you want system enhancements.  It’s important to know that you’ll be dealing with employees of the firm, not short-term contractors.  If the company was founded last month, and it uses only contract employees – keep looking.
5. What skills do you offer?  The answer to this question should include a lot more than a list of the languages in which the firm writes code.  Your vendor should talk about the skill sets required for a software project, including:  requirements definition; system architecture; maintenance programming and report writing; testing; and project management.  One big advantage of teaming with an experienced software partner is that you don’t have to hire someone to provide each skill set a software project requires.  If your vendor can’t provide someone for each set of skills, they’re not likely to be a viable long-term partner for your business.
6. What went wrong in previous projects, and what went right?  If the vendor tells you that all previous projects were perfect, they’re likely to be careless in their handling of the truth.  Everyone has at least one failed project, and they should be able to tell you why it failed and explain the lessons learned.  Each vendor should also have a few outstanding successes to share.  Look for quantifiable, detailed information, and if the success story is a reference account, call them.

Spend time choosing the right custom software vendor.  When you pick the right one, you can expect a long-lasting and mutually profitable relationship. Ready to start your journey with a trusted software partner? Contact Teximus for expert guidance and ensure a successful and enduring partnership.

The post 6 Questions to Dodge Bad Software Collaborations appeared first on InTune.

The post 1 Person Can’t Wear 6 Hats in a Successful Software Project appeared first on InTune.

1.  Don’t accept “What did you do wrong?”

You:  I just added a new sales order, but it’s not in the system!

Software support:  What did you do wrong?

If something that has worked for days, weeks, months or years suddenly doesn’t work, there’s a 99% probability that you didn’t do anything wrong and the issue is with your network, hardware, or software.  Don’t accept “you did something wrong” as your software manager’s first response every time there’s an issue.

2.  Don’t accept non-answers and techno-speak

You:  I just added a new sales order, but it’s not in the system!

Software support:  Initial index analysis indicates a 48% cost hash match aggregate, so I may need to optimize the view this is using.  I’m looking at replacing the udf with an inline SQL, but that shouldn’t cause data loss; however, if 225 seconds is near the ADO.Net command timeout then that could explain a user/UI timeout, which might have caused the data loss, though you would have gotten a SOAP exception, so that didn’t happen.  I could execute the sproc in production with the same parameters you used.  If we run it with a BEGIN / ROLLBACK it will not affect any data. . .

If you are getting this kind of techno-speak non-answer from your software team, look for a bi-lingual liaison who can translate Business into Computer and vice versa.

3.  Don’t believe “I know more about your department than you do!”

You:  I just added a new sales order, but it’s not in the system!

Software support:  Well, I can look at it if you want, but I keep telling you that you don’t handle sales orders correctly anyway.  What you’re doing is not the way Acme Inc. handled sales orders, and I have a master’s degree in blah, blah, blah and so I know what you should be doing.

Most business managers are happy to hear constructive suggestions for improvement.  But nobody likes working with  a know it all, especially one who repeatedly tells you that the way a former company did things was correct and the way it’s done in the current company is wrong.  And when you have a software problem, you don’t want to hear that your business process is wrong – you want the software problem fixed!

When your software support your business processes, your software team may get a great overview of how the company works, and maybe they will have constructive suggestions for improvement.  However, if they dodge and delay fixes by focusing on ways your company isn’t doing things right, that’s just wrong.

What should you hear?

 You:  I just added a new sales order, but it’s not in the system!

Software support:  Wow – that’s a problem, and we’ll get it fixed as soon as possible.  Can you walk me through the steps that led to the problem so I can try to reproduce and fix it?

If you’d like to get this kind of response from your software team, contact Teximus.  We speak business, and we understand the importance of having software that works for you.

The post 3 things you shouldn’t accept from your software support team appeared first on InTune.

Final Changes:

Remember that you can make changes at any time to your software application. Thisexibility is one of the most advantageous aspects of a custom software application. You can work with your consultants to make sure that you get the application that you need and that the application will make your business cost effective and efficient. That said, remember that the later in the project that the changes are made, the more it will cost in both time and schedule. At the end of the software project, the only changes you should be making are bug fixes to the system. If you decide to make a major change, you need to weigh the cost in time and money against delaying the final implementation of the system.

Installation of Final Software:

Some applications, especially small applications, may not need an installation of final software, but rather, the version of the software that was installed during the beta software installation phase can be used. This occurs when any final changes made to the software can be made directly to the version that is already installed at your site. In other cases, a new and final version of your custom software application is installed at your site. This version may have additional changes and features that were not included in the beta software version. Once the final software is installed, and your employees are trained, you are well on your way to using your custom application to achieve your business goals.

Ongoing Support:

You may choose to maintain your system yourself or to contract with your consultants to do it for you. Ongoing support from your consultants may include fixing problems that show up only after many hours of use, changes to documentation, or additional training for employees. In addition, ongoing support may include troubleshooting problems, installing upgrades, and system backup. Support can also encompass technical support where your employees can contact your consultants when they need help using the system.

Your custom software application is an investment in your businesses future, and your consultant understands that. A well designed and well written custom software application can help your business remain competitive and moving forward in the business world. Consult Teximus to get started!

The post Installation of Final Software and Ongoing Support appeared first on InTune.

• Module Testing
• Integration Testing
• System Testing
• Acceptance Testing
• Site Testing

Module Testing:

In the previous issue of Info Point, we discussed module testing as part of the programming phase of a software development project. In a software application, each group of related screens that automates a business function is considered a software module. Modules are tested individually before they are combined with other modules. Module testing is important to make sure that a module works as designed by itself. The module should accept input and produce output without any errors. Programming in modules ensures consistency, simplifies training, streamlines programming, and facilitates changes. All these features of modular programming ensure that you get the custom software application you need, not a pre-packaged system that doesn’t help you meet your business objectives.

Integration Testing:

After a software module passes testing, it is integrated with other software modules, and the modules are tested together. As more modules are added to the integration, various parts of the system are tested to uncover any problems or errors early in the project. The earlier a bug is found, the less it costs to fix in time and money.

System Testing:

System testing is a critical phase of custom software development. During the system test, all the modules are integrated and tested together as one application. The main objective of the system test is to run the application in an environment as close as possible to a live environment with as little simulation as possible. If the system test is skipped, bugs may show up during acceptance testing or after the system has been installed. Training can also begin during system testing so that you and your employees can be involved in the acceptance testing part of the project.

Why is a bug a bug?

At Harvard University, on the evening of September 9, 1947, The Mark II computer was being tested. The test was not going well, and after investigation, Grace Hopper, who was serving in the Navy at the time, and her associates found a moth ensnared between two points of a relay. They removed the moth, taped it to the computer log book and indicated that they had “debugged” the machine. This was the introduction of the term “debugging a computer program.” The original bug, shown below, is now at the Smithsonian Museum in Washington, DC. Grace Hopper, who retired with the rank of Admiral from the US Navy in 1986, was a leader in the field of software development. She passed away at the age of 86 in 1992.

Acceptance Testing:

During acceptance testing, the custom application is demonstrated and tested to show that the system is what you and the consultant agreed to when you started this project. During acceptance testing, several criteria should be introduced that have not previously been introduced. For example, employees who will be using the new system and have used the old system should be involved in the acceptance testing. Also, real system data that has not been previously used in testing should be introduced to the system. During acceptance testing, you and your consultants make certain that the system you install accurately reflects your business processes.

Site Testing:

Site testing is done at your site with your employees. Site testing uses your equipment, your data, with no simulation at all. If the custom system is new, it can be installed and tested without considering any existing system. However, if the new system replaces an existing system, sometimes the new and old systems are run in parallel. In the case of parallel testing, you can use the output of the new system immediately, but you can switch back to the old system if you need to do so. You also can compare the output of the new and old systems to make sure they are identical. Once the new system is accepted, you can discard the old system and use the new one exclusively.

It can be exasperating to wait on hold for long periods of time trying to get through to technical support for an off-the-shelf software product. Even more infuriating is being told that the problem with the software is a bug that will be fixed “in the next release.” With custom software, you can work with your consultants to make sure bugs are found before your system is up and running in real time.

Ensuring Bug-Free Custom Software!

From module to site testing, we’ve got you covered. Contact DragonPoint for a seamless system aligned with your business goals!

The post Looking for Those Software Bugs appeared first on InTune.