Dump Truck Dispatcher is cloud-based software that can help organize and manage quoting, orders, ticketing, scheduling, dispatching, and fleet vehicle maintenance for dump truck hauling companies. It was initially written as an application for a large dump truck company in SC and then enhanced to be made available to similar companies on a hosted SaaS model.
In addition to providing this as SaaS, it could be used as a starter point for customizing an application for similar industries.
Dump Truck Dispatcher is based on the latest ASP.NET Core framework. It is mobile responsive, so it can be run from smart phones and iPads. It includes a driver application created as a progressive web application (PWA).
StrategicRM for Cloud-based CRM, Project Management, and Time Tracking
StrategicRM is a Customer Relationship Management system with project management, social, and marketing automation functionality. It was written in response to our inability to find software that met our needs. While we could find several different products such as CRM, project planning, time tracking, and accounting software, and cobble them together, this would result in excessive cost and double entry of some data. This product, which has not yet been released, will be made available on a subscription basis to people in need of this type of functionality.
The Recruiting Wizard is an applicant tracking program for 3rd party recruiters and internal recruiting departments. Recruiters could easily keep track of their job orders, clients, applicants, and match candidates to jobs. It was originally written in MS Access in 1998 as a very cost-effective solution for small recruiting organizations.
Although the technology is now dated and is not one we would use today, there are still a number of clients running the application, including those that the application was originally written for. This is a good example of how a well-written program can have a long lifespan with little maintenance.
In the early 2000s before WordPress was the standard blogging platform and before WIX existed, Portal Builder provided a way for construction builders to have their own branded website. This application was provided free of charge to builders by a bank that specialized in construction loans.
This custom web application was written in VB.NET using ASP.NET webforms with SQL Server as the database.
Our Members Church Membership Software
This is the home page that shows you the number of members as well as any upcoming activities or events.
The following view shows the detail information for a member.
The next view shows the related tasks, events, and notes for a member. All of the information for a member can be accessed from 1 place.
Below is an example of the detail for a meeting. Note how it also shows who will be attending the meeting.
Engineering Job Tracking
The Town of Tonawanda’s Engineering department needed a means to track their projects and the time and cost associated with each project. This application, which was originally written in MS Access 2 in 1997, has stood the test of time. Aside from being upgraded twice to newer versions of Access; the application has not required any additional maintenance. See what our client has to say about the program here.
Eighteen years after it was written, the application finally reached its end of life. Microsoft released some changes to the latest operating system that required a rewrite. Since the original application lasted as long as it did, we were awarded the project and had the pleasure of rewriting the application as a web application.
Configurator and Quoting Tool
Configurator is a custom software program written to support a product used to allow people to configure complex products and create proposals. For example, in one case it allows hospitals to visually configure beds and accessories for the beds.
Golf League Software
This custom software application is used by the Twilight League Golf Club to manage their membership and league standings. It was originally a VB6 application with an MS Access database. It has now been rewritten as a Windows Forms program (desktop application) that is written in C# and uses Entity Framework with LINQ to access the SQL Server 2014 Express database.
How to Keep Your Software Project on Track
In software project management, communications is key to ensuring that your project will be successful. It keeps you up to date with how the project is proceeding, shows the developer that you care about the project, and that you are willing to get involved to ensure its success. Providing rapid feedback to your developer is important to keep the project on the tracks. It also provides a means for holding the developer accountable.
Communications can be done through numerous methods such as phone, Skype, email, project planning, issue tracking tools, etc. The key is that you get regular updates, and that you have a central place to keep track of features and defects. I require daily status reports from the developer even if it is only a sentence in an email. For most projects, a daily scrum meeting at the beginning of the work day will get everyone started on the right track every day. If a developer is not going to work on a given day that they are normally scheduled to work, I expect a quick note that they will be unavailable.
For keeping track of features and defects I prefer using Visual Studio Online. There is a free version of Visual Studio Online for small teams of 5 or less. For more info go to https://www.visualstudio.com/
For really simple projects, you do not need these project tracking systems. However, if your product is more extensive, you will need to have some means for keeping up with the features and defects other than email.
When you are provide feedback, make sure that you are giving positive feedback when warranted. Developers like hearing good things. All too often, all the developer hears is “this is broken” or “this doesn’t work right”. Try to give at least as many compliments as you give criticism. It makes the developers happy and willing to try even harder to please you.
Get Working Software Quickly
In addition to making sure you are effectively communicating with your developers, you should also try to have working software as early in the process as possible. This applies to software that has minimal functionality. Ask the developer for demos early in the process. If it is a web application get your hands on a version that you can play with as soon as possible. The developer should be able to update the website regularly with little effort. If they are doing it right, this build process should run automatically after every checkin.
As was discussed in the previously, use feature and issue tracking software to keep the project on track when appropriate. Regularly review the status and make sure the developer is in the habit of keeping the work items updated and passes them along to you for review when done.
Stay Actively Involved
Stay involved in the project on a daily basis so you will know when things start to fall behind. Address problems early. The sooner a problem is identified, they easier it is to correct. Try to understand the issues so you can see how you can help. Is the issue that the developer really doesn’t understand what he is supposed to do next? When developers aren’t sure what to do they often procrastinate and move on to work on something else that they understand. Some developers are slow to ask for help and may spend too much time fighting with an issue. Ask them who they have reached out to to solve the issue. Ask what their plan is to fix the problem.
If the issue isn’t related to understanding or to a technical issue, determine if the developer is having other problems, possibly personal, that are keeping them from focusing on the application.
Will Your Software Development Project Be a Success?
Unfortunately, a large percentage of software development projects fail. These statistics can often be daunting to someone taking on a new software project. That’s why it is important to understand the definition of failure as it is different for every project, and is based on who is defining the success or failure. For example, to a business, the definition of failure might be
“The project does not meet the needs of the business unit at the desired price and in the specified time frame.”
How many projects do you think meet that definition? Very few software development projects succeed on all of those fronts – functionality, time, and money. You could in fact fail by that definition but still have many happy users. They may love the program and not know that the program cost twice as much as was budgeted. So the majority of the people may not even know that it failed. The point here is that even with happy users, you may not get more work from the company because the person paying your bill might not like the cost overruns. All this is to say that failure is hard to define, and you have to look at it from many perspectives in order to truly define whether or not your project is a success.
In addition to things like happy users and getting the project done on time and on budget as promised, you must also be a winner in the deal. If you were not compensated sufficiently, then would you call it a success? When dealing with your clients, employees, and vendors, you should always be looking for win-win scenarios. It is never good when one of the parties feels like they have lost.
Creating software involves trade-offs
No software is perfect. The more features you add, the longer it will be before you can release the product. Many companies spend so long in developing the product that they run out of money before they can release the product. Besides, if you release a minimal set of features and get it into the hands of your users, they will be better able to give you feedback and direct you in what features are most important for the next release.
It boils down to whether the user would prefer to have good, working software today or perfect software at some point in the future.
Know when to stop
Adding too many features can be as bad as adding too few. These added features that may rarely be used can make it more difficult for the user to get to the features that are used frequently. They may also cause confusion and can be a cause of bugs. Every added line of code is another opportunity to create a bug.
Listen to your client. Ask probing questions. Give your client the spotlight for at least 70% of the time during initial conversations and listen to their answers. They will tell you what they want.