61–70 of 206 posts
And since the 'world' of the chat is mostly epistemologically closed (except for Web search), there's no absolute tether point. Everything's subjective, and self-confirming.
I was about to post this thought on the latest "We're moving from tech/architecture X to Y" post on the HN front page today, but now I feel it belongs here. I was recently chatting with a friend about how we used to do so much more with so few developers: 20 years ago, we developed mission critical, real time software (trading systems) in C++ with team of a couple of dozen developers. The core trading kernel team was…
Earlier quoted context omitted.
Talking to the users, allowing them to show you what they are trying to do with your software, almost feels like cheating, because of how easy things suddenly appear to be when uncertainty fades away. Obviously, the number of uniquely different users has an influence, and users most often do not truly know what they need, but that's our job to tease appart. Turns out the users most often benefits from small changes t…
"What problem are we trying to solve?" is a question I have to ask constantly in corporate development environments, and rarely does anyone presenting the task to be done actually know the answer! It's very frustrating.
Software development untethered from the practical realities of the customer / user is what drives people insane. When developers are required to interact with the customer on a regular basis , the freewheeling effects described in this article are damped massively. The potential for insanity goes off the charts when the development team is siloed away in solitary confinement and the only interactions with the client…
Software development untethered from the practical realities of the customer / user is what drives people insane. When developers are required to interact with the customer on a regular basis , the freewheeling effects described in this article are damped massively. The potential for insanity goes off the charts when the development team is siloed away in solitary confinement and the only interactions with the client…
I was about to post this thought on the latest "We're moving from tech/architecture X to Y" post on the HN front page today, but now I feel it belongs here. I was recently chatting with a friend about how we used to do so much more with so few developers: 20 years ago, we developed mission critical, real time software (trading systems) in C++ with team of a couple of dozen developers. The core trading kernel team was…
It seems like you're implying that teams of 60-80 developers should be expected to outperform teams of 12. This is simply not true. The most important feature of source code as a language is that it allows precise mindshare among close knit teams. It doesn't guarantee it, but it makes it possible for people to talk about the product at a level that is otherwise very difficult.
A convenient side-effect of the source code is that it instructs the machine what to do. But instructing the machine was never the bottleneck, the essential difficulty of software development is in understanding what are the correct instructions to achieve some objective, not typing them out.
The problem is that communication doesn't scale at all. Having just 3 developers with good alignment about mental models, best practices, and design direction is hard enough, and if you found the right three people at the right time with the right ideas, you could generate billions of dollars of value.
Large monolithic teams on the order of 80 are a product of people in control not understanding how software development works, and how to make it work well.
Earlier quoted context omitted.
>> I think that over-reliance on analytics has had a similar effect I lost track of how many times the directors would tell us, "Since the analytics say A, we should do B." then the research person says, "Sure Jim, great idea, lets get a few rounds of useability research and confirm it first." Then the always predictable thing happens: Users never align with your analytics. Seeing data and seeing someone struggling t…
> Users never align with your analytics. Any good theories for how this happens (i.e. why the data fails to capture the struggle)?
I think it's because a lot of analytics are data points oriented instead of being workflow oriented. So you can see that feature A is not being used a lot, but it's very important in a particular flow. Feature B may be used a lot, but it can be only important for a particular class of users while very detrimental mentally for another class.
People use software for a needs, but rarely I've seen a need being highlighted when interpreting analytics data.
Earlier quoted context omitted.
> Simple example: feature X is rarely used (thus we should get rid of it) Oh man, I remember a very specific example of this: many years ago now, Google Chrome pushed an update that got rid of the option on the menu bar for "Close Tabs to the Right". I remember looking into the Google issue tracker where people were complaining, and some PM provided a "data-driven" justification: when people opened the context menu,…
For what it's worth, I definitely don't organize my tabs in a way where "close to the right" would be helpful in cleaning them up.
Earlier quoted context omitted.
> Simple example: feature X is rarely used (thus we should get rid of it) Oh man, I remember a very specific example of this: many years ago now, Google Chrome pushed an update that got rid of the option on the menu bar for "Close Tabs to the Right". I remember looking into the Google issue tracker where people were complaining, and some PM provided a "data-driven" justification: when people opened the context menu,…
For what it's worth, I definitely don't organize my tabs in a way where "close to the right" would be helpful in cleaning them up.