3 ms·
If I was trying to develop good developers, I'd add a 7th initial, recurring step to the vertical: Talk to your customer as often and directly as possible to en
by bob1029 2y ago
If I was trying to develop good developers, I'd add a 7th initial, recurring step to the vertical: Talk to your customer as often and directly as possible to ensure you are still working on the right problem.
It seems to me that a lot of wasted energy is in the form of working on problems that no one cares about. Not that this is necessarily bad (hobby, fun, art, side projects, new ideas, etc), but in a concrete business setting you need to be a bit more aggressive about making sure the customer still gives a shit about what you are working on over time.
I find all of this leads neatly into the 2nd most important thing for me which is making sure you have a good domain model (schema). If the tables, columns and relations that represent the business are high quality and accurate (I.e., your customer understands them), the code that follows will usually go smoothly. Staying on the customer's heels regarding the applicability of your software to the business means you can keep this well aligned over time.
I think much of the tech bloat we see today is a side effect of attempting to outrun the complexity of the customer's specific needs. After sitting on the phone with vendors and customers for a week, you will likely not find yourself playing around with the idea of using some esoteric language or infra to implement things. It's incredible what being directly exposed to the customers can do for a developer's growth.
- shinycode 2y agoIt’s completely true. Sometimes software development is at the crossroads of art and craftsmanship. So we like to do things nicely for the sake/pleasure of it and we can loose sight of what really matters. Most of the times, what really matters is the customer using the product and if the product is a tool, the most important criterias for him have to be aligned to what we spent the most time on. Sometimes we want to make a generic case out of specific ones in order for all customers to also benefit from it and that can lead us to higher, unnecessary levels of abstraction and sometimes because there isn’t enough it leads to hard to maintain spaghetti code that is working under specific conditions that are hard to evolve. The balance is thin and often blurry because it’s a bet on an uncertain future that depends on how well we can predict future business
- begueradj 2y ago> It seems to me that a lot of wasted energy is in the form of working on problems that no one cares about. That's where classic software methodologies such as Waterfall are good at: everything must be carefully discussed with the customer during the "requirements analysis" phase.
- BOOSTERHIDROGEN 2y agoWhat are the more modern methodologies?
- meiraleal 2y agoScrum, which means letting a clueless "scrum master" and "product owner" change directions twice a week so they can pretend to be working.
- cess11 2y agoOne must remember, Scrum is not agile.
- Viliam1234 2y agoAlso, Scrum-as-practiced-in-most-software-companies is not Scrum.
- meiraleal 2y agoAnd real communism has never been tried
- Viliam1234 2y agoMore like https://en.wikipedia.org/wiki/Sturgeon%27s_law https://en.wikipedia.org/wiki/Sturgeon%27s_law Most people are incompetent at what they do. That includes managers at software companies.
- 2y ago