Hiring a Software Consultant?

Posted on by chris

Hiring a Software Consultant?

Hiring a consultant for your business can be a little uncomfortable. You have a contract that protects your business, but what if the consultant is just… bad? There are a few tips and tricks for identifying a less than stellar software consultant and this article will cover those.

Low Balling

Whether your project requires temporary help or more long term, beware of consultants that bid low. There’s an axiom that states “you get what you pay for.” Some software consultants purposefully provide low estimates. These low estimates may seem like you are getting a bargain, but beware that those consultants make up for this low estimation through scope change fees and additional customization fees. These fees quickly add up to be well more than the original estimate. Be sure to get multiple quotes from software consultants before hiring and compare their experience with their rate. While the cheapest consultant may look like a great choice, the more expensive consultant will save you surprise billing and additional headaches in the end. Realistic cost estimates may seem expensive, but it’s a more accurate representation of what you will end up paying. You can also help protect yourself from purposeful low bids by building into your contracts some wiggle room for specifications on scope and requirements. You should also get a feel for your consultants on how flexible they are before hiring them.

Bait and Switch

Some consultant firms lure clients in by showing off their star performers. This helps justify a higher price and makes the firm more attractive. However, these firms increase their profit margins by bringing in junior developers to do the actual work. Sure, the seasoned engineer might be some part of the development process, but the time that engineer spends on your project is severely limited. You should meet the entire team that you are hiring. At the end of the day it is your product you are paying for. You should interview the team to get an understanding of their competence for defining requirements and developing solutions. Your contract should explicitly list the developers that shall be working on your product. Including a hefty penalty combined with listing explicit team members should dissuade the more devious firms from attempting this ploy. Teamwork makes the dream work!

Communication Breakdown

Good communication is necessary to complete a project. Great communication is necessary to complete a great project. When you hire a consultant, be mindful of lacking communication. No news is not good news with your consultant. You should be driving conversations and making decisions. An unseasoned consultant, especially when paid hourly, may find no incentive of coming up with a decision or ending a long, drawn out meeting. Your decisions should have a clear deadline of delivery or schedule with defined, time-bound milestones. Without a time based factor driving the schedule, an unqualified consultant has room to draw out the project bleeding your company of your cash.

What’s Yours is Yours

When you hire a consultant, you are opening up vulnerability in your character, your trust, and your company. The consultant that is working for you is creating something that should be making you more money than the investment in hiring the consultant to complete the project. Your contracts should protect that vulnerability. The intellectual property rights for products a consultant creates should remain the company’s. You should lay out any tools or processes to help protect that property. Some consultants may try and hold your product, equipment, servers, and accounts hostage. This can become especially problematic when you try and replace the consultant or even add more consultants to the team. Be sure to include in your contracts that the company retains the intellectual property rights for anything developed and^[[C any domains your register. Check with your contract author to determine additional safeguards against having your company held hostage by a bad consultant. Demand copies of any documentation, licenses, and credentials for a consultant as part of the contract.

Project Vampires

Nothing is worse than hiring a consultant that looks great on paper and has talked the talk only to find out they can’t walk the walk. This is probably the most common problem I hear from companies that hire bad consultants. A project vampire is typically someone who is either unfamiliar with a technology that are supposed to be an expert at or someone who cannot make a decision and stall the project while they “figure it out.” Both scenarios are bad news as every minute that ticks by “figuring it out” leads to higher billing. On the flip side, the company itself could be that vampire with not making direct decisions and communicating those to the consultants (communication is key!) as well as keeping those consultants accountable with deadlines and milestones. Decision by committee is rarely productive and as the project drags on, the bill will increase as the consultant is waiting to hear back or busy “figuring it out.”

Teamwork Makes the Dream Work

This is my axiom. As a consultant to your business, I act as a team member for your product. I communicate early and often on anything I don’t understand, I’m not familiar with, and and concerns I have over the technical direction of your project or existing infrastructure. I do respect your business and the decisions that go into operating it. After all, it is your business and I’m helping your achieve your goals. Communication is key to a successful project and I communicate… often. I also share ideas on technical direction and can step back if there is a technical direction already in place. I can work with existing team members (including other consultants) to hit your goals and deliver a quality product. My time is as valuable as yours and I don’t prefer to waste my time or your dime for endless meetings or over analyzing solutions. I do prefer to help your business succeed. I advocate for your business when necessary to ensure you retain what is yours and you don’t over pay on shoddy work or vampires.

Teamwork makes the dream work. If you are looking for a consultant for your project contact me below:

    Eisenhower Matrix

    Posted on by chris

    Eisenhower Matrix

    I’ve had my share of projects in the past. With each project comes a bit of unknown terrain, deadlines, known tasks, known risks, unknown tasks, unknown risks… the list goes on. It’s hard prioritizing everything as it comes in for a project and backlogging this prioritization becomes a huge burden. I’m sure your project backlog (or your at home to do list) is massive and any attempt to start tackling these things may become overwhelming. Fortunately, I’ve found a rather interesting tool to help: the Eisenhower Matrix!

    • Eisenhower Matrix
      Your backlog just got easier.

    The Eisenhower Matrix was created by Dwight D. Eisenhower, the 34th president of the United States. During his presidency he launched DARPA (the precursor to the internet) and NASA. He was the Supreme Commander of the Allied Forced in Europe during World War 2, and the first Supreme Commander of NATO. This guy was busy! He also had to make a lot of decisions quickly. This box was his tool do accomplish all of these things.

    The concept is simple, for a given task, determine if it is urgent or not urgent then determine if it important or not important. Once you figure those out, place the task in the appropriate box. Wherever it lies, you either Do it, Plan it, Delegate it, or Eliminate it.

    Consider something on your household to-do list: grocery shopping. It’s urgent if you are out of food, it’s pretty important unless you have some other means of feeding yourself, perhaps a garden or maybe you already have food. If you do have food, it may not be as urgent, but is still important. If you don’t need food right it may not be urgent or important. In either case, you must determine if you need to go now, can plan on going later, can delegate something else to handle your shopping (maybe Amazon pantry?), or if you have a garden that can sustain you, it might not be urgent or important at all and you can completely eliminate it from your to-do list.

    Once you completely process your backlog in this manner, you should have (hopefully) eliminated a bit of it. Maybe that deck you want to build can be delegated to a contractor. That room you want organized planned for a day to finally get it done. And that oil change that’s overdue, you’re at the shop today getting it done. This process of backlog grooming can be repeated each week (or however often you want to do it.. be sure to put that task in the right box!) but the process should at least help you see the priority in the items in your backlog and help you groom it to a manageable state. Anything you want to add, make sure you put it in a box!

    Strong Opinions, Weakly Held

    Posted on by chris

    I believe in three core values to any successful team and/or project: communication, collaboration, and transparency. Communication is a key aspect to successful teams because it keeps everyone involved. Communication drives ideas. Ideas are the seeds of change and communication gets them planted. Collaboration brings the seeds of ideas to growth. Teams that are not collaborative suffer from infighting and become unproductive and resentful of a project. Team members want to be part of a solution and collaboration is the vehicle everyone must ride in to reach success. Transparency is the last leg of a successful team. Transparency requires both communication and collaboration. Transparency requires each individual team member to know the difference between what they do know, and what they need to learn. Team members who are transparent in their skills ask a lot of questions. The answers to these questions are often helpful for other team members as well. Transparency is also about owning mistakes, addressing them, and learning from them. Every failure comes with an opportunity to learn. One never really fails if they seize the learning opportunities afforded by failure and grow from them. These three core values I hold are what I instill in my teams.

    Recently, during an interview, I brought up these core values and followed up with a quote I feel expresses not only these three values, but my thoughts on being a team member: “Strong opinions, weakly held.” This can also be rephrased as “Strong opinions, loosely held” and they both mean the same thing. I bring strong opinions to a team backed by experience and learning through many failures. Learning from these failures strengthens particular opinions, but they still remain loosely held. These opinions are meant as a starting point for collaboration or as a learning opportunity for myself and any others who may not have experienced what brought about these opinions. These opinions are meant to inspire creative thought and collaboration, not as a rule of thumb or “set in stone” requirement. These opinions are loosely held.

    The flexibility of a team is important to adapt to changing requirements, processes, deadlines, and outside obstacles. Rigidity is a project slayer. I may have strong opinions on a topic (say, using a REST API vs an unstructured one) but these opinions are meant as a conversation starter to discuss a solution to a relevant problem. This conversation solicits input from the members of the team. It provides a platform for other opinions and a better solution. Sure, that solution may be an unstructured API, and that’s okay. But, the point of bringing up strong opinions is to start that conversation, not lay down the law. If there wasn’t at least a conversation about API design (or any other implementation) in the first place, the team could move forward in a rather meandering manner. The project could take an intangible hit to be discovered later as it accumulates technical debt. Communication about a project direction reduces this debt and lets a project be more flexible during a time where flexibility comes easy.

    In the interview, I failed to accurately describe “strong opinions, weakly held.” This article is me learning from that failure and really taking the time to think about that phrase and how it can be perceived by others. When I came across the phrase it resonated with me as it so succinctly underlined my core values of communication, collaboration, and transparency. To me, it’s a positive attribute to have. Using that particular phrase became a strong opinion of mine. Maybe in the future I won’t use this phrase without following up with exactly how it aligns with my core values and what I look for in a team. The only thing I know is that I don’t know everything and I am definitely open to learn. I have strong opinions for sure, but they are loosely held.

    Version Control

    Posted on by chris

    Version Control

    I’ve been working as a software engineer for over a decade. In my time I’ve worked on projects that had version control in place and projects that had no version control. While I believe all projects should use version control, I have come across some projects that don’t see the benefits or value. This article aims to highlight the benefits and value from using version control and the pitfalls of no version control.

    What Is It?

    First, what is version control? It’s essentially a library for your code with a specialized database tracking all changes to any file. This type of tracking provides insight into your code in terms of changes, thoughts about changes in the form of comments, and overall visibility into how your code changes over time. It also allows using your entire code base at any single change. This becomes helpful if a breaking change is introduced to your code, you can always roll back to a previous version. It also helps your developers identify the exact change that introduced a bug.

    Why Use It?

    As mentioned, it does provide some innate capabilities like rolling back to a previous version and viewing changes to code. It also handles complicated code merges in the event 2 people change the same code. This type of code merging makes things easier and faster over teams that do not utilize version control systems. Take an example I’ve experienced in the past during my early years as a software engineer:

    The team was small (3 people) and the project was simple (a simple website). This was the days of FTP clients and deploying your website was accomplished by drag-and-drop to your web server. Simple. Easy. Clean. Right?

    Well, with 3 developers we decided that the web server would be the stand in for the most current version of the website (after all, it’s what everyone on the internet was looking at). Things immediately became more complicated. If a developer was working on something, they first needed to copy the files from the web server to their local machine, make their changes, then copy the files back to the web server. Hopefully no other changes were made in the meantime. When changes were made (and the most definitely were) the developer would have to copy the files from the web server (again) back to their local machine (in a different folder), talk to the developer (or developers) that made changes to figure out what they changed, and manually merge changes in those files affected (timestamps definitely helped). When that was all done, they would have to the web server again for changes. Sometimes, more changes were present and the whole process of copying, talking, and merging needed to occur again. This cycle repeated itself until the timing of being ready to copy to the web server and no changes on the web server aligned. This could take a few hours.

    We were naive of version control systems at the time. Once we discovered one (Subversion in this case) it made things infinitely easier. Developers would check out the main branch of the repository, make their changes, then check them in. Merging happened automatically most times unless 2 developers were working on the same code. In this case, the source control manager would present the conflicting changes in an easily readable visual manner and allow the developer to pick and choose what the final file would be. After this merge, the developer could test the changes before committing everything back to the repository. If a developer made changes before the commit was ready, the source control manager knew and the developer would update their code from the repository. Again, merges generally happened automatically at this point, but in the rare case a conflict would arise and the visualizer would present this conflict to the developer. This cycle rarely happened because the whole process was fast, easy, and efficient. When a deployment was ready, a tag was made in the repository and that specific tag was checked out on the web server. No file copies were made any more, no FTP clients were involved, and everyone knew exactly what was on the web server at any given time and if any of the files on the web server had changed.

    Wrap Up

    I find version control systems a necessity for a successful software development team both in terms of efficiency and cost. Less time working on frivolous things equals less money spent! If a team insists on not using a source control manager, maybe that team hasn’t yet experienced anything negative impacting their development efficiency. I use source control for all of my projects regardless of team size. It’s beneficial for a team of 1 just for the ease of code tracking and visibility into bug introduction. If you’re not using source control, I strongly urge you to adopt it!