S3Corp. Tech Blog

Startup development projects get derailed by well-intentioned — but terrible — advice. Here are 6 pearls of wisdom worth ignoring.

Building quality software is tough. And at times, misguided insights make it much tougher.

When creating quality code and building great software, it is important to carefully plan your project and communicate well during each step of web application development and mobile application development.

Though good advice is not scarce, bad advice runs rampant amongst those lacking expertise. With this in mind, I reached out to some fellow developers and innovators in the tech space to hear about their software development experience and asked them to share the worst advice they’ve ever received. Below are some of my favorite insights from those conversations, and my own “worst” advice:

1. If your change is small enough there’s no need to test.

Testing code is crucial. As Charles Kong, a Google developer, explained, “Software engineers face the issue of how much time should be spent on writing tests, and some might say that with negligible change, unit tests are a waste of time if you know it’s definitely not going to break. In my opinion, tests should always be written for any piece of code, and for a trivial change, it’s much quicker and easier to write a simple test for it anyway. You never know when you might make that minor spelling mistake that happens to compile.”

Errors happen, so do not sacrifice testing your code–no matter how trivial or small it may seem.

2. You don’t need to comment on well-written code.

Some say commenting is a lost cause. Actually, it’s not.

Not everyone will understand your style of writing code. Jawbone developer, Trung Le learned this the hard way. “This is completely wrong, you always need to comment your code. The reason I don’t like this advice is because LOTS of people don’t read code well, hence they rely on the narrative from the comments to understand how code works.”

3. Avoid offshoring at any cost.

This generalized statement is one we often hear about foreign programmers. However, it’s a misconception, according to my co-founder Pratham Mittal.

“This advice makes an incorrect generalization,” he explains. “There are both good and bad software developers within any country. Viet nam software outsourcing and Vietnam software services have a large talent pool full of educated and competent programmers.”

4. Build on opinions or assumptions vs. measurable results.

According to Ludo Antonov, Technical Lead for the Pinterest Growth Team, an engineer is used to getting a lot of advice. But when it comes to product development, he says, “The most destructive advice is the type that lures you into building solely based on opinions rather than measurable results. Often times, many good engineering hours get wasted that way.”

Product development is not subjective. In fact, it’s all about results.

“At Pinterest, we’ve harnessed a phenomenally laser-focused and data-driven approach, that’s critical for our success,” says Antonov. “It’s important for ideas to find their way into code and be tested out. However, relying on opinions alone is particularly risky when it comes to deciding on the code’s success, and its introduction as a permanent part of a product, which needs to be well supported over time.”

Sites with large traffic should run many experiments on subsets of their user base and optimize based on key metrics.

5. Don’t touch ‘that’ part of the code.

It’s there and it’s working, then why touch it? Well, just because it’s running doesn’t mean it’s right. It must be functional. And because someone else has written the code doesn’t mean you can’t handle it. Comprehending someone else’s code is the strength of a good developer, explains Adnan Ali. You must be fearless.

Being the lead software architect at Financeit, Ali has received a lot of advice. “But the worst piece of software advice I’ve gotten is ‘Don’t touch that part of the code. Nobody touches that part of the code!’ It was some core part of the system and the developers were afraid to touch it. Ignoring the advice, I walked through it line by line so I could understand what it does. Based on that understanding, I made a change that got us a 20% performance gain on each web hit. Reading and understanding other people’s code is one of the most important skills for developers,” he says.

6. Don’t worry about planning.

These are some classic examples of why you should question the advice you receive. But as for me, the worst advice I’ve ever received is: Don’t worry about planning. You’ll figure out everything along the way. Just start writing code.

I believe planning is a critical phase in any development project. While you don’t have to plan out every single minute detail, mapping out your product and prioritizing features is necessary before writing code. Most of the time a team will think that all features are absolutely essential. Without prioritizing and separating out features into different versions you increase the amount of time and money invested into your first product. Instead, you should focus on building your core necessary features and getting feedback from your end customer.

We all get a lot of advice and should always listen to what people have to say, but we have to critically review the feedback we receive and experiment with different strategies.

Where do you get your software advice from? What was the worst advice you’ve received? I’d love to hear it.

Source: INC