Blog

  • 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.

  • Key Attributes of A Good Team Lead

    Key Attributes of A Good Team Lead

    A good team lead is hard to find.  Unfortunately, it is a struggle required when building a team of almost any size.  The good news is that the traits that make a good lead are easy to spot.  Once you find someone that possesses these make sure you keep them happy.

    A Good Team Lead is a Communicator

    As obvious as this may seem, it is also the most critical trait.  A Lead communicates with customers, management, and staff.  Although the Lead may want to “work” more and “meet” less, communication is always a big piece of their daily tasks.  Communication is not limited to one channel such as email, phone calls, or in person meetings.  A good lead can communicate successfully in any medium.  Communication through various means is critical to success.  Those they communicate with will utilize all of these channels.  However, written communication is the most important.  A good lead will leave a paper trail of discussions and decisions.

    They Are Comfortable in Many Roles

    A Lead is asked to take on multiple roles.  They will handle customer interaction, but also help design a solution, implement, and test.  When you have a good team lead the group works better together and stays focused.  Thus, you need to ask a broad range of questions in an interview.  Find out how the candidate thinks, test their ability to react and switch gears.  When reviewing existing staff to move into a lead role, look for people that stretch out to other groups and interact with more than their peers.

    A Good Team Lead is a Team Player

    Anyone that s placed in a leadership role will potentially focus on their career rather than the group.  A good team lead cannot fall into this trap.  They need to do the things that keep the team focused and working towards a common goal.  There is also a bit of a cheerleader aspect to such a lead.  They keep up morale and look for solutions rather than blame or excuses.

    They Are in Synch with the Customer

    The factor that might be the most important is being on the same page as the client.  A good team lead has the customer’s best interests in mind and understands their priorities.  This is a crucial piece of all the other attributes of a good Lead.  This quality helps communication, direction, and team management.  When a team lead is no the same page as the customer, the likelihood of project success goes up.  Coincidently, the frustration levels of those involved in the project good down.  Agreement between the implementors (personified by the lead) and the customers reduces overall friction and reduces the likelihood of scope drift.

    There is more to a good team lead based on particular circumstances.  However, these attributes seem to be universal in my experience with people that have excelled in the role.

     

  • Using a Clickable Demo

    Using a Clickable Demo

    One of the challenges with any project is getting everyone on the same page.  Over the years I have found that the best tool to help solve this problem is a clickable demo.  The demo is so useful it is one of the first steps in a new project.  Creating the clickable demo can be simple and straightforward or a big effort in itself.  However, these actions make even a complex system easy to model.

    Go With the Flow

    An important part of a clickable demo is an example of the application flow.  When use cases are properly done, they should be a stepping stone to the application flow.  The use cases will not provide all of the details, but a good demo will address every user story.  The look and feel of the demo are not as important initially as the flow.  It should model how a user will progress through the application while providing a rough approximation of the data they will be presented.  General navigation should be worked in early on as well.

    Look For Important Details

    Some requirements are more important than others.  The requirements that a good clickable demo presents include those around data input and output or reporting.  When a customer is reviewing a clickable demo, they should be able to tie steps into current use cases.  This link is best accomplished by showing details around each step.

    For example, let’s consider an application that includes data entry and search for entered records.  A good clickable demo will show the input fields as close as possible to the end product.  This should be at least eighty percent of the requirements for data entry.  The search, in this case, should allow a search on enough of the data entry fields to be easy to find any given record.  A customer should be given an example of how difficult or easy the interface will be for regular usage.

    Leave Room For Discussion

    The purpose of this demo-based approach is to provide a focus point for customers.  Don’t be afraid to leave a few areas open for interpretation.  Also, avoid getting designed into a corner.  The demo is not production code so spending a lot of time on it may be a wasted effort.  As iterations of the demo are presented there will be areas that become concrete, but early on avoid lock-in where possible.

    The Danger of a Clickable Demo

    I started with a claim of this approach being perfect for any project.  That does not mean it is not without risks.  The most common issue with a demo of this type is that it is “too good.”  In this situation, a customer falls in love with the demo.  The result is not a criticism, but instead something along the lines of “when can we ship it?”  This tricky situation can be avoided by clearly stating smoke and mirrors and lacking functionality during the walk through.  Set the expectations early, and clearly, so there is not an underestimation of the effort required to make the demo fully functional.

    The problem with a vision is that it is not reality.  Thus, everyone is left to their interpretation of the goals.  Try a clickable demo next time to bring a vision into reality early in a project life-cycle.  It will make discussions of the vision much easier and will help avoid misunderstanding of conceptual features.