Ask HN: How do you move a business forward that's using old tech? | Hacker News Reader

Ask HN: How do you move a business forward that's using old tech?

6 pointsartificialLimbs6 comments

I work at a very stable, mid-sized company. We have ~ 1,500 clients. Our internal site, which we share with clients who have their own creds, is built on an ancient tech stack. An IBM DB2 server with vanilla php 5.4. We are still using iframes and tables for layout. It ... mostly works, except if you try to use it on mobile/small screens. We manually build SQL statements. We do not use classes. There is no CSS, only a few inline styles here and there. We use a proprietary, old IDE and will not be changing because of existing devs.

I am a relatively new web dev, ~ 3-4 years experience (but with wife and kids that whole time, so not much free time). The other 2 devs at the company have been there a LONG time. One is dedicated to sys/db/running the business, the other is web/client facing. They don't seem very interested in using new tech.

The boss has asked me to experiment with my own web server, Laravel, and a PowerBI gateway for analytics, but I'm completely on my own and pretty swamped with basic stuff like manually building forms. What would you do to help get this business up to speed?

Two choices:

Iterative and incremental, or, "Rebuild projects"

Tech isn't useful because it's new, and it isn't bad because it's old.

It's a business investment to "solve problems" or "create opportunities" for someone.

"If it ain't broke" yada

I would find what's broken (I can't get enough time to look for potentially better ways for our systems to work because I'm always building forms) and recommend prioritising some of your time per week to identify a solution (I'll spend 1 day per week investigating ways to use greater automation and or lower bespoke effort to build forms) meaning I won't have as much time to do x, y, z.

Then if you find a solution, work out what the first interation would be and guess how long it will take and seek agreement to invest the same or more time per week in implementing it.

Rinse and repeat

I'd say build the api first, then any frontend of your choice may be used.

Or how about leaving it as is and building a new business with any new tech you like.

In the end though, tech doesn't matter so much for most businesses, I think.

I'm in a similar situation and what's worked so far is to do things incrementally and to make it as easy as possible for the rest of your team to switch over to the new stack. Don't try to replace everything at once if you're working on it by yourself.

How's the source control?

Are you using CI/CD?

We have an internally hosted bare git repo that I configured. I don’t even know what CI/CD is yet.

Then I'd recommend getting a test framework installed, probably PHPUnit, and get CI/CD - Continuous Integration / Continuous Deployment- set up to run the tests on checkin, Gated checkins if possible (prevents merging in of code that results in test failure), get branches in your repo for different environments - Dev, Test, Production, etc. and have the CI/CD deploy those branches to different environments (if possible/have the budget, if nothing else it'll let you or other devs run smoke-tests) - once all that is done you can guarantee a degree of code quality, cut down on broken builds, get a tighter feedback loop for changes, can refactor till your hearts content, etc.

Reply on news.ycombinator.com