I am not sure how much it is in the interest of a developer to help the business to increase revenue or reduce cost. It's certainly good to come from a successful company but if you haven't worked on the latest cool tech you still don't look good. Even if that decision was 100% the right thing to do.
That's just my personal impression but I believe you have better chances coming from an unsuccessful company with all the right buzzwords than from a successful company with old tech. You will quickly be labelled as "dinosaur".
The real winner is to use cool stuff AND come from a successful/known company.
It's really not about what should happen in a perfect world. I'll stay after work or put some extra hours in to create a proof of concept using a new to me technology. The company may benefit from my extra hours but so do I. Either my current employer is going to pay me more or my next employer is going to pay me more based on what I learned.
If a company is doing fine with the current technology, it doesn't benefit them to invest in the new and shiney as much as it benefits you as a developer. It also doesn't hurt their business not to invest in the latest technology as much as it hurts your career.
And of course, the devs often care about using new tech since it improves both their current enjoyment of the job and (often) their future job prospects
The question one should ask is: what $hot_tech can we adopt without the product becoming significantly worse than with $old_tech? That is, which things do we adopt only or mostly to make the project or company attractive to work with or invest in?
Saying “why would you ever do that rather than building the solution the cheapest and with the lowest risk” doesn’t fully appreciate the importance of attractiveness.
I’m selling my hours of work time for a salary, fun, and resume points. My employer pays me in all 3. I’ll always push for $fun_tech or $hot_tech despite it not always being in the short term interest of anyone but myself or my fellow developers. I’ll keep justifying this by “if we do this in $old_tech then me and half the team will leave, and that’s a higher risk than using $new_tech”.
(By tech I here mean things like languages and frameworks not buzzwords like microservices or blockchain, ai... )
So use 6 month old tech because you need to keep up with the cool kids who are hiring for that new tech specifically? Hamstring your current company in order to stay on top of tech/framework trends?
I'm in the same boat. Funny how many people here are on the same boat. So many smart people but they feel like they can't prove themselves to land a job at another company. I feel that is one thing that stinks about our industry. I think option 1 and 2 are difficult..it takes a talented leader to pull off, but it may not be appreciated by people who haven't been there.
Meaning, it's easier to create a new project using x,y,z new tech. But to transform a company and bring business value from old tech, is more difficult.
I beg to differ. These technologies come with real, actual benefits -- one of the biggest ones for most of these being speed of execution. Many of them fit much better with agile development methods. Others that you list offer scalability benefits, which will save headaches down the line. If you're a tech startup that doesn't at least understand these benefits and has a good justification for why you've gone with other technologies, I'd have questions about the skill level of your technical team. If you already know PHP, learning Rails to start building is like, an investment of a week (or should be if you're a decent programmer). Have you read up on the hoops that Facebook has had to jump through to make PHP scale for them? The future costs of trying to hire excellent developers when you're bound to a stale tech stack is another significant consideration.
I'm not disagreeing that you can make a good product with old tech, but I'd contend that producing a good product and using some of the newer tools are not unrelated, on a number of levels.
I struggle mightily with this in managing projects. My instinct is to use solid boring tech, and maximize chance of delivering on time. But I've found that:
1.) No one writes blog posts about using old boring stuff and meeting expectations. And such blog posts can contribute to recruiting and even, indirectly, sales, by helping your company get general press for being "on the cutting edge."
2.) You can potentially get better overall results even if the new tech has more gotchas and unknowns, because certain developers will knock themselves out to deliver on time and prove you were right in trusting them with the platform/language decisions. But you have to pick very wisely on this and keep in mind such devs may immediately lever their experience on the new tech to get a new job and leave you with a team of juniors that wander lost without their guru.
I don't think you and he are in disagreement. Obviously you should do what will give your business an advantage. He is just saying that it is easy to think that certain new technologies will give you an advantage, but then realize later that what they cost you in bugs/complexity/maintainability etc. make it not worth it for the business. So it's usually better to go with tech that is tried and tested rather than always reaching for the latest new thing.
In practice, you don't have money for those, and your team is lazy and doesn't really want to learn that new cool tech, just let them do their job.
In practise, you want to cheap out on paying for training, have your team do their job and learn an entirely new system to expert level at the same time, the "cool new tech" isn't and your team knows that you're trying to sell it as "cool" to pull a fast one on them because you think they're idiot children, and you won't even commit to using it for long enough to make it worth the bother of trying to learn before changing your mind or prioritising something else, and you're humming and hawing about investing in the tools to make the new tech work well because it's free software so why should it cost you any money?
Besides, you won't prioritise maintenance or design, so the codebase is a mess and people are incentivised towards panic-of-the-day fixes and don't-ever-ever-break-anything conservatism - their fault not yours, obviously, it can't be your fault, you don't even work with the tech (you just choose it by fiat).
Thank you for taking the time to answer. You sound like a good rational engineer. Things that work don't need unnecessary splash of coolness.
On my previous job, I had been working for 15 years on the development of a complex business system. It included desktop apps, mobile apps, webs, on-premises and clouds. Throughout the years, we have introduced many then cutting-edge technologies for new products within the system. Some technologies before they were cool. But, the fine-working-already-done products, we kept supporting with the original technology for the lifetime of the product.
The point is that many new tools and technologies bring a very limited value to the finished working products.
Now, I am a maker of the new development tools. So, I am eager to push them to the world, but wouldn't like to be perceived as an "architecture astronaut". Your opinion helps in understanding how and why engineers choose new tools and technologies.
Possibly. There's absolutely nothing wrong with building something with new tech just for fun, but when you're trying to build a business of course you have to think about whether it actually adds value.
Choosing a technology because you're betting it will become popular and therefore better than it is now is a bad move (except for hobby projects). You should only choose to use a new tech if you will derive enough in its current form to justify the cost. Otherwise you may well end up stuck with technology that you were never happy with and that never hit the popularity thresholds you hoped for.
As they were previously running client jobs, I can see an attractive side to building up the team experience on new tech using their in-house project rather than on client projects.
Put otherwise, in their previous line of business, it matters to be current with regards to state-of-the-art application development. Where's the harm in experimenting with your 'on the side' app?
Yes and no. The tech doesn't matter but that is The Point. That is, your tech won't save bad product. Using the latest cool kids framework or buzzwordy tool won't save bad product.
Yes, the business you're in matters. No, it doesn't matter how you build them - as long as it's quickly. If you outgrow you're overly simplistic stack, that is a _great_ problem to have.
For business I don't think tech stack matters that much but for developers, it matters. Good and young developers avoid working on dull technologies as they don't see future in those.
On the contrary, I would say that enterprises should take the risk and use such projects. They likely have enough capital to hire the correct people (e.g. one of the core devs) when a problem shows up.
Startups can't afford that. Therefore they should use older technology until they grow big enough to tank the damage.
That's just my personal impression but I believe you have better chances coming from an unsuccessful company with all the right buzzwords than from a successful company with old tech. You will quickly be labelled as "dinosaur".
The real winner is to use cool stuff AND come from a successful/known company.
reply