DEV Community

loading...

Observations of a Business Owner by a Code Cruncher

wstocker profile image Wendy Stocker ・2 min read

Throughout the years I've worked for many companies both for agency style businesses as well as internal developer for larger organizations.

Along the way I've noted some growing pains and learning experiences that business owners have gone through while adjusting their business practices to meet the demands of the market.

Now to preface this, understand that one of the biggest expenses a business owner has, is the cost of an employee whether the organization be small or large.

That is why it's SO tempting to want to...

Outsource the labor to a non-US based labor pool

I cannot tell you how many times I've seen companies make this mistake. Either it be the person who was hired on to clean up the legacy code, or untangle a huge mess that something like this has created. In the long run it always ends up costing the business more than it saves. A good rule of thumb to remember is you always get what you pay for.

Second mistake, if they already haven't made the first is to...

Strip down costs and operate on a skeleton crew

This is often painfully felt by workers the most. In this kind of situation no one really wins. If your developers are spread too thin they are going to produce subpar work that isn't well thought out and could create more issues in the long run. While an application might be visibly functional on the front-end, yyou can bet your booties that there are some skeletons being created in the closet on the back-end. Often when developers need to cut corners to meet a deadline, things like security, documentation and QA will be sacrificed to get something done on time. Eventually those problems are going to surface whether it be now or later.

Third issue that can make your organization suffer...

No clear process in place and skipping over documentation

Many companies that produce tech have converted to an agile or at least agile-ish structure and process. Although I initially found this structure a bit intimidating, it was something that ended up being crucially beneficial. Agile methodologies really help developers create meaningful work that they are excited about. They also help them to create more accurate estimates by not pinning them down to an hourly deadline, while accounting for a certain amount of unknown or discovery that goes into developing a project especially if it is a new API or technology that you haven't worked with.

Documentation is often something that gets prioritized last which is indefinitely important. With good documentation you can easily avoid hellish scenarios where everyone is going to that one developer that has been there for years to find the most basic of information and everyone cries when they take the day off.

A good company to work for is a successful one

A good company to work for is like a well oiled machine, capable of meeting the demands of the market while producing a high quality product. Cutting corners, although extremely tempting will inevitably lead to the decay of both quality and culture.

Beware business owner, beware! :)

Discussion

pic
Editor guide
Collapse
ddarrko profile image
Daniel Benzie

Rule of three springs to mind

1 hour writing code
2 hours writing tests
3 hours writing documentation

Although it is basically impossible to adhere to that from my experiences.

Collapse
wstocker profile image
Wendy Stocker Author

Definitely. It is sometimes overlooked how adaptable developers need to be to get something done!