To be fair MSFT finishes a lot of projects. The problem at MSFT is literally 1000s of little disconnected projects going on and no focus. I know because I worked on a couple of them earlier in the decade as a contractor and there was no clear focus on them. It was just - do whatever to make it working.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple's Flexible Engineering Teams Said to Operate Like a Startup
- Thread starter MacRumors
- Start date
- Sort by reaction score
To be fair MSFT finishes a lot of projects. The problem at MSFT is literally 1000s of little disconnected projects going on and no focus. I know because I worked on a couple of them earlier in the decade as a contractor and there was no clear focus on them. It was just - do whatever to make it working.
x-box and most of their corporate software have been very successful. online and mobile have been failures. most of microsoft's money is from products most consumers never see
Apple I see as being under staff and over worked. This thing I read more confirms the reports I have read about workers who have quite apple because they are burning out from those demands. That and months worth of work being screwed over by another group working on something else that you did not know about.
I was talking with one programmer/dev and their personal feeling on people who program with out proper comments and variable naming and she said that she does not call those people programmers but nothing more than hackers because the code is basically useless to any one but the person who wrote it.
The comments are visible if you have the source code any how. All poorly commented code does is slow down some one else figuring it out. It does not stop it. I think it is poor practice.
In my classes when I write code i normally go back and comment sections after I finish working on them but I do have comments that I put in as I write to make it easier for me to track and know what is going on. Now the comments in WIP code are full of more short hand notes. I name things to make them easier to track like prefex like int_, bln_,dbl_ ect to match to variable types and tend to comment what ever meathod I call.
Plus things like //end *meathod name or loop name*
I get how that organizational structure works because I am plugged into one as well. What I don't understand is why Remote is not simply getting some attention through time splicing. Being agile enough to go from project to project is fine, but being focused ONLY on one project at a time sounds like a bad feature to their particular meme, and a bit surprising.
Apple has so many "projects" from Remote to USB modem to Light Peak to USB3 to a thousand other things. It is probably true one engineer worked/works/will work on perhaps 2 dozen of them.
If I were Apple's manager I would add a time splice layer and have the engineer have three projects at a time, so when you get burned out on OSX7 and iOS4, during a long day or week, I find it helpful to "change gears" for an hour or so so another project with entirely different needs and priorities distracts the particular brain neurons being overworked by the main project.
In my case I go from designing some elaborate aerostructure or pressure retention system with its competing materials, thermodynamics, aeroelastics, and do something simple. Cut some steel on the tools. Or read Macrumors and parse all the wacky stuff people post, or get laid.
I would hope that Apple engineer has Remote in a second window he works on a bit at a time maybe 30-60 minutes a work day.
Just as folks need to take legal physical breaks, they need brain breaks too. Especially in such a high velocity and high frequency environment.
My comments are not specific to Apple either. They apply to any firm that employs this scheme to manage projects.
Having employed my suggestion for over 10 years now, I can tell you it also produces ah ha moments that translate into new projects later.
Rocketman
Apple has so many "projects" from Remote to USB modem to Light Peak to USB3 to a thousand other things. It is probably true one engineer worked/works/will work on perhaps 2 dozen of them.
If I were Apple's manager I would add a time splice layer and have the engineer have three projects at a time, so when you get burned out on OSX7 and iOS4, during a long day or week, I find it helpful to "change gears" for an hour or so so another project with entirely different needs and priorities distracts the particular brain neurons being overworked by the main project.
In my case I go from designing some elaborate aerostructure or pressure retention system with its competing materials, thermodynamics, aeroelastics, and do something simple. Cut some steel on the tools. Or read Macrumors and parse all the wacky stuff people post, or get laid.
I would hope that Apple engineer has Remote in a second window he works on a bit at a time maybe 30-60 minutes a work day.
Just as folks need to take legal physical breaks, they need brain breaks too. Especially in such a high velocity and high frequency environment.
My comments are not specific to Apple either. They apply to any firm that employs this scheme to manage projects.
Having employed my suggestion for over 10 years now, I can tell you it also produces ah ha moments that translate into new projects later.
Rocketman
Lean and Mean = best quality Green...
Having worked for a company that began as a start-up and matured into a glacial behemoth, I prefer the culture of the start-up.
There is no room for complacency, everything is a fire-fight and always very interesting. There is no room for retirement track folks who spend all day looking at message boards instead of doing work (whoops, look at me!) ;-)
Those who can't take the heat have to get out of the kitchen, and this "start-up" culture fosters a highly adaptable and dynamic workforce.
Upside: selects for the best team of hard working, can-do people that will make the personal sacrifice for company success.
Downside: Starved resources mean middle and lower priority projects get forgotten. What may be a middle tier priority for the company may be high priority for the customer.
My opinion...
TB
Having worked for a company that began as a start-up and matured into a glacial behemoth, I prefer the culture of the start-up.
There is no room for complacency, everything is a fire-fight and always very interesting. There is no room for retirement track folks who spend all day looking at message boards instead of doing work (whoops, look at me!) ;-)
Those who can't take the heat have to get out of the kitchen, and this "start-up" culture fosters a highly adaptable and dynamic workforce.
Upside: selects for the best team of hard working, can-do people that will make the personal sacrifice for company success.
Downside: Starved resources mean middle and lower priority projects get forgotten. What may be a middle tier priority for the company may be high priority for the customer.
My opinion...
TB
Depending on how well this is all managed, Apple is either an exciting and dynamic company to work for or a miserable hell hole.
Didn't Apple reject a lot of applications for "duplicating Apple functionality" or some such in the past? Kind of hard to create a replacement app if they're going to reject it on that basis.
It also fosters burn out. It's easy to dupe really young people into working this way. They think they are working for some great reward, even though most start-ups fail.
You can't take the heat forever. When you start feeling guilty about taking time off work to visit a dying relative or watching your kid's hockey game, you know you're cooked and it's time to get out.
Great for the engineers
Nothing worse than getting stuck in a rut and working on the same stuff day in and day out.
Nothing worse than getting stuck in a rut and working on the same stuff day in and day out.
The Way of The World....
Is adopting this very model of a small team of highly skilled individuals and moving their focus from one project to another. Keeps costs down and keeps the "corporate fat" from forming. It is a fact that in most "traditional" large corporations that 20% of the people do 80% of the work. This is because the majority of folks just aren't that bright, motivated, or focused.
Right now "lean" initiatives are gaining momentum in corporate America. What this means is more shrinkage in an already shrinking middle class. Let's face it, the majority of Americans don't have current skills, work ethic, etc.
And employers know this......so don't expect unemployement to get better anytime soon.
Is adopting this very model of a small team of highly skilled individuals and moving their focus from one project to another. Keeps costs down and keeps the "corporate fat" from forming. It is a fact that in most "traditional" large corporations that 20% of the people do 80% of the work. This is because the majority of folks just aren't that bright, motivated, or focused.
Right now "lean" initiatives are gaining momentum in corporate America. What this means is more shrinkage in an already shrinking middle class. Let's face it, the majority of Americans don't have current skills, work ethic, etc.
And employers know this......so don't expect unemployement to get better anytime soon.
Remote
I don't understand why this app is not one of the default-installed iPhone apps. Despite being super useful for controlling iTunes (and Airport Express speakers), using it in conjunction with iTunes DJ and crowdsourcing the music for a party is really, really fun. Everyone who has the app downloaded can request songs, vote songs up in the queue, etc. I would be emphasizing that kind of social interaction more.
I don't understand why this app is not one of the default-installed iPhone apps. Despite being super useful for controlling iTunes (and Airport Express speakers), using it in conjunction with iTunes DJ and crowdsourcing the music for a party is really, really fun. Everyone who has the app downloaded can request songs, vote songs up in the queue, etc. I would be emphasizing that kind of social interaction more.
Great to keep control in this manner, but it does help to explain why so many products are seemingly out of date.
If I *need* comments to understand someone's code, there's something wrong. The method is too big, it's doing too much, there are no test cases that help me understand what this part of the code is supposed to be doing.
There's no hard rule but if you're pushing 100 lines of code in a method there's probably some refactoring to do.
a lot of the cool companies like Google and Apple attract young unmarried people to work 90 hour weeks. MS used to be like that until people started getting married and having kids. i hear same thing is happening to google. no one with young children wants to work 90 hour weeks. it's too hard and people want to see their kids.
my first son i was like the walking dead for a year. babies have this tendency to wake up in the middle of the night to be fed
The average working age at NeXT was around 30-35. Apple's core engineering staff is often > 40.
I've worked for startups that are burn outs. Burn outs happen when the vision, talent and focus don't either exist or ever coalesce.
Too lazy to read through much more than the first page of posts, but for the couple posters who said that one of the problems is that the lead dev would have to point a new/jr coder in the right direction to update a given app...
...the issue is that they should not have to do that if they'd properly and thoroughly documented their code initially.
Problem is this is the thing that most of the (good) coders I know *hate* to do, either because it's no fun, or because it explicitly exists to make it easy for others to muck with their code.
If SJ mandated proper and thorough documentation of code, and simply hired more insanely smart coders, they could advance the ball on more projects at a time. Frankly I wish they would.
...the issue is that they should not have to do that if they'd properly and thoroughly documented their code initially.
Problem is this is the thing that most of the (good) coders I know *hate* to do, either because it's no fun, or because it explicitly exists to make it easy for others to muck with their code.
If SJ mandated proper and thorough documentation of code, and simply hired more insanely smart coders, they could advance the ball on more projects at a time. Frankly I wish they would.
And yet comments help no matter how you cut it. Standard name convention also help. Who wants to jump around cost looking at 20-30 different methods when a short comment covers everything the called method is going to do.
Comments help to skim threw code with out having to deal with reading it in per code form.
If you haven't looked at code you wrote six months ago and said to yourself "What the hell was I thinking here?" you haven't been in the business all that long. Test cases and short methods are no substitute for comments explaining what the business or real-world rationale is for a programming decision.
+1
I put lots of step-by-step, one-line comments explaining every non-trivial statement/block... Guess I read too much sample code & tutorials
This assumes that all engineers are essentially interchangeable and equal in talent and ability, which is far from the case.
This goes for those saying just hire more people. Why hire people just to hire people? You need to find good people who are going to do the job as good or better than the people you have already. Don't just hire mediocre people because they can do something while the good people work on something else.
And a heavily commented 1000 line method isn't a substitute for designing something clean and elegant enough that it documents itself.
Comments help, no doubt.
Absolutely true. There is one irrefutable truth about comments and documentation: people don't maintain them, and they're often wrong to begin with. Comments explaining WHY you did something that might seem odd or wrong--those comments are a good thing. E.g.,
// This is dumb but the front office demanded we associate accounts with a person instead of a group, so here's our translation so we can move on to dealing with the group.
Comments explaining what the code is doing are VERY BAD if you're working in a high-level language. ARM asm? Sure, sometimes. Objective-C or Perl or Ruby? If you're doing it right, it should be perfectly readable without comments. Your comments will only serve to mislead once the code is changed (if the comment was even accurate to begin with).
I'll add one more problem to WestonHarvey's list that often leads to code that "needs" comments--overuse of inheritance. This happens especially with programmers who have less than, say five or ten years' experience. They fall in love with the inheritance aspect of OO and build up impenetrable chains of abstraction and delegation.