3 ms·

I'll disagree with a few points here. First, I think that the key is a mindset, not an age--I'm the youngest person at my company and yet I'm consistently the

I'll disagree with a few points here. First, I think that the key is a mindset, not an age--I'm the youngest person at my company and yet I'm consistently the one pushing for smarter, smaller, better-designed solutions to our problems. It seems that a lot of people, especially those with an academic background, forget one of the three qualities of a good programmer: extreme laziness. Developers (often younger ones) that manically hop from framework to framework and sprint to sprint because design work is "too slow" end up expending more energy than if they'd just been lazy and really thought about what they wanted to accomplish before they worked on it. This is especially true in business, where that mindset is invaluable for skipping work you'd otherwise do while finding fit. Second, I disagree that on a good team engineers aren't fungible: the fact is that, if you have one person who "owns" a part of the code, you are inviting disaster and bad design. This, and not its converse, has been proven to me over and over the last decade. Sure, one person might have the domain expertise or familiarity with something to really nail it, but they should never be the only one on the team who can do so. If they are, you slip them pizzas under the door, make them happy and productive, and then sack them as soon as you can extract their knowledge for they are a liability waiting to turn into a problem. Third, and perhaps most controversially, the author supposes that good design is important. For almost any business, sadly, it isn't. Nobody gives a shit when you have deadlines to meet and bills to pay--and if you're lucky, you can push that burden up onto the next poor bastard to inherit the codebase after you've cashed out. I really, really wanted to believe that good design mattered, that somehow it had intrinsic value. Sad thing is, it doesn't. BeOS failed. Plan9 failed. Inferno failed. Transmeta failed. Sun and SGI failed. Smalltalk failed. Lisp failed. Erlang failed (and cleverly stood back up, but not because the majority knew or cared about design).

EdSharkey 12y ago
But NextSTEP didn't fail. It succeeded, in the biggest, most spectacular way I can imagine an operating system would. So, design does matter. Design seems to matter a great deal at Apple, so that backs up your other point that most other businesses could care less about their software's design and that NextSTEP at Apple is an exception.
- angersock 12y ago
  BeOS !== NextSTEP http://en.wikipedia.org/wiki/BeOS http://en.wikipedia.org/wiki/BeOS
  - EdSharkey 12y ago
    I brought up NextSTEP because it was a notable success that was not mentioned by the parent comment. And arguably, NextSTEP is a success story because of its design which enabled it to crossover successfully into mobile through iOS. NextSTEP's blueprint allowed iOS to operate at a performance level that other OS'es and architectures could not match when it debuted. BeOS was fine, but it was rightly or wrongly seen as a spiritual successor to Amiga, which only had a niche market. NextSTEP wanted to be a spiritual successor to MacOS, but never really could until Steve Jobs forced it in there. Even so, the technical design points of NextSTEP were well-suited for a resource constrained mobile platform, and that is one reason iOS has been such a success.
    - the_why_of_y 12y ago
      Agree with you that NextSTEP is well designed (at least in the upper layers, not necessarily the Mach-based kernel...) but the reason why it succeeded where BeOS failed are not technical: BeOS failed because of network effects (market too small for ISVs) and Microsoft actively preventing OEMs from installing it, and NextSTEP avoided both of these problems by being bought by Apple. iOS is not really running on a "resource-constrained" platform; the first iPhone already had 128MB RAM, which was a lot of RAM for a PC in 1999, in particular considering the low screen resolution. Apple just got the timing right; the mobile hardware became powerful enough to run "real" OSes (instead of things like Symbian or WinCE that were actually developed for resource-constrained hardware) around 2005.
TheCondor 12y ago
Actually, because you have deadlines and bills, that's why design does matter. There are definitely echo chambers where it doesn't, or at least it seems like it doesnt, but when it comes to making real money being able to deliver on time with quality matters more than anything else.
4ydx 12y ago
You sack them as soon as you have their knowledge? Seems a bit extreme. Or you are simply saying that the person in question is aggressively keeping people off of their turf? That must be it :P I have been working at a small startup for the past 6 years. The code is all mine so sometimes it is a bit hard to relate to all of the internal struggles that programmers seem to have.
fsloth 12y ago
" if you have one person who "owns" a part of the code, you are inviting disaster and bad design. " I think we have different definitions of ownership. To me, ownership signifies that a certain person is aware of the history of a particular area of code, is responsible for keeping it in good shape and is usually the go-to person for all modification, or at least code reviews all work done to the code. This does not mean that they should be the only one who understands it and has the ability to modify it. I think we both agree that the understanding of the code should be dispersed, so that any other employee can get up to speed with the code just in case the prior owner exits the organization. I'm working at an organization that some parts of which do development in the "share all" mentality and some of which try to maintain code ownership in the way I described. The code ownership strategy seems to work much better, but, YMMV as always. When the code ownership is not made explicit, actually there can develop pockets of "accidental ownership" even in the "share all" codebase. Something that only one person has ever touched, and who does all the modifications because all the organization needs is a tiny, quick tweak, and the codebase is already a hot mess after endless amount of these "quick tweaks". "I really, really wanted to believe that good design mattered, that somehow it had intrinsic value. Sad thing is, it doesn't. BeOS failed. Plan9 failed. Inferno failed. Transmeta failed. Sun and SGI failed. Smalltalk failed. Lisp failed. Erlang failed" Those all are large scale systems, so I cannot speak for them. However, in the scale of day to day coding, I've usually attempted applying good design to all of my prodcution code and usually the only feedback I've got from my way of working has been positive. I've shipped on time and the bugcount (for all I know) has been low. So, based on my experience, I really cannot concur with you. Perhaps our experience from software development is from a completely different business area. Professionally I specialize in performance critical C and C++, 8 years and counting so perhaps I've not been long enough in the field just yet to witness the fail of good design.
- angersock 12y ago
  I suspect our experience is indeed different. :) I've had the good fortune of working with good programmers doing performance critical C and C++ for a hobby project--the time spent in design has paid off, and the codebase is a joy to work with. Sadly, the code has yet to see the light of day, because reasons. For the purpose of "get game project finished", more bad code faster probably would've been better, though we would've had to rewrite it anyways. As for the rest, I've been in a few shops now where people who should've known better (or who didn't!) have written klocs and klocs of unmaintainable poorly-performing garbage and who subscribe to the "code owner" philosophy. The result is, of course, that you can't fix or even organize their messy fiefdoms, and so there is no peace-of-mind to be had that the code works. And yet, the businesses still trundle along to this day despite what is probably stage 4 cancer of the IP. Maybe it's just Stockholm syndrome. I kind of feel like an abused puppy every time I have to look at that code and fight, for hours and weeks, to do something as basic as "Hey, maybe we should try both debug and release targets!"

EdSharkey 12y ago

But NextSTEP didn't fail. It succeeded, in the biggest, most spectacular way I can imagine an operating system would. So, design does matter. Design seems to matter a great deal at Apple, so that backs up your other point that most other businesses could care less about their software's design and that NextSTEP at Apple is an exception.

angersock 12y ago
BeOS !== NextSTEP http://en.wikipedia.org/wiki/BeOS http://en.wikipedia.org/wiki/BeOS
- EdSharkey 12y ago
  I brought up NextSTEP because it was a notable success that was not mentioned by the parent comment. And arguably, NextSTEP is a success story because of its design which enabled it to crossover successfully into mobile through iOS. NextSTEP's blueprint allowed iOS to operate at a performance level that other OS'es and architectures could not match when it debuted. BeOS was fine, but it was rightly or wrongly seen as a spiritual successor to Amiga, which only had a niche market. NextSTEP wanted to be a spiritual successor to MacOS, but never really could until Steve Jobs forced it in there. Even so, the technical design points of NextSTEP were well-suited for a resource constrained mobile platform, and that is one reason iOS has been such a success.
  - the_why_of_y 12y ago
    Agree with you that NextSTEP is well designed (at least in the upper layers, not necessarily the Mach-based kernel...) but the reason why it succeeded where BeOS failed are not technical: BeOS failed because of network effects (market too small for ISVs) and Microsoft actively preventing OEMs from installing it, and NextSTEP avoided both of these problems by being bought by Apple. iOS is not really running on a "resource-constrained" platform; the first iPhone already had 128MB RAM, which was a lot of RAM for a PC in 1999, in particular considering the low screen resolution. Apple just got the timing right; the mobile hardware became powerful enough to run "real" OSes (instead of things like Symbian or WinCE that were actually developed for resource-constrained hardware) around 2005.

TheCondor 12y ago

Actually, because you have deadlines and bills, that's why design does matter. There are definitely echo chambers where it doesn't, or at least it seems like it doesnt, but when it comes to making real money being able to deliver on time with quality matters more than anything else.

4ydx 12y ago

You sack them as soon as you have their knowledge? Seems a bit extreme. Or you are simply saying that the person in question is aggressively keeping people off of their turf? That must be it :P I have been working at a small startup for the past 6 years. The code is all mine so sometimes it is a bit hard to relate to all of the internal struggles that programmers seem to have.

fsloth 12y ago

" if you have one person who "owns" a part of the code, you are inviting disaster and bad design. " I think we have different definitions of ownership. To me, ownership signifies that a certain person is aware of the history of a particular area of code, is responsible for keeping it in good shape and is usually the go-to person for all modification, or at least code reviews all work done to the code. This does not mean that they should be the only one who understands it and has the ability to modify it. I think we both agree that the understanding of the code should be dispersed, so that any other employee can get up to speed with the code just in case the prior owner exits the organization. I'm working at an organization that some parts of which do development in the "share all" mentality and some of which try to maintain code ownership in the way I described. The code ownership strategy seems to work much better, but, YMMV as always. When the code ownership is not made explicit, actually there can develop pockets of "accidental ownership" even in the "share all" codebase. Something that only one person has ever touched, and who does all the modifications because all the organization needs is a tiny, quick tweak, and the codebase is already a hot mess after endless amount of these "quick tweaks". "I really, really wanted to believe that good design mattered, that somehow it had intrinsic value. Sad thing is, it doesn't. BeOS failed. Plan9 failed. Inferno failed. Transmeta failed. Sun and SGI failed. Smalltalk failed. Lisp failed. Erlang failed" Those all are large scale systems, so I cannot speak for them. However, in the scale of day to day coding, I've usually attempted applying good design to all of my prodcution code and usually the only feedback I've got from my way of working has been positive. I've shipped on time and the bugcount (for all I know) has been low. So, based on my experience, I really cannot concur with you. Perhaps our experience from software development is from a completely different business area. Professionally I specialize in performance critical C and C++, 8 years and counting so perhaps I've not been long enough in the field just yet to witness the fail of good design.

angersock 12y ago
I suspect our experience is indeed different. :) I've had the good fortune of working with good programmers doing performance critical C and C++ for a hobby project--the time spent in design has paid off, and the codebase is a joy to work with. Sadly, the code has yet to see the light of day, because reasons. For the purpose of "get game project finished", more bad code faster probably would've been better, though we would've had to rewrite it anyways. As for the rest, I've been in a few shops now where people who should've known better (or who didn't!) have written klocs and klocs of unmaintainable poorly-performing garbage and who subscribe to the "code owner" philosophy. The result is, of course, that you can't fix or even organize their messy fiefdoms, and so there is no peace-of-mind to be had that the code works. And yet, the businesses still trundle along to this day despite what is probably stage 4 cancer of the IP. Maybe it's just Stockholm syndrome. I kind of feel like an abused puppy every time I have to look at that code and fight, for hours and weeks, to do something as basic as "Hey, maybe we should try both debug and release targets!"