You'll have to pardon me for not reading the whole article; but you opened up saying you've never even followed this process yourself. That's a big red flag for me.
If history has taught us anything it is that just because it works on paper doesn't mean it works in reality.
1. Communism sounds great on paper, but we know it sucks...
2. Science works on paper a lot, but experimental physicist exist because it can't always work.
3. When Dr. Phil comes out with a weight loss plan, no one with 2 brain cells believes it actually works (cause ya know, he never lost weight on it).
4 (and my biggest point). If it's so great why have you yourself been unable to follow it? Could it be that your process is unrealistically challenging, or maybe it doesn't account for many real world issues. But I'm willing to bet that you think you write great software already and don't need to follow your own guidelines.
The bottom line is that until you become your own activist (meaning you follow the principals rigidly and write good software) you can't preach it.
You don't see people running around promoting a religion they don't even follow.
Consider Linux on the desktop vs OS X or even Windows. Sure, I use and sorta like it, but I don’t think I could keep a straight face if I tried to tell you it was higher quality.
I'd honestly want someone to elaborate on this.
Personally, after spending lots of time with GNU/Linux and BSD, I find it physically painful to use Windows. Even with the existence of alternative DEs, third-party package managers and whatnot, your entire perception of what an OS should be simply changes after being exposed to the Unix way and you never really go back.
For context, my normal desktop environment is wmii running on Linux. I also find Windows physically painful. The problem is that the reason this works for me is that I'm able and willing to put up with an awful lot of bullshit and have a reasonably good ability to debug things when they're not working properly.
I pretty much agree with your description of what it's like to run Linux. However, I don't see how that makes Windows or OS X better than Linux.
With Windows, you have to put up with at least as much BS, if not more, and whether or not you can debug things is irrelevant because the system is opaque. At least in Linux there are plain text configuration files if the worst comes to the worst.
With OS X, things work fine as long as you don't try to do anything with it that Apple didn't explicitly design for. As soon as you try to color outside those lines, it's at least as much BS as Linux, and while the configuration files are technically text files, they're not plain text, they're XML (PList files), which means that you end up having to use customized tools to hack on them instead of a plain text editor. So debugging things is not as easy as on Linux, although it's still a lot easier than on Windows.
I also find Windows physically painful. With Nuget, third-party devs have started addressing the worst part of using Windows, which is package management, but it's still nothing like using apt or aptitude.
Furthermore, I rarely have to put up with debugging strange Linux problems. I use Linux Mint with Mate and it just works 99.9% of the time. The technology behind Mate is the old Gnome 2 environment, so it's very battle-worn.
I have to wonder what distro all the people complaining of strange Linux desktop bugs are using. Yeah, they happen, but are increasingly uncommon when using non-beta software (like Debian Wheezy or an Ubuntu or Ubuntu LTS release).
I find OSX to at least be a tolerable platform once I found out about the existence of homebrew, but as a development platform for anything other then platform-specific software, linux is peerless and I recommend it as a superior experience.
If your goal, on the other hand, is to browse web pages, edit documents via wysiwyg interfaces, and maybe play some games, there really is nothing wrong from a UX perspective about Windows or OSX, and at least some minor problems with linux.
I can elaborate a little. (This feels like pointless stirring, because even "Linux desktop software" is a vague topic where people can point to things linux does better which are unrelated to my activities, as a windows home user (not yet a tech professional like most of HN) occasionally checking over the years to see if I can recreate windows life on a $0 OS)
Four or five years back, I was trying linux torrent clients and got round to deluge. I thought "Wow.. the UI layout and column choices, equal to utorrent.. the options... almost as comprehensive as utorrent, equally coherent... okay this big torrent is slow to load and there's the occasional crash, but apart from that this is as good as windows software". So torrenting was covered. Unfortunely, music playing, media playing, etc weren't. And built-in distro wares (eg abiword, ristretto) only serve as reminders that you're in windows minus. (In fairness, they might technically do everything wordpad and windows photo viewer do, while feeling less slick because the OS is behind in ergonomics). But thats me, waiting for a lucky free windows clone whether thats fair or not.
Wait, this is just a train of thought... and it's got almost nothing in it.
I'll save you the read: "Good software is produced by teams who represent the people they’re building software for."
I feel like this has to be backed up by something. I don't feel it's necessarily true, or even correlated with good software. Some good software tends to come from teams which have domain knowledge, but good software also comes from teams where not everyone on the team necessarily does. Sometimes just the UX team has the domain knowledge, and the programming team knows how to program really well. Sometimes they're one and the same. The author hasn't landed on anything here except perhaps "UX process is a relatively important part of creating good software."
I'll offer a deeper answer.
Good software is created by good process executed by people who understand both the importance of that process, as well as how to create.
Knowing how to create is step one. You must master the craft of software first, and find people who also have, or want to.
Good. Now you must understand process. As your software grows, it will cease to fit inside your head. You have to build systems surrounding your software that guarantee its quality, and bypass your feeble human limitations.
Good. Now, as your company grows, you must understand people. The relationships and complex interactions and psychology will cease to fit inside your head. You have to understand the motivations and limitations of people in general, and your specific people, and make sure your company aligns them all in the direction of quality. You must build a company that values quality, and values the quality process, above all else.
Build an organization which is aligned toward quality, and it will produce quality software.
> Anything you do that you did not set out to achieve is achieved by accident
I disagree. Software that incorporates deep domain knowledge often results in emergent features, i.e. features that offer huge benefits, but that are essentially free to implement (negligible effort) due to the underlying design.
I was expecting a discussion of best practices, but it doesn't actually talk about how to write good software at all. The title should be "Corporate incentives sometimes interfere with software engineering best practices when the software itself is the product". Also, there are a lot of assumptions - I imagine most technology startups need to write software, but many of them aren't in the business of selling it.
12 comments
[ 629 ms ] story [ 981 ms ] threadIf history has taught us anything it is that just because it works on paper doesn't mean it works in reality. 1. Communism sounds great on paper, but we know it sucks... 2. Science works on paper a lot, but experimental physicist exist because it can't always work. 3. When Dr. Phil comes out with a weight loss plan, no one with 2 brain cells believes it actually works (cause ya know, he never lost weight on it).
4 (and my biggest point). If it's so great why have you yourself been unable to follow it? Could it be that your process is unrealistically challenging, or maybe it doesn't account for many real world issues. But I'm willing to bet that you think you write great software already and don't need to follow your own guidelines.
The bottom line is that until you become your own activist (meaning you follow the principals rigidly and write good software) you can't preach it.
You don't see people running around promoting a religion they don't even follow.
I'd honestly want someone to elaborate on this.
Personally, after spending lots of time with GNU/Linux and BSD, I find it physically painful to use Windows. Even with the existence of alternative DEs, third-party package managers and whatnot, your entire perception of what an OS should be simply changes after being exposed to the Unix way and you never really go back.
With Windows, you have to put up with at least as much BS, if not more, and whether or not you can debug things is irrelevant because the system is opaque. At least in Linux there are plain text configuration files if the worst comes to the worst.
With OS X, things work fine as long as you don't try to do anything with it that Apple didn't explicitly design for. As soon as you try to color outside those lines, it's at least as much BS as Linux, and while the configuration files are technically text files, they're not plain text, they're XML (PList files), which means that you end up having to use customized tools to hack on them instead of a plain text editor. So debugging things is not as easy as on Linux, although it's still a lot easier than on Windows.
Furthermore, I rarely have to put up with debugging strange Linux problems. I use Linux Mint with Mate and it just works 99.9% of the time. The technology behind Mate is the old Gnome 2 environment, so it's very battle-worn.
I have to wonder what distro all the people complaining of strange Linux desktop bugs are using. Yeah, they happen, but are increasingly uncommon when using non-beta software (like Debian Wheezy or an Ubuntu or Ubuntu LTS release).
If your goal, on the other hand, is to browse web pages, edit documents via wysiwyg interfaces, and maybe play some games, there really is nothing wrong from a UX perspective about Windows or OSX, and at least some minor problems with linux.
I'll save you the read: "Good software is produced by teams who represent the people they’re building software for."
I feel like this has to be backed up by something. I don't feel it's necessarily true, or even correlated with good software. Some good software tends to come from teams which have domain knowledge, but good software also comes from teams where not everyone on the team necessarily does. Sometimes just the UX team has the domain knowledge, and the programming team knows how to program really well. Sometimes they're one and the same. The author hasn't landed on anything here except perhaps "UX process is a relatively important part of creating good software."
I'll offer a deeper answer.
Good software is created by good process executed by people who understand both the importance of that process, as well as how to create.
Knowing how to create is step one. You must master the craft of software first, and find people who also have, or want to.
Good. Now you must understand process. As your software grows, it will cease to fit inside your head. You have to build systems surrounding your software that guarantee its quality, and bypass your feeble human limitations.
Good. Now, as your company grows, you must understand people. The relationships and complex interactions and psychology will cease to fit inside your head. You have to understand the motivations and limitations of people in general, and your specific people, and make sure your company aligns them all in the direction of quality. You must build a company that values quality, and values the quality process, above all else.
Build an organization which is aligned toward quality, and it will produce quality software.
I didn't go into enough depth, but this guy did: https://en.wikipedia.org/wiki/W._Edwards_Deming
But yes, for a team of one, it is probably closely aligned with how well you understand your users.
I disagree. Software that incorporates deep domain knowledge often results in emergent features, i.e. features that offer huge benefits, but that are essentially free to implement (negligible effort) due to the underlying design.