Here's a few counter-examples of easily fixable bugs in closed systems that really bug me.
GitHub has a few tiny bugs that could probably be fixed with a few lines of code within a day (best case scenario), but they haven't for months now since I've reported these issues. http://shurcool.github.io/bettertogether/
The latest version of Chrome for iOS has a shadow not appearing properly when you open a new tab in the background. Once you switch to it, it's fine.
Chrome [1] for OS X has a small area around the close tab button where the hover animation occurs (button highlights red), yet clicking the mouse does nothing. You have to move the cursor a few pixels closer to the center before clicking will have an effect. This discrepancy between hover and clicking action is annoying because I often (several times per day) run into it. OS X dock has a similar issue.
I'm very picky when it comes to the smallest details... I'd rather fix them and move on than keep running into them every day.
[1] I know this one is open source, but because it's a huge project, I never got around to compile it, etc.
The Chrome example brings up a good point: it's a lot easier to fix niggling details on small projects than big ones. We could probably stand to see some innovation in architecting open products to be easy to install only part of into a development environment. The GitHub editing interface helps here, though project culture is another barrier. I fixed a typo on AngularJS and started to discover a heavier project structure than I'm used to:
I absolutely agree. I think we need to try to innovate how large scale complex software can be written.
One of the approaches I'm currently investigating and have high hopes for composition, pure functions, and explicit two-way dependency tracking. I'm trying to put this to the test in my work. The idea is that I hope even huge software can be decomposed into smaller independent (meaning all the dependencies are explicit) chunks with pre- and post-conditions. So fixing many bugs could boil down to navigating to the code responsible and fixing it there. It's too early for me to say how it'll work in reality, but I will find out with time.
Comments
Here's a few counter-examples of easily fixable bugs in closed systems that really bug me.
GitHub has a few tiny bugs that could probably be fixed with a few lines of code within a day (best case scenario), but they haven't for months now since I've reported these issues. http://shurcool.github.io/bettertogether/
The latest version of Chrome for iOS has a shadow not appearing properly when you open a new tab in the background. Once you switch to it, it's fine.
Chrome [1] for OS X has a small area around the close tab button where the hover animation occurs (button highlights red), yet clicking the mouse does nothing. You have to move the cursor a few pixels closer to the center before clicking will have an effect. This discrepancy between hover and clicking action is annoying because I often (several times per day) run into it. OS X dock has a similar issue.
I'm very picky when it comes to the smallest details... I'd rather fix them and move on than keep running into them every day.
[1] I know this one is open source, but because it's a huge project, I never got around to compile it, etc.
pull requests welcome and much appreciated ;-) https://github.com/balanced/balanced.github.com/issues https://github.com/balanced/balanced-dashboard/issues
you just reminded me of a mobile display issue on the blog: https://github.com/balanced/balanced.github.com/issues/32
The Chrome example brings up a good point: it's a lot easier to fix niggling details on small projects than big ones. We could probably stand to see some innovation in architecting open products to be easy to install only part of into a development environment. The GitHub editing interface helps here, though project culture is another barrier. I fixed a typo on AngularJS and started to discover a heavier project structure than I'm used to:
https://github.com/angular/angular.js/pull/2374
Maintaining a culture of innovation at scale is a challenge for both open and closed companies.
I absolutely agree. I think we need to try to innovate how large scale complex software can be written.
One of the approaches I'm currently investigating and have high hopes for composition, pure functions, and explicit two-way dependency tracking. I'm trying to put this to the test in my work. The idea is that I hope even huge software can be decomposed into smaller independent (meaning all the dependencies are explicit) chunks with pre- and post-conditions. So fixing many bugs could boil down to navigating to the code responsible and fixing it there. It's too early for me to say how it'll work in reality, but I will find out with time.