3 ms·

Having had the fun of taking over a project from a bunch of clever contractors I would caution: It may be too clever. There is value in simplicity and a stake i

Having had the fun of taking over a project from a bunch of clever contractors I would caution: It may be too clever. There is value in simplicity and a stake in long term ownership. Some article here recently associated technical debt as lost institutional knowledge so handing the most key decisions to contractors has also drawbacks. One needs an integrated approach for design, build, maintenance and operation.

cellularmitosis 2y ago
Mixed in with this may also be architectural decisions based from a "let's just spin something up quickly" mentality. Those foundational architectural decisions have a way of becoming set in stone, long after the freelancers have left, dooming the project to scalability and latency problems which seem to linger forever.
- carlmr 2y ago
  I've seen equally many projects never achieve lift-off because they were stuck in analysis paralysis trying to architect MVP for scalability, extensibility etc. And even if that succeeded you often end up with fear of change because the complicated architecture can't be touched. It's really important to have the right balance here, but KISS and YAGNI are often easier to scale when you need it, than the reverse. If you don't have the mentality that the MVP must never be rewritten.
- switch007 2y ago
  > Mixed in with this may also be architectural decisions based from a "let's just spin something up quickly" mentality That, plus "they're probably going to fire us in a year anyway, who cares" thinking And "we don't need to understand the business domain, let's just MVP", which they get away with because they would get accused of not being agile if they did boring stuff like trying to understand the business I refer more to bigger off shore consultancy shops than individual freelancers
davedx 2y ago
Yes! This also happened in the team I mentioned. Sometimes during design/architecture meetings we'd run into the "too many chiefs" problem. That's why I think it's also important to make clear who the lead is from day one.
danfunk 2y ago
Agreed. Take long term ownership. Don't farm this out. There are some companies out there that provide support and consulting on open source projects. Rather than look for a freelancer to build an in-house application, find someone that can help you capitalize on tools that already exist. My company does exactly this. We build and maintain an open source project (SpiffWorkflow, for process automation) and help our clients build internal skills to deploy it and use it. No license fees or SAAS lockin - and no team of developers that walk out the door when things get difficult.

cellularmitosis 2y ago

Mixed in with this may also be architectural decisions based from a "let's just spin something up quickly" mentality. Those foundational architectural decisions have a way of becoming set in stone, long after the freelancers have left, dooming the project to scalability and latency problems which seem to linger forever.

carlmr 2y ago
I've seen equally many projects never achieve lift-off because they were stuck in analysis paralysis trying to architect MVP for scalability, extensibility etc. And even if that succeeded you often end up with fear of change because the complicated architecture can't be touched. It's really important to have the right balance here, but KISS and YAGNI are often easier to scale when you need it, than the reverse. If you don't have the mentality that the MVP must never be rewritten.
switch007 2y ago
> Mixed in with this may also be architectural decisions based from a "let's just spin something up quickly" mentality That, plus "they're probably going to fire us in a year anyway, who cares" thinking And "we don't need to understand the business domain, let's just MVP", which they get away with because they would get accused of not being agile if they did boring stuff like trying to understand the business I refer more to bigger off shore consultancy shops than individual freelancers

davedx 2y ago

Yes! This also happened in the team I mentioned. Sometimes during design/architecture meetings we'd run into the "too many chiefs" problem. That's why I think it's also important to make clear who the lead is from day one.

danfunk 2y ago

Agreed. Take long term ownership. Don't farm this out. There are some companies out there that provide support and consulting on open source projects. Rather than look for a freelancer to build an in-house application, find someone that can help you capitalize on tools that already exist. My company does exactly this. We build and maintain an open source project (SpiffWorkflow, for process automation) and help our clients build internal skills to deploy it and use it. No license fees or SAAS lockin - and no team of developers that walk out the door when things get difficult.