5 ms·

I worked on the floor with two teams. One (ours) built our apps and infrastructure the correct way. JIT. Get it working, get it working correct, get it working

I worked on the floor with two teams. One (ours) built our apps and infrastructure the correct way. JIT. Get it working, get it working correct, get it working fast. And given the scale, it did wonders. The other team talked big and gave demos to higher ups and their higher ups and their higher ups. Web scale baby. And with that came the galactic infrastructure and all the buzzword needed in order to run it. About 6 months later, they quit. They had spent their whole budget on astronaut architecture, that the didn't have any money or time left to build the apps that were supposed to run on said infrastructure. "You are not FANG". But even if you are, JIT development.

islanderfun 7y ago
I don't believe I'm familiar with JIT in this context? Just in time development?
- OJFord 7y ago
  I haven't heard it either, but apparently it's another name for the Toyota system/'lean manufacturing': https://en.m.wikipedia.org/wiki/Just-in-time_manufacturing https://en.m.wikipedia.org/wiki/Just-in-time_manufacturing
  - alfiedotwtf 7y ago
    Sorry. No, I wasn't referring to JIT Manufacturing... It was merely a tongue-in-cheek to mean just build what's needed right now in front of you, then get it working at scale once there's an actual needs to scale. This is in contrast to starting from day one spending most of your time thinking of scale, then building everything so that it can infinitely scale (along with the complexities that come with it), only to find out that you have 8 users and your data can fit entirely in memory.
    - dredmorbius 7y ago
      That sounds more like JDI / JGID -- just do it / just get it done. Sometimes "make it so" from ST-TNG.
    - OJFord 7y ago
      Oh, okay, sorry. (Fwiw searching 'JIT development' does net first page results of people talking about JIT/lean manufacturing in a software development context.)
    - mgkimsal 7y ago
      there's a vast middle ground between 'astronaut architecture' and 'common sense necessities', and knowing where a good cutoff point is is hard without experience. I've met more than a few folks who consider web templating systems to be 'overkill', and have 0 understanding of the risk of xss. Same with sql/db escaping - "I just write the SQL and run it, using all those libraries is just a waste of time", etc. Many of the projects I've come in to over the years were doing with a "JGID" mentality. And they did "get it done", "it" was just a steaming pile of crap when it was done. "Why is this taking weeks to do - the previous guy was so much faster?" Had this one last year: "This was never slow before when X worked on it, you've made changes what have you done? We need to call X back in to the project". X just "got it done". And X was a db admin who was writing code. And X decided it would be good to have views join against other views which joined against other views, and have some queries which used those views run in triggers. When X was on the project, and there were 40 users, it was fine. They hit 1000 users, and things were 'slow', so they upgraded to a larger EC2 instance. X left, and I came in, and several months later they hit ~30000 users (not active, just ... user account records). The system was dying with more than 5 active users, because of all the views joining other views on 30k+ records. Unravelling that meant deciphering all the views, all the queries, all the code that touched all of it, and rebuilding a moderate portion, without tests, known 'good' data, or anyone on the project knowing what 'right' was - they just knew when things looked 'wrong' (or slow). BUT... 18 months earlier, it was "JGID", and it got done. I'm still a bit perplexed why a professional DB admin thought views joining against multiple other views was a good approach. We've all got horror stories, I'm sure, it's just that the "JGID" mentality is often preached by competent experts as a good approach, but picked up by beginners as the approach used by experts, and has bad consequences.
      - dhuramas 7y ago
        Out of curiosity - Which database is this? and is it really taboo to have views joining against multiple other views? If the underlying views were performant- I'd assume the query optimizer would do the right thing(at least 90% of the time). EDIT: I guess it depends - Just did more research and found this [1]. As long as the views don't do unnecessary heavy lifting or joining unnecessary tables, it should be fine. [1] https://dba.stackexchange.com/questions/151169/are-views-harmful-for-performance-in-postgresql https://dba.stackexchange.com/questions/151169/are-views-har...
    - rambojazz 7y ago
      > just build what's needed right now in front of you What's needed right now, but that doesn't take a complete overhaul when it's time to start growing.
      - tyldum 7y ago
        It requires a very savvy developer in order to succeed. I have seen the massive technical debt this approach can give.
- anoncake 7y ago
  I think YAGNI is a more common term.
tanin 7y ago
Could you elaborate more? I'm a bit confused. The first one seems to do the wrong thing because there is no mention of any stakeholder at all. Getting it working first is great though. The second one seems to do the right thing by demoing to stakeholders first. Then, it goes on to make it web scale with buzzwords (which doesn't seem good). The best combination seems to be: 1. demoing to higher up and 2. JIT (I'm not familiar with the word, but I get what you mean).
- alfiedotwtf 7y ago
  In the second case, because sprint velocity was on the up and the walls were covered full of bright colours, it looked like they were doing lots of work. The actually were doing lots of work, but none that the stakeholders cared about. The second team emphasised the importants of scale and how they were going to solve that problem. The apps to run on top seemed to slip everyone's minds because ticket were being closed hitting KPIs.
- k1t 7y ago
  When faced with building a simple web page, Team 1 spends a couple of days producing a single static html page and builds on it as necessary. Team 2 spends 6 months showing upper management architecture diagrams and flashy mockups. They blow a million dollars on cloud hosting their load balanced web servers. They've got Kafka, ElasticSearch, triple redundant SQL servers, and a 12 person team to run it all. But when asked to present the actual page they announce that nobody on the team knows HTML and they just kind of assumed somebody else would do that part. Non-technical managers cannot tell the difference between the two teams.
  - alfiedotwtf 7y ago
    lol, reading your description made me think you were there too... but you said $1M rather than $6M :)

islanderfun 7y ago

I don't believe I'm familiar with JIT in this context? Just in time development?

OJFord 7y ago
I haven't heard it either, but apparently it's another name for the Toyota system/'lean manufacturing': https://en.m.wikipedia.org/wiki/Just-in-time_manufacturing https://en.m.wikipedia.org/wiki/Just-in-time_manufacturing
- alfiedotwtf 7y ago
  Sorry. No, I wasn't referring to JIT Manufacturing... It was merely a tongue-in-cheek to mean just build what's needed right now in front of you, then get it working at scale once there's an actual needs to scale. This is in contrast to starting from day one spending most of your time thinking of scale, then building everything so that it can infinitely scale (along with the complexities that come with it), only to find out that you have 8 users and your data can fit entirely in memory.
  - dredmorbius 7y ago
    That sounds more like JDI / JGID -- just do it / just get it done. Sometimes "make it so" from ST-TNG.
  - OJFord 7y ago
    Oh, okay, sorry. (Fwiw searching 'JIT development' does net first page results of people talking about JIT/lean manufacturing in a software development context.)
  - mgkimsal 7y ago
    there's a vast middle ground between 'astronaut architecture' and 'common sense necessities', and knowing where a good cutoff point is is hard without experience. I've met more than a few folks who consider web templating systems to be 'overkill', and have 0 understanding of the risk of xss. Same with sql/db escaping - "I just write the SQL and run it, using all those libraries is just a waste of time", etc. Many of the projects I've come in to over the years were doing with a "JGID" mentality. And they did "get it done", "it" was just a steaming pile of crap when it was done. "Why is this taking weeks to do - the previous guy was so much faster?" Had this one last year: "This was never slow before when X worked on it, you've made changes what have you done? We need to call X back in to the project". X just "got it done". And X was a db admin who was writing code. And X decided it would be good to have views join against other views which joined against other views, and have some queries which used those views run in triggers. When X was on the project, and there were 40 users, it was fine. They hit 1000 users, and things were 'slow', so they upgraded to a larger EC2 instance. X left, and I came in, and several months later they hit ~30000 users (not active, just ... user account records). The system was dying with more than 5 active users, because of all the views joining other views on 30k+ records. Unravelling that meant deciphering all the views, all the queries, all the code that touched all of it, and rebuilding a moderate portion, without tests, known 'good' data, or anyone on the project knowing what 'right' was - they just knew when things looked 'wrong' (or slow). BUT... 18 months earlier, it was "JGID", and it got done. I'm still a bit perplexed why a professional DB admin thought views joining against multiple other views was a good approach. We've all got horror stories, I'm sure, it's just that the "JGID" mentality is often preached by competent experts as a good approach, but picked up by beginners as the approach used by experts, and has bad consequences.
    - dhuramas 7y ago
      Out of curiosity - Which database is this? and is it really taboo to have views joining against multiple other views? If the underlying views were performant- I'd assume the query optimizer would do the right thing(at least 90% of the time). EDIT: I guess it depends - Just did more research and found this [1]. As long as the views don't do unnecessary heavy lifting or joining unnecessary tables, it should be fine. [1] https://dba.stackexchange.com/questions/151169/are-views-harmful-for-performance-in-postgresql https://dba.stackexchange.com/questions/151169/are-views-har...
  - rambojazz 7y ago
    > just build what's needed right now in front of you What's needed right now, but that doesn't take a complete overhaul when it's time to start growing.
    - tyldum 7y ago
      It requires a very savvy developer in order to succeed. I have seen the massive technical debt this approach can give.
anoncake 7y ago
I think YAGNI is a more common term.

tanin 7y ago

Could you elaborate more? I'm a bit confused. The first one seems to do the wrong thing because there is no mention of any stakeholder at all. Getting it working first is great though. The second one seems to do the right thing by demoing to stakeholders first. Then, it goes on to make it web scale with buzzwords (which doesn't seem good). The best combination seems to be: 1. demoing to higher up and 2. JIT (I'm not familiar with the word, but I get what you mean).

alfiedotwtf 7y ago
In the second case, because sprint velocity was on the up and the walls were covered full of bright colours, it looked like they were doing lots of work. The actually were doing lots of work, but none that the stakeholders cared about. The second team emphasised the importants of scale and how they were going to solve that problem. The apps to run on top seemed to slip everyone's minds because ticket were being closed hitting KPIs.
k1t 7y ago
When faced with building a simple web page, Team 1 spends a couple of days producing a single static html page and builds on it as necessary. Team 2 spends 6 months showing upper management architecture diagrams and flashy mockups. They blow a million dollars on cloud hosting their load balanced web servers. They've got Kafka, ElasticSearch, triple redundant SQL servers, and a 12 person team to run it all. But when asked to present the actual page they announce that nobody on the team knows HTML and they just kind of assumed somebody else would do that part. Non-technical managers cannot tell the difference between the two teams.
- alfiedotwtf 7y ago
  lol, reading your description made me think you were there too... but you said $1M rather than $6M :)