How Not to Get Screwed Over as a Software Engineer: Part 1 — Contracting Woes
Sigh.
I wish I was here today to talk about my favorite tech stack. I wish I was here to talk about the latest improvements to my Android app codebase by implementing Kotlin co-routines, or a nifty new trick to organizing my unstructured data in an elegant manner with Pandas DataFrames for my python projects.
These things (and things like it) are what software engineering should be all about. Some people like to believe that’s all there is to it. That’s all you have to care about in this magic world full of sunshine and rainbows and binary digits. Especially if you are new to it.
But, let’s be real for a minute…
Make no mistake, for as awesome as creating something is that people use, and enjoy using — at it’s core, software engineering is 99.89123% about money.
Getting that fundamental premise out of the way, there are a few rules to remember whenever you are dealing with people and money and contacting (and by extension software engineering):
- People will always try to get the most product possible for as little cost as possible. This is nothing new or unexpected. You, me, our loved ones, strangers, everyone does it. Just ask Robert Kiyosaki (but don’t ask his Poor Dad).
- A smaller subset of people will try to get the most product as possible for as little cost as possible, at the expense of others.
- The above said smaller subset of people are usually the most successful in the contract business world, no matter how they try to paint themselves, as “for the concerns people” or being “ethical actors” or “heros of the common folk”. Remember: Sharks are the apex predators, but they have the widest grins.
- Software engineering is basically a business. Contracting is a business model. When those two things collide, someone is BOUND to get screwed at some point in time. In fact, this statement should be codified as a “law of nature”. And if you have a counter example, I guarantee, upon further scrutiny, from an objective authority in contracting law, you’ll see that my above assertion, is invariably correct.
Disclaimer (yet again!): NONE of this article is legal advice. I’m not an attorney and I’m not responsible for the outcome of you following any of this advice! Consult an actual lawyer if you are planning to do any kind of contracting.
The Anecdotes
Here are some situations I ran across. You might have had worse, but hopefully better experiences. I’m not an expert on any of this stuff, but if someone can relate to or learn from the things I’ve mentioned, I’ll be happy.
Several years ago, at a time when I was exploring contract work as a means to obtain supplemental income, I found a number of clients that wanted my associates and I to build mobile apps and websites for fun and profit (but mostly for profit).
The common thread amongst all the jobs that came my way, was that the various apps had to be built as closely as possible to an existing iOS/Android version of the client’s website, which they often had already built to various stages of completion. I won’t go into the specifics of any of the several contracts I was involved in, or even the conclusion of the associated stories. I’ll suffice it to say, that the troubles that I experienced gave me some very insightful take aways on how to deal with independent contracting situations in the future.
Here they are…
Heuristic 1: Never accept a Non-Negotiable Flat Rate contract if you can avoid it.
This should be a given right? You’re probably thinking right now “If these are the ‘insights’ that you are providing, then I might as well save myself a few minutes and stop reading this trash”. I wouldn’t blame you. I mean this is common sense right? Why would anyone voluntarily box themselves in like that? To be frank, I had severe reservations in accepting contracts under such a premise. But I was over-confident, and wanted to impress the clients but working with a really constrained budget in a really constrained time frame. After all, I was trying to be forward thinking. I was like “It’s not about the money now. Once I get my name out there, with enough impressive recommendations, I can then be more flexible in what I ask for. I just need my foot in the door”. A lot of younger and newer people accept exploitation based on this same premise. That “if I just demonstrate my value, then…the world will see X,Y,Z in me”.
Unfortunately, as much as people try to push the positive thinking, Tony Robbins stuff, and try to get you to believe that your worth comes entirely from within (a lot of it does but…), in the world of business, and money, there is very little you can do to get around this perception that you are only worth your volume in good recommendations.
This means, in order to prove yourself, you’ll have to stretch yourself thin, and in some cases, for peanuts. But what I learned is that even though this dynamic has been the case since time immemorial, that you can do things to protect yourself to an extent.
Firstly, if, despite any warnings, you’re intending to accept a flat rate contract, always try to have a line in your contract language that reads something like “Flat Rate with the ability to negotiate for ‘Billable Hours’ based on extenuating circumstances”. If your potential client does NOT want to give you the ability to negotiate, or wants to make it difficult to negotiate, even a little, then in my opinion, this is a HUGE red flag, and demonstrates, almost definitively, that they *mindfully* intend to exploit you. If you’re still willing to accept such terms, then be prepared for a lot of heartache. (P.S. Make sure you have a legal expert review any and all pieces of a contract)
By the way, one of the most controversial, yet fundamental phrases in contracting vocabulary, is “billable hours”. Billable hours can lead to exploitation of the client and the contractor both, which is why there is typically a ton of legalese around creating a contract that explains exactly what billable hours means to the different interested parties.
Moving on…
Heuristic 2: Always, always, always, have the contract spell out the EXACT details of ALL the individual pieces of work that are to be required.
This was the biggest one for me.
Again — it seems like common sense right? But the devil here, is truly in the details. For my specific case, several of the contracts I had were “to have the Android/iOS App function just like the iOS/Android App”. For anyone that has spent any amount of time in the world of app development, this is far easier said than done-even in the case of the “dumb client”. This is why cross platform solutions like Flutter or React Native are becoming more popular, however imperfect as they still are.
I’ll give you an example (though I can give you quite literally DOZENS).
On one of my apps, there were was a requirement to add a feature for “Fetch Profile Via LinkedIn” to the app. “Fetch Profile on Via LinkedIn” worked a lot more smoothly on iOS, than Android (at least as of the time when we worked on that feature). The amount of time to implement this feature took around 10 times longer than it did on iOS. However, due to the constraints of the contracts, we were expected to accept the same amount of pay. At the time, I believed that I’d still be able to finish the rest of the contract, with this dent in time having minimal impact, and we could write it off as a courtesy. That might have been possible, if a bunch other issues in a similar vein didn’t show up during the course of the contracts.
There were also several features in the various existing apps and sites that weren’t explained as was having existed once development started on the project. For example, there were hidden data features, hidden popup modals that got triggered under very specific circumstances, hidden alternative app experiences based on user profile data, just to name a few.
On top of that, the apps had feature creep, which we constantly had to call out as being as not part of the original contract. Sometimes we found that certain features that we missed, in fact, were part of the original apps. However, in such cases, it was never actually pointed out when we first priced the contract. These were not evident features, and I believe they were excluded from the initial explanation of the apps’ required features in order to prevent us from increasing the initial price estimate - sort of sneaking it upon us, which is shady to say the least. I could be wrong in a few of the cases, just a hunch.
In many cases, I really couldn’t prove this last statement on paper (partially because my formerly lax attitude to meticulous record keeping). And because of that oversight, there is enough plausible deniability for several of my clients to say that this wasn’t the case. Over the years, I’ve tightened my record keeping process in response.
Again, in these situations, I could have backed out of the various contracts, but I was still in the “hustle” mindset, and figured I’d have more leverage at a later date to push back. Unfortunately, that idea never manifested to the extent that wanted it to.
Also, the sunk cost fallacy quite often came into play, and I believed that quitting early would be abandoning all the work that was put into the apps I worked on. So often times, we chose to stick it out in a far from ideal situation.
Heuristic 3: The expectations to meet hard dates for contracts MUST be qualified with language that places responsibility on BOTH the contractor to meet their obligations AND for the client to meet their obligations.
Over the years, I’ve had several clients that had the attitude that went something like: “We’ll validate your work, but when we get to it, it better work right”.
That makes sense, if you were a regular employee, getting paid by the hour. But if not, then you are essentially sitting there waiting for work. You might further ask “what’s wrong with that, especially if you’re getting paid?” For many, that’s not a problem. But as a busy person who has to hustle, you are likely working on several projects which have several deadlines and other competing concerns. When the particular client says “Jump when we say jump”, that means, in addition to having no concern for your other projects, they are not taking any additional financial responsibility for the disruption it causes you as the contractor.
The problem herein goes back to the flat rate contract. If they are only willing to pay you when they say something is “Complete” and not before — weeks, or even months later, you still might not have gotten paid, because they will find additional bugs with your work. They can use that as a premise to continuously defer payment “the feature is not complete”. I don’t know about you, but to me, that’s annoying at the very least.
There needs to be a commitment to be responsive on feature validation from the client (for feature by feature projects), written directly into the contract.
Furthermore, given a long enough time technology changes. Take APIs for instance. A number of times you could be working with a clients api (presumably one that they used to power their other thin clients) or an external api. If a feature was working when you finished it, but a client took their sweet time to validate it, if the API suddenly stopped working, then it could break your feature, and that’s additional time on your end to fix it with NO EXTRA PAY because of the flat rate contract.
So you should try to get the contract written in such a way that
you as the contractor “are not responsible for additional costs that are incurred by the client, due to delays in client validation of open tickets”. This helps to keep everyone on the ball.
Heuristic 4: If you must do a flat rate contract, then be sure to include a line about bug fixes, even if they are to existing work, being additional labor.
Obviously, this doesn’t give you the right, as the contractor, to do a bad job, and then demand additional money because of your failure to deliver the original request.
But bugs happen, and there should be good faith understanding from both the contractor and the client that these bugs should often be considered as ongoing work. This should be negotiated on a case by case basis, but by no means, don’t allow the client finding bugs (especially small non-critical ones) here and there delay payment. Even though it’s time consuming, it’s worthwhile, I think, in many cases, to spend the extra time to segment the cost appropriately. It can help you avoid the feeling of being screwed over.
PLATFORM PARITY: Do not let your client make presumptions on when work should be completed, and how much to pay you, because the original platform you’re copying from should be “simple to just copy”, or some non-sense this effect. While this can be true for simpler applications, I find that generally speaking, it’s not the case. This should be spelled out very early on , and should somehow be worked into the negotiable elements of the contract.
Heuristic 5: Make sure you have a legal expert review any and all pieces of a contract language! I’m not a legal expert, but they are available just for this specific need.
So that’s it for now. I hope some of this helped.
I’m no longer a regular contract worker, as full-time employment is far more satisfying. But on side projects that I work on or contribute to in the present day, I find that taking these heuristics into account, has allowed me to save myself a lot of headaches.
