5 Biggest Lies Web Developers Say
Language [X] will help us do stuff faster.. We must use [x] tech…
Using [ INSERT TECHNOLOGY ] instead will help us make stuff faster.
Reality: You’ll either spend months painstakingly migrating between technologies. OR spend even longer stuck supporting both.
Explanation: We software engineers are full of preferences and opinions. Unfortunately those opinions often get expressed in a heavily biased, matter of fact way. They often support their preference with vague promises they rarely deliver. “We can built stuff so much faster.”,“Our app will work so much better.”, “We can find much better developers.”
The truth is swapping interchangeable technologies is almost never worth it. If your company has already built an ecosystem around a technology. Unless a different tech has a proven clear advantage that addresses a problem you have. Odds are the will be a large cost to change from one tech to another only to end up where you already are.
I have seen this happen on more than one occasion. It happens often in smaller orgs when a new team or manager is added. Instead of adapting to their new environment. They seek to mold the organization around their comforts.
On one occasion a new team joined our company and pushed their existing framework into the org. The end result was lost efficiency for everyone. Since the new team did not know the company and the old team did not know the new framework the entire team faced a steep learning curve. Many mistakes were subsequently made to make up for lost time.
Another occasion a group of Rails enthusiasts pushed for adoption in an organization that was built in PHP. Although Rails has significant advantages over the PHP tools being used in the organization. It wasn’t enough to justify the amount of effort needed to replace the systems in place.
The end result was 1/2 the code being written in Ruby, the other in PHP. The teams divided effort along those lines and work was often redundant and incompatible.
I’ll keep this explanation short for this article. But the ramifications of this decision is something I’ll get into deeper in another article. Comment request for the story so I can gauge interest.
Take Away: If you are at a starting point, you can choose a technology based on its merit’s and your preference. However, if your organization already utilizes a technology to its satisfaction. Laterally moving a technology is more often then not a huge waste of time and money.
We must use [ INSERT TECHNOLOGY ]!
Reality: You end up introducing unnecessary complexity to your stack.
Explanation: We techies love the latest toys. Whenever we see a new tool, we want to rush to use it and tell everybody how awesome we already are at it.
The problem is software developers confuse this excitement with necessity. Once again developers disguise their interest as a benefit to the company. We want an excuse to use the tech, so we push the company to adopt it.
Why? EGO. Web developers feel a social stigma and competitive pressure to know the latest technologies. Some people just blatantly want to pad their resumes with the latest buzzwords. Others simply make the mistake of thinking a new technology is a magic bullet.
I’ve seen this happen more than once with AWS, Docker, Elastic Search, and more.
Don’t get me wrong. I also enjoyed playing with these techs and learning them. But the organizations I was a part of simply had no use cases for them. However that did not stop developers from pushing adoption.
The end result was poorly executed attempts to adopt technologies we didn’t need. The organizations experienced higher infrastructure costs, or more complicated and less stable deployment processes.
No matter the technology, using a tech for it own sake needlessly adds complexity, fail points, and management to your stack. I am a firm believer of doing what you need with as little technology as possible.
Take Away: Let the problem dictate the solution. I know its tempting to be an early adopter. But strive to keep things simple, understandable and small. If you have a problem a new technology can solve, by all means use it. But do not make up needs to justify wants.
FYI: How many of you googled “MercuryIO” ? I totally made that up. If you did don’t feel bad, we all love new stuff. Leave a comment if you did I would love to see results.
Our app is really complex.
Reality: Your app is NEEDLESSLY complex.
Explanation: I never understood why. But tech teams everywhere love to pretend they work for NASA/Facebook/Google. I guess its part wanting to be part of the tech company culture, or simply over inflated egos.
But most companies do not face the same problems the likes of Facebook/Google/Twitter face.
Of course, your company might have really intricate and complex business logic. Your organization might has lots of moving pieces and inter dependencies that require management.
Yet complex business logic does not require complex code. I have a saying that goes: If you think its complex, you built it wrong.
The reason is writing software is about people, not computers. Languages, frameworks, libraries, etc.. are all here for the HUMAN benefit, not the computers. The computer doesn’t care if you used Laravel or Rails. It doesn’t care if your code breaks SOLID principles or is DRY. It will run the code its told no matter how simple or complex.
Therefore, your code should be written with simplicity as its principle for the humans sake. If you’re application is seemingly complex. It is because you did not do a good enough job of organizing your app.
This might mean you break your app down into separate components. Perhaps refactor your code to reduce volume, redundancy and focus more on code portability.
Take Away: The wonderfully strange thing about programming is you do it better by doing it less. A good web developer will build more stuff with less code. By focusing on proper code organization and re-usability you can do complex operations with simple commands.
Saying the “problem was really hard” or “the application is really complex” is sugarcoating a lack of understanding. This might be the developer’s fault, the app’s fault, or somewhere in between.
But I assure you there is never a NEED for complex software. Even if what the software does is complex, writing it shouldn’t be.
This is going to take 2 weeks
Reality: You either have NO idea, or you know it will take a few days but rather watch YouTube.
Explanation: Time estimates are every software engineer’s Achilles heel. This isn’t the developers fault, they just simply never built what you’re asking them to build before.
Every seasoned web developer knows the devil’s in the details. Yes they’ve built apps before. Perhaps you’re looking for a simple website and the developer has built hundreds before.
Be that is it may, they’ve never built YOUR website before. All those details that made those other projects unique do not apply to your project.
The best a programmer can do is have a historical record of similar projects and average that time, add 30% buffer and hope that’s correct.
Of course, business people don’t like dealing with abstract time estimates. They want the experience we all expect when making an order. “I just paid for it, when will it be done?”. I do this to mechanics and contractors all the time.
The best thing you can do to help eliminate time uncertainty is to eliminate uncertainty in general. If the project is dependent on YOU doing something to keep going, do that thing ASAP. Its the unknowns that make timelines unpredictable so eliminate them as much as possible.
That being said, there are management techniques used to help eliminate guesswork from teams. They help by measuring and analyzing metrics.
If you’re a programmer, odds are you are familiar with Agile and Scrum, story points, effort points, and sprints.
Each team adopts these techniques in their own way, but the theory behind the practice is the same. You measure a developer’s effort level by complexity. A developer may not know how long something will take. But their intuition about whether the task is straight forward or daunting is normally in the ballpark.
You capture their “efforts” for each ticket as a point. You then measure points over time to understand how much work someone can do in a given amount of time.
Take Away: You can’t heavily rely on time estimates without enough history to help inform an estimate. Web developers have gotten used to providing time estimates quickly. Often out of bad habits and misunderstanding of software development. So plan flexibility into your schedules. Work with developers to better measure and track work.
Now I have seen developers say 2 weeks on items they could do in a day. This time uncertainty works both ways and many developers to take advantage.
Now, some time padding is normal and perfectly acceptable. There is a 3X rule in software development. It says multiply your original estimate by 3 for a more accurate estimate. However if a task seems suspiciously padded for its complexity, ask why. If you hear the terms “flux capacitor” or “bypass” its probably bullsh*t.
We are a tech company.
Reality: There is no such thing as a tech company.
Explanation: I’ve now worked for 3 “tech” companies. Each company’s culture tried to mimic the tech company culture of silicon valley. Engineers were seen as the pillars of the company. Their heroic efforts were the backbone of the products and services the company provided. Engineers were highly regarded, which was a problem.
In reality engineers did play a pivotal role in the company’s success. The problem was so did everyone else. I was a part of the problem. As part of the tech team I erroneously was often frustrated by the other departments.
Frustrated by the BS interruptions to support customer service with a client. Or help the VP send emails. Or run reports for various sales people. These all seem like a waste of time from my perspective. Taking MY valuable time away from making technology. Didn’t they know our technology was our bread and butter?
If I sounded like an complete idiot, it’s because I was, but it wasn’t just my fault. Orienting a company as a tech company caused a lot of misconceptions about what we “did” as a company.
Yes, our main product was a tech one. But it was people using it, not machines. We didn’t sell technology, we sold a solution to a problem real people had in their everyday lives.
People weren’t buying our stuff for the beautiful code nor the symphony like server orchestration. Our customers didn’t care about our technology at all.
Those sales people I was annoyed to support were paying my salary. Those customer service folk were keeping our reputation up. Those email’s our VP needed to send paved the way to expansion. Our software was a small part of a much bigger puzzle.
Important: This wasn’t an innocent marketing problem. Positioning the engineers are the “heroes” of the company has real down side. Other departments felt underrated and mistreated. Salaries were slanted towards the tech guys. The company’s culture was of a primary and secondary class of employees. This led to bitter tensions between departments and individuals.
Take Away: A company isn’t about its most visible components. A well assembled company shouldn’t have superfluous departments. Every component of a company is critical. If it isn’t, it doesn’t belong there in the first place.
Give value to all your employees. Help them understand their part of your company’s mission. Help them understand they are on the same team.
Like and share this article, or leave a comment I’d love to hear your feedback. Follow me for further insights into where my entrepreneur life takes me. Check out my work at http://www.rockstarcode.com
