Tag: business

Remote work has grown significantly since the COVID-19 pandemic. However, while many young workers are eager to embrace this change, there are numerous challenges workers should consider before they commit to remote-only jobs.

Larger Pool of Competitors

I live in a relatively small community. As such, there is a limited pool of both qualified workers and tech jobs. However, when jobs become remote only, the pool of job seekers can include anyone. Thus, remote workers will need to be far more knowledgeable in order to attract the attention of remote employers. Furthermore, this larger pool of candidates means that employers can seek out value candidates that may work for far less than you’re seeking. In this instance, the business benefits from remote workers due to smaller office costs, better quality candidates, and the potential to pay less. Conversely, the candidate may see fewer opportunities for less money.

Easier to Outsource

Beyond finding candidates in within the United States, remote jobs offer employers the ability to outsource their work to Latin America, Ukraine, Southeast Asia, or other areas with significantly smaller wage requirements. As above, this is actually a benefit for the employer and works against domestic workers finding jobs that pay fair wages. Even if employers choose to keep those jobs in the US, they can find developers in cheaper regions of the country. Because outsourcing can be significantly cheaper than domestic workers, a trend toward outsourcing could threaten entire industries of workers (such as computer professionals) who are accustomed to being well paid in the US.

Work Harder for Recognition

Because remote workers are unseen to many with the organization, they may struggle to gain recognition within their organization. Thus, remote workers may be forced to work longer hours and still be behind their office-working peers. Additionally, since remote workers have fewer opportunities to develop bonds with management and other coworkers, they are significantly easier to fire. Additionally, this lack of bonds as well as a difficulty in receiving recognition will ultimately lead to stagnant wage growth for many remote workers.

Conclusion

While most employees are increasingly fond of remote work, they may realize too late that their employer has gained more than they have. Furthermore, they may find it increasingly difficult to find work in a pool of highly-qualified candidates both domestically and internationally.

What is an idea worth? I am frequently approached by friends and acquaintances with ideas for software applications. Typically, the individual believes that the idea will generate huge revenue, and they will graciously share a portion of the profit with me for my time developing the software. In no instance does the individual suggest that they will help do the development, that’s what they need me for. Furthermore, they do not have the finances to hire a developer, so their hope is that I will invest my ‘sweat equity’ into their dream project.

There are a variety of problems with this proposal. First and foremost, I have bills to pay. As such, I can’t drop paying customers for hope a future payout. Furthermore, these projects typically involve niche markets with a limited number of customers. As such, it is necessary to examine a variety of factors to determine if such an idea really has any value.

To determine that value, you must first determine an estimate of all costs involved in producing the software application. This will include development time as well as a variety of other costs. For example, licenses involved for development, deployment servers, cloud hosting costs, costs to manage the services, etc. Then, costs to market or distribute the application must be considered as well, such as the cost to Apple or Google to distribute on their mobile platforms.

After the sum of all costs is determined, the individual must make a conservative estimate of the number of units sold as well as the anticipated price point. Once that is accomplished, the profit can be determined. Multiply the unit price times the number of units sold and subtract all costs. Once that value is determined, you can have an estimate of the value of a given idea. Sadly, in many instances, that value is well below $0. Thus, many projects are simply not worth the effort because they have no return on investment.

For the developer, it is rarely useful to develop an application based on the future hope of a payout. If you do, you will very likely end up on the losing side of the equation. For the prospective client, if you feel strongly that your idea is profitable, develop a business plan. Then, convince investors of the return on investment they can hope to achieve. Once you have investors, you can then go to a development firm with a far more profitable scenario – pay for the services you want and forget about the free app development.

Regardless of the type of work done by a service organization, two payment models exist: project-based and hourly. Each of these models works better for certain kinds of projects, and each model has pros and cons for both the buyer and the service-provider.

Service Billing

For simple services that can easily be estimated accurately, a project-based rate makes sense. Examples may include the cost of a car wash, painting a room, or changing the oil in a vehicle. In each of these instances, the actions of the service-provider are nearly identical with each implementation of the service provided. Furthermore, the time required is either constant (changing the oil in a car) or is easily measured based on a parameter such as room size (painting a room).

Other types of projects may be more difficult to accurately estimate. For example, gutting and remodeling a bathroom may require an estimate that is highly dependent on how the project progresses. As the contractor moves through the project, unforeseen issues may arise such electrical wiring problems or rotten floorboards that could not be known prior to the start of work.

Software Development Models

While many customers may want a project-based price, the reality is that such estimates are often inaccurate. Much like the wiring issues or rotten floorboards found by a contractor, issues often arise in software development. Furthermore, since every project is unique, developers are often forced to provided what is really nothing but an educated guess into the timeframe.

This reality has been acknowledged by most software companies as they have moved form “waterfall” to “agile” development methodologies. In waterfall, timeframes and budgets are defined before software development begins. However, companies found that these plans were rarely accurate. In fact, a common problem was budget overruns and late project delivery.

To solve this problem, companies moved to “agile” development. In this model smaller pieces of work are performed and deployed over and over again to build an application iteratively. In this model, the customer begins using the software as soon as possible and has the ability to change course as needed. For example, a customer may find that an “essential feature” is really not important once other aspects of the project are delivered. Or, they may find that an essential feature is missing which prevents required functionality.

Software Billing

Given that software quotes can be highly inaccurate, software companies and clients are left to determine how to best bill for software services. In a project-based model, the development firm takes on all the risks of providing an accurate estimate. However, knowing that estimates are frequently inaccurate, the firm will likely pad the estimate considerably to account for those issues. Furthermore, the software firm will have a vested interest in performing the least amount of work to accomplish the client’s vision. This may result in poor, unmaintainable code or buggy implementations as well as the client paying a higher overall hourly rate.

Conversely, if the software company bills on an hourly rate, they may have less of an interest in performing their job efficiently. Instead, they may want to run the clock to bill more hours. While the client has a better expectation of quality code, their bill may be inflated.

Since both models can be exploited by software development firms, it is important to find a developer you trust. Ultimately, I prefer an hourly model. This allows me to change course as the client’s needs change. I have found that customers rarely have an accurate idea of what they want. However, as the project progresses, and their vision comes into focus, clients are able to provide meaningful direction. If I’m forced to provide a project-based price, the client’s feedback will likely be ignored since their changes would constitute a change in project scope – something not allowed in a project-based model.

Conclusion

As a customer, an understanding of both models can help you interact with a software provider. While your first thought may be that the software company is trying to run up the bill with extra hours, any decent developer can provide you a ballpark figure for your project. However, know that such an estimate may be subject to change based on unforeseen problems as well as changes in your requirements as the project moves forward.