4 ms·

I'm sorry to hear that, indeed, the engineers have to follow through on their end as well. That means "working" software, minimally functional, has to be delive

I'm sorry to hear that, indeed, the engineers have to follow through on their end as well. That means "working" software, minimally functional, has to be delivered ASAP, at least to be able to gouge customer engagement. "Design Patterns" and the latest "Web Framework" fad are the opposite of delivering working software. How you find people with the right mentality? I'm not sure. Low-level game devs tend to have that "make it work" mentality but they like to reinvent the wheel a little too much because the existing wheel is 0.1% slower than their custom made one. Web devs are the opposite, they seem to think the wheel has manifested itself from the ether. They probably don't even know about half of the 50 wheels they brought into the project, and they'll replace them with newer, shinier wheels in a week. I think hiring a good team lead with the right priorities is key. Not a "manager", but the team member everyone else looks up to and follows out of their own volition. It might be worth wasting a lot of money and time on finding and hiring that person at the very beginning. If you do, the rest should fall into place, as they'll hire people who work well with them, meaning same priorities. Look at the impact someone like Jim Keller had on the companies he worked for, as an example.

blowski 4y ago
Yep, both managers and contributors have a faulty model of agile. We're all guilty of it, even those of us who know it when we see it because we know the theory so well. Finding people with the right mentality is, as you say, very hard. The temptation of the manager is to get people with the wrong mentality and wrap them enough process that it will fix them. The temptation of the contributor is to blame the manager without looking at their own faults. As good a solution as I can suggest is to work with people who are willing to collaborate on a positive outcome, and go through genuine continuous improvement.
- sirwhinesalot 4y ago
  And just to clarify, I've been both the "shinny new framework" and the "I can make it 0.1% more efficient" guy at different points in my admittedly short career (still a senior though). These days I'm the "make it work" guy but only after suffering the negative outcomes of the other two a little too much. You only really "get it" after doing the "wrong" way first. I've also had to deal with the "bad" manager that gives no push (nor any time) for stabilization, leading the code to a near-project-killing state of constant malfunction. Quite a few of the principles in the manifesto are about avoiding exactly this state, but they too are not followed correctly. The following are in a different order in the manifesto, but I think this should be the way to read them, they almost form a coherent paragraph: "Continuous attention to technical excellence and good design enhances agility. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." This means quality needs to be considered from the beginning and maintained, but that's not contradicting the fast delivery, quite the opposite (proven by many studies on Continuous Delivery). Quality arises from constant refactoring the working code to be better, based on the results obtained from seeing that code running. Not from planning ahead with some insane micro-service bullshit architecture 3 months in advance for a project that probably will never scale to a size that needs that nonsense (at which point you deal with it). But you have to give time for that cleanup work, and introduce a culture that demands that quality (where quality is measured by the software working well and delivering value, not by how theoretically "clean" the code is) otherwise it simply won't happen. I've also had to deal with the "good" manager that tries to fix the above issues (after they happened) with processes. In my experience they just slow down velocity and don't resolve any of the actual problems. It's like telling a plumber that is almost swimming in shit to read and sign a 20 page document before turning off the valve of the pipe that's spewing brown liquid everywhere. That plumber is just going to hate you. The only thing that works is to demand both continuous delivery and consistent quality (and allow time for the latter at the expense of the former if need be), ensure you have the right lead, communicate openly and regularly, and then let the team do its thing. If the devs and PMs don't see each other as allies rather than annoyances, the whole thing falls apart. Also all it takes is 1 bad dev to spoil the bunch, I've seen them do so much damage it's nuts (stuff like introduce some whole new web framework nobody else in the team knows on some part of the project, or rework entire parts of the code to be async even though then it doesn't work with the rest of the codebase). Code review / pair programming is supposed to prevent this but if the team lead lacks the strength to keep devs like that in line, you're screwed anyway. "Individuals and interactions over processes and tools" If the individuals and interactions are wrong, no amount of processes and tools will fix it... I guess companies the size of Microsoft and Google can throw enough money at the problem that things work out somehow, despite the abysmal quality of most of their software.

blowski 4y ago

Yep, both managers and contributors have a faulty model of agile. We're all guilty of it, even those of us who know it when we see it because we know the theory so well. Finding people with the right mentality is, as you say, very hard. The temptation of the manager is to get people with the wrong mentality and wrap them enough process that it will fix them. The temptation of the contributor is to blame the manager without looking at their own faults. As good a solution as I can suggest is to work with people who are willing to collaborate on a positive outcome, and go through genuine continuous improvement.

sirwhinesalot 4y ago
And just to clarify, I've been both the "shinny new framework" and the "I can make it 0.1% more efficient" guy at different points in my admittedly short career (still a senior though). These days I'm the "make it work" guy but only after suffering the negative outcomes of the other two a little too much. You only really "get it" after doing the "wrong" way first. I've also had to deal with the "bad" manager that gives no push (nor any time) for stabilization, leading the code to a near-project-killing state of constant malfunction. Quite a few of the principles in the manifesto are about avoiding exactly this state, but they too are not followed correctly. The following are in a different order in the manifesto, but I think this should be the way to read them, they almost form a coherent paragraph: "Continuous attention to technical excellence and good design enhances agility. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." This means quality needs to be considered from the beginning and maintained, but that's not contradicting the fast delivery, quite the opposite (proven by many studies on Continuous Delivery). Quality arises from constant refactoring the working code to be better, based on the results obtained from seeing that code running. Not from planning ahead with some insane micro-service bullshit architecture 3 months in advance for a project that probably will never scale to a size that needs that nonsense (at which point you deal with it). But you have to give time for that cleanup work, and introduce a culture that demands that quality (where quality is measured by the software working well and delivering value, not by how theoretically "clean" the code is) otherwise it simply won't happen. I've also had to deal with the "good" manager that tries to fix the above issues (after they happened) with processes. In my experience they just slow down velocity and don't resolve any of the actual problems. It's like telling a plumber that is almost swimming in shit to read and sign a 20 page document before turning off the valve of the pipe that's spewing brown liquid everywhere. That plumber is just going to hate you. The only thing that works is to demand both continuous delivery and consistent quality (and allow time for the latter at the expense of the former if need be), ensure you have the right lead, communicate openly and regularly, and then let the team do its thing. If the devs and PMs don't see each other as allies rather than annoyances, the whole thing falls apart. Also all it takes is 1 bad dev to spoil the bunch, I've seen them do so much damage it's nuts (stuff like introduce some whole new web framework nobody else in the team knows on some part of the project, or rework entire parts of the code to be async even though then it doesn't work with the rest of the codebase). Code review / pair programming is supposed to prevent this but if the team lead lacks the strength to keep devs like that in line, you're screwed anyway. "Individuals and interactions over processes and tools" If the individuals and interactions are wrong, no amount of processes and tools will fix it... I guess companies the size of Microsoft and Google can throw enough money at the problem that things work out somehow, despite the abysmal quality of most of their software.