- This topic has 9 replies, 1 voice, and was last updated 6 days, 19 hours ago by usernameqwerty005.
- January 12, 2021 at 7:33 pm #5680tstrvParticipant
[embed]https://www.youtube.com/watch?v=ivHMddlPbEo[/embed]January 12, 2021 at 7:33 pm #5682Fanor51Guest
I only believe in deadline driven development.January 12, 2021 at 7:33 pm #5683sbditto85Guest
So if I understand the difference between the CRM example and the Github example is with the CRM they knew up front they wanted to replace it based off of business needs and the Github example they assumed there would be more but didn’t consult with the business and it turns out the business actually didn’t care?
Otherwise in either example you might as well use a crystal ball to tell you if you should abstract or not. It’s always been a challenge for me to decide how much abstraction is helpful.
Loved the talk, and the more I code the more I agree that getting business people involved to make sure you deliver something that provides business value and doesn’t just end up as gold plated code is super important!January 12, 2021 at 7:33 pm #5684tzohnysGuest
Although I understand the need to produce features fast, especially when you have to deal with non-technical end-customers changing design patterns in the same project produces more problems than it solves in the end. On tight deadlines people will lean towards the easy approach and having always tight deadlines will lead to having most of your implementations made with the easy way. If it needs to be done, it must be very defined and clearly communicated.
From my experience the process of developing software is more important than design patterns. Having defined practices that are agreed by all, clear communication with all parties involved (from management to developers and end-customers) can get you a long way. The only true requirement is that your code should be as easy to test as possible.January 12, 2021 at 7:33 pm #5685sproingieGuest
In the end, _all_ activity is time-driven. It’s the ultimate inelastic supply.January 12, 2021 at 7:33 pm #5686NotSoSillyAfterAllGuest
I was pleasantly surprised by her insights. Though I am slightly disappointed that she didn’t actually talk about Time Driven Development after the first couple slides.
Though insightful, most of her talk was about how she abstracted the functionality in her application.
I did subscribe, though. I predict good things from this channel.January 12, 2021 at 7:33 pm #5687justlasseGuest
Well learned a bit more laravel best practices but that was about it…January 12, 2021 at 7:33 pm #5688Fenrir_25Guest
She finally has an YouTube channelJanuary 12, 2021 at 7:33 pm #5689systematicalGuest
The presenter started losing me at the slide that starts around 3:15 and then I closed the window on the next slide. She starts using an either/or mentality to setup her point.
You don’t have to choose between striving for unit tests and the value you provide for your users. The unit tests actually do provide value to the users for one and we are of course still coding for the user at the end of the day. Why do we need to choose between the two? This is a false dichotomy. Dear god.
I closed at “We’ve created a toxic environment that values the usage of good design practices above creating value for the users.”
I’d love to see this organization and take a job there. I generally see the other way around, we sacrifice good design practices to rush features out the door for the user. Which actually ends up hurting the user, the organization, the product, and the developer.
Edit: You can read the article here if you rather not sit through a YT video. The premise of the article is common-sense, nothing groundbreaking here: https://adevait.com/software/time-driven-development
You don’t have to choose, we are not robots, we know when we can forgo unit tests during MVP/protptype and when we need to start implementing them. We know the difference between throwing down prototype code versus cleaning it up with SOLID and nice design patterns.January 12, 2021 at 7:33 pm #5690usernameqwerty005Guest
Risk-driven development is the ordinary wording, no?
Compare with the spiral model: https://en.m.wikipedia.org/wiki/Spiral_model
- You must be logged in to reply to this topic.