3 ms·
Love this >>> "ship it when it's better than what's live now" Is a fantastic rule - as it is almost always measurable (even things like engineering quality ca
by lifeisstillgood 2y ago
Love this
>>> "ship it when it's better than what's live now"
Is a fantastic rule - as it is almost always measurable (even things like engineering quality can be measured (a little)) and so justifiable.
Also your last line (Deadlines are poverty) suggests that it’s a term you use a lot in your company - want to expand?
- skrebbel 2y ago> Also your last line (Deadlines are poverty) suggests that it’s a term you use a lot in your company - want to expand? Nah, I just invented it to make the comment feel more edgy. Your question made me realize that that's the only reason it was in there, so I edited it out. I mean I do believe that deadlines are poverty but the comment is sufficiently controversial without it. Basically, I think the idea of hiring highly intelligent and creative people, and then forcing them to work on assigned tasks on sticky notes given to them by "product managers", is an extremely brutal destruction of capital. Sucking the joy out of creative engineers seems like a very costly idea to me, and I'm not convinced that the project management benefits of doing so exceed that cost. Just see how fast and well and enthusiastic people can code when doing eg open source projects, or hackathons, or entire browsers (Ladybird), and so on. I think as a leader you should want to channel that joy and enthusiasm for your company's (and your people's) benefit. If you give people a lot of trust and freedom, and build a culture of eagerness to ship, you can get that. Deadlines then are an extreme buzzkill and I firmly believe it makes people less productive in the long term, particularly because they'll just do worse work and that compounds quickly.
- lifeisstillgood 2y ago>>> extremely brutal destruction of capital. Hell yes. This chimes with my own experience and attempts to build sane work environments wherever I can. I think software has a very unusual relationship to the “explore exploit” concept - in that most manual / labour intensive businesses probably work ok with 20% explore - but with software once the explore is done the exploit is a marginal cost - so one should tune software business to be very high explore ratios (lean processes etc). In other words hire great people and let them experiment. My general schtick is that software is a form of literacy - and if you hire an illiterate person to for example write your autobiography, the process they would have to come up with would look not dissimilar to most Agile projects. Or perhaps another way of looking at it - Linus Torvalds accepts patches that have made their way through several layers of “lieutenants” - why shouldn’t the CEO of corporate X be the owner of the codebase that runs the corporation ? In the end all the discussion should be about the code - if it is not about the code you are discussing the wrong thing. Anyway - completely agree with your points and your … passion? It’s in the right direction and good luck to your business :-)
- skrebbel 2y agoFwiw I agree with most of what you said, but as a business owner I can't let this one slide: > In the end all the discussion should be about the code - if it is not about the code you are discussing the wrong thing. The code is important, but in the end it's all about the customer. For us, if it's not about the customer (in the end), you're discussing the wrong thing. This is a key part of our "ship fast and incrementally" ethos - how can you tell whether something is better than what's in production now? By explaining how it impacts the customer.
- lifeisstillgood 2y agoYes - of course. I think as a peon in a vast multi national there is too much “other” - PowerPoints, project plans not connected at either end to real customers or real code. I want to at least connect one end :-)