>There seems to be a growing assumption in software that small, simple, focused is always best.
Growing assumption? No, its an assumption that's always been there. I mean, isn't this the core of the Unix philosophy - small sharp tools? I'd rather have three separate programs that each are really good at what they do than a single program that's mediocre at what it does.
>Would I prefer to develop software in Visual Studio 5 rather than 20xx to avoid bloat?
I'd rather develop software in vim than either, and that goes back to what I was saying above. Vim is a tool that does one thing - edit text. I don't need my text editor to automatically suggest my next function call. I don't want my text editor to automatically compile code in the background. I don't want my text editor to take up hundreds of megabytes of memory to load metadata that I'll never use. I don't want my text editor to handle source control.
I want my text editor to edit text.
>What we want is well designed, coherent applications with equality of 'fit and finish' throughout. This is easier to achieve with a simpler application, so simple is being trumpeted as a virtue in itself. It isn't, though - we should be looking to develop applications as complex and powerful as both we can manage to develop well and our users can manage to use easily.
Specialization doesn't imply simplicity or lack of sophistication. Look at vim. Its unbelievably complex. I've spent years working with it, and I'm still learning new things about it. Its just that all the complexity and sophistication is focused towards one goal - making text editing faster. I can code faster in vim than I could in Visual Studio. The way I see it, a lot of VS's aids are like training wheels - they're great when you're starting out, but if you want to go fast, you'll have to leave them behind.
Maybe, within the Unix world, but there's a large software world beyond Unix, and that world seems to be grabbing onto 'simple is best' rather hard for my liking at present.
I'm pleased for you that you like the Vi family of editors - I'm relatively familiar with them, but can't stand them. I'll never understand its continuing popularity; I know other editors I'd judge as powerful in practical usage but which are no harder for an ordinary user than Notepad. When I want a straight text editor I use one, but there's more to developing code than just editing text and that's why I like Visual Studio (not that it's the best IDE necessarily, just the one I use for work) - it gives me a single, coherent, consistent interface for developing the program in a way that I find vastly more productive than when I was having to use plain text editors and jump between tools to accomplish routine tasks. I don't for one minute miss having to compile code to find I'd made a one-character typo that didn't compile, or had made a type referencing error. Nor do I miss having a separate window to jump to whenever I realised I needed to check out an individual file while on a bug hunt. I don't dispute IDEs have their training wheels and some of them get in the way, but plain editors have their obstructive limitations too. I use IDEs willingly having come from the other approach, not in ignorance of it.
To get back to my original point - we shouldn't be looking to make our tools simple but to make them ruthlessly focused on improving the user experience for our users. Talking paperclips are a bad idea but I don't believe that source control integration in an environment that will largely be used with source control is anything but a boon to developers or that other similar examples in other software are bad. We should be looking to make software as powerful as we can keep under control, not as simple / narrowly focused (I'm aware they're not the same but I don't believe the article would cite Vim as an example of simplicity) as we can manage. Workflow is good, context switch is bad.
Unfortunately the unix philosophy does not extend to enterprise software because the rank and file employees can not be expected to effectively synthesize their own optimal workflows from a collection of small, flexible tools.
Growing assumption? No, its an assumption that's always been there. I mean, isn't this the core of the Unix philosophy - small sharp tools? I'd rather have three separate programs that each are really good at what they do than a single program that's mediocre at what it does.
>Would I prefer to develop software in Visual Studio 5 rather than 20xx to avoid bloat?
I'd rather develop software in vim than either, and that goes back to what I was saying above. Vim is a tool that does one thing - edit text. I don't need my text editor to automatically suggest my next function call. I don't want my text editor to automatically compile code in the background. I don't want my text editor to take up hundreds of megabytes of memory to load metadata that I'll never use. I don't want my text editor to handle source control.
I want my text editor to edit text.
>What we want is well designed, coherent applications with equality of 'fit and finish' throughout. This is easier to achieve with a simpler application, so simple is being trumpeted as a virtue in itself. It isn't, though - we should be looking to develop applications as complex and powerful as both we can manage to develop well and our users can manage to use easily.
Specialization doesn't imply simplicity or lack of sophistication. Look at vim. Its unbelievably complex. I've spent years working with it, and I'm still learning new things about it. Its just that all the complexity and sophistication is focused towards one goal - making text editing faster. I can code faster in vim than I could in Visual Studio. The way I see it, a lot of VS's aids are like training wheels - they're great when you're starting out, but if you want to go fast, you'll have to leave them behind.