Blog

  • Contractors or Employees? Options for Growing Your Team

    Contractors or Employees? Options for Growing Your Team

    In building a team one of the first questions that need to be answered is whether you will use contractors or employees.  Although this decision may be dictated by circumstances, it is important to recognize the pros and cons of each.  In the spirit of full disclosure, I have been a contractor for most of the last decade.

    Let’s look at the positives of employees first

    Loyalty used to be a huge plus for employees, but that seems to be less a factor every year.  However, an employee does still improve the likelihood of team continuity.  Employees may leave your organization, but it is more likely that contractors will move on.  This can cause a drain of business-specific knowledge.  Consequently, employees are more likely to give a return on the investment of training them on your processes.

    An employee also provides more ability for you to impact their attitude.  Never discount the productivity that can come from a happy and motivated employee.  There are steps you can take to make contractors happy.  However, you will have much more at your disposal to keep and motivate an employee.

    Contractors will sometimes talk about a partnership with their customers.  This is a good attitude to have, but at the end of the day, an employee is more closely bound to a company.  Their future is tied to the company success in a more direct manner than any contractor.  This symbiotic relationship does not guarantee everyone works together.  There are always going to be politics and personalities that drive a team.  Nevertheless, employees are at least going to have some shared benefits to come from a successful company.

    Finally, contractors tend to be project focused.  Your company may hire contractors for the long-term, but most will come in, focus on a project, and then move on.  This works for turnkey projects.  However, it is not the most efficient way to build a living, growing solution.  There are always ideas during implementation that get set aside but are valuable in future releases.

    Contractors have a different set of positive attributes

    It may seem cold, but contractors are disposable.  The investment made in a contractor should always be smaller than an employee.  Training and benefits are worries of the vendor, not your company.  A contractor should be primarily a short-term resource and it is usually easy to end a contract.  In any case, you let contractors go, but have to fire employees.  This has a lower cost no matter how you slice it.

    A contractor brings a new set of skills and experience.  Employees will have shared experience over time.  That is a strength of building a team but can also lead to a form of tunnel vision.  A contractor will have a different set of experiences and often can bring a new set of skills to the team.  They also will be on the hook to keep their skills current and marketable.  This can be a way to improve the overall skills of the team without paying for more training.

    One of the biggest strengths of using contractors in my experience is the ability to flex up and down those resources.  It is almost always easier to find another contractor than it is to hire someone.  You can also reduce contractor headcount quickly and reduce costs during slow seasons of business.  In fact, this is my most recommended approach to software development.  I recommend and have followed the process of building a core team that is small.  Once the team is in place, use contractors to handle peak or high-need times.  This keeps overall costs and commitments low while still getting work done.

     

     

  • Finding A Balance in Choosing Your Technology Tools

    Finding A Balance in Choosing Your Technology Tools

    One of the challenges we face when building a new product is the selection of the technology.  Finding a balance between a homogeneous or mixed solution can be difficult.  On the one hand, a single vendor is easier to work with.  However, on the contrary, you want to avoid lock-in, and single vendor solutions often lack the features of one built using multiple tools.

    All-In-One Solutions

    In my experience, a single technology solution almost never works for custom solutions.  Tools like Microsoft Access, FileMaker, and others that offer all-in-one solutions can be useful.  However, their use is limited, and customization can be painful, if not impossible.  That being said, simple applications like general accounting, address books, and catalogs are entirely possible with these tools.  These are solutions that need little customization and follow a sort of template solution.  These tools work, but often the end solution would have been cheaper to buy off the shelf.

    The cost of these solutions tends to be low as you can find resources that know the tool and have proven experience in it.  They know how to stay in the “safe” areas of customization and upgrades are often painless.

    Best-Of-Breed Solutions

    Another approach is to find the best tool for each feature or aspect of your solution.  This method often allows heavy customization and the ability to create your solution precisely.  However, there is a cost of integration.  The tools have to be made to work together.  Sometimes the “glue” used to put these disparate pieces together can be complicated to create and fragile once completed.  A change to any part of the solution could potentially bring down the system.  Upgrades become risky, and the pressure to leave things as they are can be enough to freeze the solution from enhancements and upgrades.

    The cost of these solutions can be very high.  In fact, this often is only a path open to enterprises and companies with a significant number of development resources.  It is very rare for one person to know more than a few of these sort of technologies.  Thus, there is often a need for at least a resource or two per technology.  Note that I said, “at least.”  Projects may require dozens of resources in each technology silo.  Keeping everyone busy during implementation requires substantial planning.  Therefore these projects can be challenging to manage.

    Finding The Sweet Spot

    There are more than two ways to view this problem.  So let’s look at the middle road.  Tools rarely are limited to a particular solution.  Thus, they will have strengths that can be used to solve other problems.  For example, a database can include business logic.  However, the front-end or User Interface tools can perform some as well.  Neither of these tools is likely to be the best way to implement business logic.  Nevertheless, it is possible.

    The key to selecting your technology stack is to find the best tools for your most significant problems.  These are the uses that will occur most often in your solution and have the highest impact for the customer.  To put this simply, make sure your key selling points are the features that work the best.  Likewise, these areas of focus should be the most stable, scalable, and easy to maintain.  You are not likely to spend enough time on ancillary features to focus on those solutions.

    Not Too Much and Not Too Little

    A single technology is rarely going to cover all of your needs.  However, a technology stack of three or four tools in tandem is very common.  This stacks can cover a lot of solutions without having to break the bank finding implementation resources.  When you use your technology choices in moderation it can keep costs down while still providing a complete solution.  It is a win-win for the company and the customer.

  • Cost Of Business – Components of Commercial Software

    Cost Of Business – Components of Commercial Software

    One of the first items of discussion with a client that wants to build an application is cost.  When they are new to the process, the cost is a complete mystery.  The wide range of resources available does not help this.  There are low-cost offshore providers all the way up to high-cost boutique firms.  However, the largest impact on the cost of an application is scope.  There are many components to consider, with some being more or less optional.  Let’s look at the components that should be addressed in some way for any real application proposal.

    Security

    A commercial application is almost expected to be secure these days.  However, a secure system is not a guarantee of safety, focusing on taking proper steps.  Customers will often have a checklist of items they expect to be a part of a secure application.  When you design and estimate your solution, each of these items should be covered in some way, even though this may simply be a note that the feature is not needed.

    • User Login and Account Management – Nearly every application requires some login functionality and a way to manage your account and password.
    • Data Security – Many uses of data requires that the data is encrypted or otherwise secured. Even when customers are not concerned about their data, it is good to avoid being the news due to a data breach.
    • Encrypted Data Transfer – A secure web connection (HTTPS) is needed to avoid warnings when a user connects to your site.  Also, Google has now made HTTPS an important factor in being considered a good site to rank in search results.
    • Single Sign-On/Third-Party Integration – This is a corporate application where users will want to authenticate using their Active Directory account or one that is more appropriate for Facebook or Google authentication.  In any case, customers are asking for easier ways to securely authenticate to their favorite applications.
    • Vertical Data Storage – This feature is not needed for all applications, but B2B software often will look for it.  The key is to be able to ensure that they will only see a customer’s data.  A bug that exposes data to other users can be crippling, so an architecture that makes this almost impossible will help sell your solution.
    An application that is a toy or game will not need to worry about these features.  However, even a simple calendar or address book application will need to consider each of these.  A decision will then need to be made about which to include and how thorough the functionality needs to be.

    Finishing Touches

    There are several components of a commercial software application that are critical but often overlooked.  However, these do get added in late in a project as the gaps are noticed.  Unfortunately, the late addition to the project is a common reason for these items to cause cost overruns and delays.  Consider these features from the initial design, and you will be more likely to avoid such issues.
    • Logos and Branding – This is often a larger problem for web applications.  The images used within your application need to be decided on and designed or otherwise properly licensed.  This step includes things like wordsmithing your notification emails, general messaging, and content, as well as look-and-feel.  Although some environments (e.g., A Windows or Mac application) provide standards and templates for many of these issues, there are almost always gaps to fill and decisions to make.
    • Notifications, Help, and Messaging – A big part of an application’s usability is how well it communicates with the users.  This communication is done through messages, email, help options, and more.  As an application moves from a demo to production, there should be a focus on making the notifications easy to understand and keeping the user informed.
    • Documentation – Developers are not known for their love of writing.  Thus, it should be no surprise this is another component that is often missed.  Whether the requirements are for a User Manual and detailed manuals or a technical guide, this is an important piece of commercial software.  We all know that no one reads the User Guide.  However, we also know that a product without documentation is probably shoddy or bug-filled.  A lack of proper documentation can hurt sales and cause support costs to be higher than expected.
    • Packaging – Even digital products need packaging.  This packaging can be install scripts, license keys, or even physical packaging.  In all of these cases, the final product must be put together in a way that it can be shipped.  Even membership sites will need a registration and billing piece.
    I have found this group of components to be the most likely to be overlooked.  Thus, these features are often treated as a change request or “add-on” that raises the cost and delays completion.  Make sure these are accounted for in any proposal.

    Maintenance

    This next group of features pertains to infrastructure and product maintenance.  Technically they can be avoided.  However, doing so is almost always going to contribute to future headaches and high maintenance costs.  It may even become an unavoidable barrier to enhancements and upgrades.  Ignoring these features is a good way to keep your product from ever being anything except a toy.
    • Logging and Exception Handling – This is a key differentiator between a coding team and a software development team.  All software hits snags somewhere.  These can come from a nearly infinite variety of sources.  Thus, good software cannot stop exceptions but instead handles them gracefully.  Errors and exceptions are handled and logged so the developers can look to avoid the problem in the future or even fix damage caused by a bug or glitch.  This is also a piece that is challenging to shoehorn in at the end of a project.  Take this component into account from the start of the project to avoid costly surprises.
    • Database design – Most modern applications utilize a database.  However, this does not mean all databases are the same.  The architecture and design of the database should be a mini-project in itself.  Assign resources and ask questions to ensure that the database is designed to handle the expected number of users and types of data.  The size of the data is also significant.  It should be clear whether the system will be handling thousands or potentially billions of records.
    • Backups and Build Scripts – This gets into the weeds a bit.  However, a professional product should include a disaster recovery plan and backups.  There should also be build scripts, and version control used correctly.  This may not matter as much to customers, but it should be critical for owners.  Think about building a house and then losing the location and ability to enter the building.  All that work becomes worthless.  That is what can be faced when building software that does not have version control and build process or script.  You may have access to the source, but the cost of building it and bringing your application back online may be more than you can afford.
    I must agree that these components have more to do with the owner than the customer.  Nevertheless, these are all critical in producing reliable commercial software.

    Avoid Surprises

    As you can see from this list, there are a lot of factors that go into building a commercial product.  If you are considering taking on something like this, make sure you find a reputable provider.  Ask questions and look at competing products to make sure there are no holes in the requirements.  The longer it takes to find these sort of holes, the more expensive they become.  Of course, you can always contact us at RB Consulting for a free consultation to get you started in the right direction.