• [email protected]
Coding As Creating | Online DevOps Academy
  • Home
  • Courses
  • Blog
  • Community
  • Pages
    • FAQs
    • Contact Us
  • 0
  • Login
  • |
  • Register
    • Login
    • Register

Developer Mistake Siren – 8 Reasons Why Stopping Wheel-Reinvention Saves the Development Team

Coding As Creating | Online DevOps Academy > Blog > Agile > Developer Mistake Siren – 8 Reasons Why Stopping Wheel-Reinvention Saves the Development Team
8-reasons-why-stopping-wheel-reinvention-saves-the-development-team
  • Alireza Chegini
  • 16 September 2019
  • Agile

Are you feeling bogged down? Well, my developer friend, that’s fine. We all go through hardships from time to time. And you or your Development Team is no exception to that.

But guess what? This time on Coding as Creating, I will lend a helping hand to get you rid of the reinventing-the-wheel loop—in the realm of Software Development.

The process of software development is complicated. Your grandma may insist on thinking on your feet all the time. But, sometimes, it would just cause more harm than good.

Your granny is always right. But, I’m afraid, not when it comes to developmental processes.

In short, if you try to invent a tool and use it afterward, you’ll probably lose everything. And I’m kidding you not. This reinventing-the-wheel thing can ruin everything. Read on to see for yourself—in case you’re a Debbie Downer.

1.    The Wheel You Invented is a Code That Someone Has Already Written

Okay, let’s be frank. You’re not the only member of the last Software Development Team of the galaxy. So, yeah, there are thousands (if not millions) of people having the same job as you. And they write codes, you say?

Long story short, what you’re trying to produce may have already been produced. Thus, a hypothetical question is “will you spend, say, a million years to produce Starbucks while the cafe at the corner is already selling it?” you better not.

Though it doesn’t make any sense, there are some development teams, companies, and developers who make this mistake.

I don’t like to point out the big-and-obvious picture. But seriously, don’t go for inventing the Starbucks from scratch. Instead, find a web service, API, or pre-written codes to fulfill the needs.

“buy a Starbucks coffee, and use the rest of the day for remaining a developer.”  

2.    Are You Going to Be a Sacrificer or a Developer?

Inventing a new tool, or writing brand-new codes is hard. You need Benjamin and miss Second on your side. So, don’t go for that unless you’re the Software Development Team head at Google or something.

In brief, you shouldn’t forget about the budget and time. you’re trying to develop a software, right? You can’t sacrifice all for getting an already-invented tool.

However, if those are not a concern, go ahead. Invent the wheel—and don’t even use a blueprint to make it even harder!

But as a piece of friendly advice, don’t over-estimate your capabilities.

3.    Your Development Team Wheel Has Not a Solid Grasp of the Material

 Let’s assume that you’ve invented that wheel. Is it immune to all kinds of breaks? I don’t think so. There’s no such thing in the realm of IT, Software Development, and Coding. New stuff in this realm is doomed to be unstable at first.

So, your new code/tool (i.e. the imaginary wheel) is not stable. You’ll need money, effort, and time to enhance it constantly. And, unfortunately, you’ll end up having two developmental projects at once.

Do you need me to emphasize the idea again? Okay, do not fall for heroic theories. Use others’ helping hand on the project. And don’t worry about owing someone. You’ll pay for what you get after all.

4.    The Codes Are New and “Full of Terrors.” So, the Automated Test is Coming!

As discussed above, this is the territory of glitches. So, no new thing is 100% reliable. And your brand-new tool is not an exception to that.

Tell me, are you going to take the risk? Will you use the unknown tool (s)? you better not.

Okay, I know some geeks are thinking about the Automated Test. And that’s sweet. But let me tell you something: it’s not a free process.

Regardless of the method, you’ll have to pay for it. Moreover, you should spend a lot of time for the implantation of such a practice. So, even a DIY would not save your butt.

However, when you use a commercial tool, things are different. The project will face no hard-to-manage issues. And you would find it much comfortable to prevent getting behind the task management. That’s so because a Development Team has already tested the tool. So, in brief, it’s just ready to use!

5.    Have You Written a Love Letter to Your Future Developer Self?

“Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing.” Says Dick Brandon.

He’s right. The documentation process is everything. And the bad news is that you won’t even get that ‘better than nothing’ part. The code/tool that you might be using is not trustable. So, letting it getting involved in the project is like starting a relationship with an underage person. It’s not right, it’s risky, and it’s wrong! 

You shouldn’t rely on a tool that is not fully documented. Otherwise, you’d need to turn off any notifications soon—and be prepared for some hodgepodge-flavored events.

Nevertheless, a real commercial tool/service is well-documented. You can always ask for logs. And use the detailed information to find solutions.

6.    Fit the Functionality into Schedule

Integration matters. Imagine as if you were hiring a new developer. Would you do this with your eyes closed? Harmony, function, and the upshot wouldn’t be a concern? I’m sure it would.

So, apply the same rule when it comes to the new tool. And don’t include any untrustworthy components in the developmental projects.

Instead, opt to have a tool/API/Web Service that has stood the test of time.

This would allow you to fit the functionality into the schedule. And get what you’re looking for faster.

Bear in mind that you need a dependable tool. This is the only way to guarantee to have a satisfying upshot. Moreover, this is the only route that would lead to easy blend-in and harmonizing.

7.    Don’t Kill Time; Instead, Breed More Attention Zones

So far so good? Hold on it’ll get even better. So, tell me, what happens when you cut back on time? what if you haven’t gotten behind the deadlines? What would you use that extra time for? Well, you could spend it to enhance what you already have.

That said, any extra time can and should be used to develop the software.

Are you wondering how could one get that extra time? let me tell you. One approach is omitting the time spent on reinventing the wheel!

In case you use an already established tool, you get an unbelievable amount of extra time.

You can use it for improvements. Or, you could find new focus zones to elaborate on.

8.    Hey, Your Development Team Needs Some After-Sales Service

Do you know what’s the best thing about an established tool? It has some sort of after-sales service.

It may not be comparable to what you get after buying a vacuum. But, you know, there’s still something to rely on in case of emergency.

So, stop being a law unto yourself. As a substitute, try to accept that you may need some professional help—though you’re already an expert.

Bear in mind that you can replace such a tool—anytime. And it wouldn’t cost a fortune.

The company you bought the tool from will be willing to help. Moreover, you could find another company at almost any stage of the project. And replace their tool with the one being used at the time.


Continue Reading

Refresh Your Knowledge From Your Holidays

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Mastodon

Related

Post navigation

Previous Post
Next Post

Leave A Comment Cancel reply

You must be logged in to post a comment.

Recent Posts

  • Terraform Workflow: Ultimate Guide
  • Choosing the Right Infrastructure Tool for Your Organization
  • Terraform State: Lost and Found!
  • Python: The Playful Programming Language!
  • DevOps Ahead: 10 Ideas to Boost Your 2023

Categories

  • Agile
  • AI
  • Azure DevOps
  • ChatGPT
  • DevOps
  • Opinion
  • Personal Development
  • Programming
  • Uncategorised

Archives

  • June 2023
  • October 2021
  • February 2021
  • December 2020
  • April 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • May 2019
  • April 2019
  • March 2019

Recent Comments

No comments to show.

Recent Posts

  • Terraform Workflow: Ultimate Guide
    10 June 2023
  • Choosing the Right Infrastructure Tool for Your Organization
    6 June 2023
  • Terraform State: Lost and Found!
    6 June 2023

Categories

  • Agile
  • AI
  • Azure DevOps
  • ChatGPT
  • DevOps
  • Opinion
  • Personal Development
  • Programming
  • Uncategorised

Archives

  • June 2023
  • October 2021
  • February 2021
  • December 2020
  • April 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • May 2019
  • April 2019
  • March 2019

Meta

  • Register
  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org

Course Search

Courses categories

  • Uncategorized

Tags

CI/CD Pipeline DevOps DevOps engineer DevOps Skills Infrastructure as code Leadership SDLC software development software engineer SysAdmin Terraform

Course tags

Courses

  • Mastering Azure Virtual Machine Mastering Azure Virtual Machines € 49,99
  • Learn Infrastructure As Code using Azure ARM templates copy Learn Infrastructure As Code using Azure ARM templates € 49,99 € 9,99
  • Mastering CICD With Azure DevOps YAML Pipelines Mastering CICD With Azure DevOps YAML Pipelines € 49,99 € 9,90

Contact Us

  • [email protected]

Feel free to contact us
© Copy 2021. All Rights Reserved

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.