5 ms·

> and then wrote an entire system! Yes yes. And this was of course very maintainable, up to todays standards, easy to onboard new hires in, not falling apart i

> and then wrote an entire system! Yes yes. And this was of course very maintainable, up to todays standards, easy to onboard new hires in, not falling apart in edge cases that weren't part of the demo, code that was audited by multiple developers, it didn't make any shortcuts in terms of security, etc. etc. etc. That some business guys are amazed by the "lone wolf dev skills" might be explainable, but on HN we should know better. Yes, there are devs that get a ton done irrelevant of framework, but "getting things done" (in terms of business requirements) is only part of the story.

reaperducer 5y ago
That some business guys are amazed by the "lone wolf dev skills" might be explainable, but on HN we should know better. I'm less cynical than you are about the parent comment, largely because I'm watching the same scenario unfold within my own company. We're on year two of the million-dollar team turning out nothing. I'm in a different department, but my position means I liaise with lots of different people throughout the organization, so I also know that a single dev in a third department is half-way through solving the problem because a ultra-high-level manager doesn't want to wait anymore and will use it as an excuse to can the other team and that department's director. And this was of course very maintainable, up to todays standards, easy to onboard new hires in, not falling apart in edge cases that weren't part of the demo, code that was audited by multiple developers, it didn't make any shortcuts in terms of security, etc. etc. etc. Unless you've seen the person's codebase, it's uncharitable for you to assume that it's deficient, perhaps based on your own experiences. If this scenario can happen in two companies, it might be more common that any of us realize.
- codebolt 5y ago
  Indeed, I'm personally half of a two-dev team maintaining and developing a system that I'd say falls deep into this category. Our giant legacy codebase has a few warts, but on the whole it follows a few simple design patterns that, once you understand them, makes it very easy to find your way around and change/extend. We also have an extensive domain understanding and direct contact with our user base, so we design, implement, review/test and deploy features very fast compared to any other team I've encountered in the organization. And though the underlying technology is mostly ancient, our product is growing strongly and consistently outcompeting systems with budgets of a different stratosphere in the open market.
- mcguire 5y ago
  Three.
giardini 5y ago
There was user & supervisor security (code that she had developed for another system). It included backup of code and databases. What was shown wasn't a demo - it was a full implementation. It was rolled into production weeks after the first showing and AFAIK is still in use 20 years later. What is there other than "getting things done" (that is, other than bitching about it)?
- Shacklz 5y ago
  Hey look, I'm not saying that it's not possible. I even believe you - in a lot of big companies, there are so many "bloat"-teams that don't really do all that much, that just drift around in the currents that flow when cash is abundant and will get shafted the moment the company has to tighten its belt (or goes belly-up altogether, if the company is incapable of identifying its inefficiencies). That being said, we should really take these anecdotes with the appropriate grain of salt. After all, we're here in a thread about countless companies being threatened by security flaws. A dev that "gets things done" (from a business point of view) might actually do that, but do they also think about all those other requirements that business themselves can neither validate nor appreciate if measured by short-term KPIs? I'm not saying that's happening, but I've seen too many "Why are you spending weeks on this, I can do this in half a day!"-kind-of-devs, that then hack something together that technically works as the requirements demanded, but completely falls flat under any aspects of maintainability and extensibility, let alone security.
mcguire 5y ago
Once upon a time, there was an application that needed to be replaced. (Apache mod_perl 1!?) My employer put a team together to do it, a team that was very concerned that it be "very maintainable, up to todays standards, easy to onboard new hires in", etc. Unfortunately, they apparently failed to include "working" in there. As the project schedule began to slip, they added more people to the team. Eventually, after many months and at least a couple million dollars, I and three other people got dragged in: another developer (no one lets me do UI code), a good project manager to coordinate with users and management, and a developer/tech lead/manager who had two unique abilities: good at cutting Gordian knots, and having enough political capital to say "no" to people (most people around couldn't say "no" to save their life; I can and do, but nobody listens to me). The latter promptly booted the previous team off the project. Within four months, we had the new app up and running and in production. I'm told that it has one of the best issue track records in our area, including never having had a sev 1 outage. On the other hand, I have heard some of its current maintainers complain about it not being "up to todays standards" because we deliberately kept it simple rather than adopting a bunch of complexity for resume-padding reasons.
astrange 5y ago
> That some business guys are amazed by the "lone wolf dev skills" might be explainable, but on HN we should know better. Yes, there are devs that get a ton done irrelevant of framework, but "getting things done" (in terms of business requirements) is only part of the story. No, you shouldn't be surprised about this, it's natural that smaller dev teams are actually faster. This is Mythical Man-Month.

reaperducer 5y ago

That some business guys are amazed by the "lone wolf dev skills" might be explainable, but on HN we should know better. I'm less cynical than you are about the parent comment, largely because I'm watching the same scenario unfold within my own company. We're on year two of the million-dollar team turning out nothing. I'm in a different department, but my position means I liaise with lots of different people throughout the organization, so I also know that a single dev in a third department is half-way through solving the problem because a ultra-high-level manager doesn't want to wait anymore and will use it as an excuse to can the other team and that department's director. And this was of course very maintainable, up to todays standards, easy to onboard new hires in, not falling apart in edge cases that weren't part of the demo, code that was audited by multiple developers, it didn't make any shortcuts in terms of security, etc. etc. etc. Unless you've seen the person's codebase, it's uncharitable for you to assume that it's deficient, perhaps based on your own experiences. If this scenario can happen in two companies, it might be more common that any of us realize.

codebolt 5y ago
Indeed, I'm personally half of a two-dev team maintaining and developing a system that I'd say falls deep into this category. Our giant legacy codebase has a few warts, but on the whole it follows a few simple design patterns that, once you understand them, makes it very easy to find your way around and change/extend. We also have an extensive domain understanding and direct contact with our user base, so we design, implement, review/test and deploy features very fast compared to any other team I've encountered in the organization. And though the underlying technology is mostly ancient, our product is growing strongly and consistently outcompeting systems with budgets of a different stratosphere in the open market.
mcguire 5y ago
Three.

giardini 5y ago

There was user & supervisor security (code that she had developed for another system). It included backup of code and databases. What was shown wasn't a demo - it was a full implementation. It was rolled into production weeks after the first showing and AFAIK is still in use 20 years later. What is there other than "getting things done" (that is, other than bitching about it)?

Shacklz 5y ago
Hey look, I'm not saying that it's not possible. I even believe you - in a lot of big companies, there are so many "bloat"-teams that don't really do all that much, that just drift around in the currents that flow when cash is abundant and will get shafted the moment the company has to tighten its belt (or goes belly-up altogether, if the company is incapable of identifying its inefficiencies). That being said, we should really take these anecdotes with the appropriate grain of salt. After all, we're here in a thread about countless companies being threatened by security flaws. A dev that "gets things done" (from a business point of view) might actually do that, but do they also think about all those other requirements that business themselves can neither validate nor appreciate if measured by short-term KPIs? I'm not saying that's happening, but I've seen too many "Why are you spending weeks on this, I can do this in half a day!"-kind-of-devs, that then hack something together that technically works as the requirements demanded, but completely falls flat under any aspects of maintainability and extensibility, let alone security.

mcguire 5y ago

Once upon a time, there was an application that needed to be replaced. (Apache mod_perl 1!?) My employer put a team together to do it, a team that was very concerned that it be "very maintainable, up to todays standards, easy to onboard new hires in", etc. Unfortunately, they apparently failed to include "working" in there. As the project schedule began to slip, they added more people to the team. Eventually, after many months and at least a couple million dollars, I and three other people got dragged in: another developer (no one lets me do UI code), a good project manager to coordinate with users and management, and a developer/tech lead/manager who had two unique abilities: good at cutting Gordian knots, and having enough political capital to say "no" to people (most people around couldn't say "no" to save their life; I can and do, but nobody listens to me). The latter promptly booted the previous team off the project. Within four months, we had the new app up and running and in production. I'm told that it has one of the best issue track records in our area, including never having had a sev 1 outage. On the other hand, I have heard some of its current maintainers complain about it not being "up to todays standards" because we deliberately kept it simple rather than adopting a bunch of complexity for resume-padding reasons.

astrange 5y ago

> That some business guys are amazed by the "lone wolf dev skills" might be explainable, but on HN we should know better. Yes, there are devs that get a ton done irrelevant of framework, but "getting things done" (in terms of business requirements) is only part of the story. No, you shouldn't be surprised about this, it's natural that smaller dev teams are actually faster. This is Mythical Man-Month.