Hacker News Reader

Comment by janosdebugs | Hacker News Reader

Step 4: 2 years down the line the code touched by dozens of freelancers becomes so brittle that you can't launch a feature without breaking two others. Greenfield projects are easy, long-term maintenance is hard.

Edit: during my career, I had numerous projects needing cleanups after developers only interested in shipping the next feature and rotating frequently. If the long term maintenance isn't your problem, the incentive to slap it together is strong.

View on HN

This is the biggest pain of the modern software development process. Freelancers or outsource companies are not interested in your business, they are interested in charging you for hours spent. This approach is counter productive and is against common sense. Especially if you are a solo maker, not a $$$$ backed startup.

I believe to change this, we need to invent a completely new way of how software is built.

I recently met a guy who came up with an idea. He created a whole new methodology of coding stuff. It took him 4 years of hard working. He made a platform which allows making software out of separated entities which live by their own lives. Those entities (components) are developed by individuals. Therefore, projects built using a set of living components needs less maintenance work because a project is built of components which are maintained by someone else.

The only way to keep this evolution of the components going on is to benefit the makers of the components. The users of the components will pay a fee for the makers of components. Thus we get a win-win. A maker of a component can create an amazing, let's say, billing module and continue working on this single piece of code for years while being paid by 1,000 users of the component. While the users of the component just pay a small fee, hit the 'plug' button and do not care about the maintenance anymore.

This sounds like a magic, but it already works. The guy who made it already got his 100+ customers.

This sounds like Salesforce plugins or something. Or at a difference scale, just using Salesforce/SaaS products in general where possible.

Yes, this approach has been implemented by many companies. But those plugins' use scope is limited to a company tool. What that folk did is expanded this approach to the 'any app' level.

component oriented programming is nothing new and comes with its own set of problems.

this also smells like distributed programming where you have loose services on a computer communicating. nothing new either.

these approaches have other issues, like performance penalties and additional complexity and their own sets of problems.

This is definitely true.

My plan was to brining in freelancers just to get the thing built - because I couldn't get it done.

I've since brought on two technical co-founders with a stake in the project to avoid what you're describing.

I was only able to bring them in because I had a product launched.

That is some rare foresight. Typically, this is not how it goes. Usually, the pressure to keep adding new features is too high, the codebase too large, and the desired functionality too amorphous for any sort of refactoring or rewrite.

OP’s method accomplishes one of two things: 1) total failure 2) enough cash to hire a team that does it right.

Getting to year 2 and then replatforming what is working and killing what doesn't seems better than spending 2 years on deploying with the "perfect" architecture

Incentives matter, but it's not like early code written by founders/employees with equity doesn't need to be cleaned up later.

Reply on news.ycombinator.com