Slashdot Mirror

It doesn't seem to make any difference. We care, because we're really great at this stuff, but marketing trumps usability every time.

MySpace is well designed, you just can't see the forest for the trees.

Firstly, go read this article which talks about what geeks call "marketing", which is often used as a throwaway term for all the parts of running a software business that the programmers don't really understand or care about. MySpace has not done any serious marketing. It grew entirely through word of mouth.

Next, go actually look at MySpace, and do it through the eyes of a non-technical young person. I don't mean a 16 year old, though I'm sure there are lots there, I mean anybody under 35. MySpace offers the following things:

• It's distracting and fun. It has lots of features that let people spend their time just faffing around - redesigning their profile yet again, finding cool bands, seeing who their friends friends are, writing on peoples walls etc. If there's nothing good on TV and they don't have much energy it's an easy way to be entertained.

• It lets people express themselves. Ever wondered why almost every MySpace profile page is customised? Well, people just love to express themselves. How many people live in a room with no ornaments or posters or personal artifacts? Hardly anybody right? Why do people blow 8mb of memory on a wallpaper that will sit under their copy of Word for 90% of the day? Why do people use annoying custom ringtones that they change every few weeks? People like to customise their personal space, it's just a part of who we are, and MySpace allows you to do that.

• It's a quick and easy way for musicians to get their music out to the masses. See the example of Lily Allen in the UK for somebody who made it big via MySpace. Ditto for I think the Arctic Monkeys.

• It can be used as a dating site even though it's not marketed that way.

  It used to be that people met through local institutions ... if you go back and ask your grandmother how she met your grandfather I wouldn't be surprised to hear an answer like "we went to the same church" or "he worked in a local shop and I saw him every day when buying groceries". This sort of thing is now very uncommon. People live more isolated lives, and it's often hard to date people you meet through work due to workplace politics - this is especially true of slightly older types who are in management.

  So it's not surprising that surveys and studies everywhere show that use of internet dating is way, way up and growing all the time. But it still has some social stigma attached to it. MySpace lets you search peoples profiles by region and easily contact them, which is all you really need to have a "dating site", except anybody who is on there can simply say they are there because their friends are there, because they like the bands etc. And for people looking it's better too, as people tend to post (mostly) real photos and don't just make stuff up, because they know their friends might see it.

• It has lots and lots and lots of people

Some things MySpace doesn't have: technical sophistication, robustness, speed - all the things geeks value. These things do matter, look at how totally Facebook has crushed MySpace amongst those who have access to it. But never discount the value of a good social design, because these sites aren't tech demos, they are social networking sites.

Look, I know you CxO types are very busy and super important people [sarcasm] but lets not invent new words shall we? All the CEO is supposed to do is look good and say forward thinking things like "We intend to make profits this quarter."

It's the actual engineers that make companies like HP and Compaq move forwards.

TRY to run a company with engineers, and see what happens. Engineers build products, not businesses. They just don't operate at that level - it's not a question of intelligence, it's one of focus, perspective, and education. Check out this "fable" by Joel Spolsky for a good illustration.

I don't care how much marketting you spin on your new laptops, if you don't put a screen in [for example] it's not going to sell. Or if the damn thing weighs a ton, or the batteries explode or ....

It's not the engineers that decide features like weight, batteries, screen... that's what the marketing department should be doing. They determine what the customers want and balance market demand and operating budget with the engineer's estimate of what it takes to build these features and how they impact each other. (At least in an organization that's functioning - I'm making no claims either way regarding HP). They aren't (or shouldn't be) just about trying to "spin" poorly-wrought products.

Some of Dilbert may be right on, but you know... it's not gospel. Some of it is just comedy.

then either your engineers stink or you've put them in an impossible situation. A good engineer will rarely miss an estimate made with sufficient information unless you're pressuring them to commit to an unrealistic timeframe, asking them to develop something for which they had no input or control at the design phase, or you keep surprising them with other work that has a higher priority than their project work. As for sufficient information--if the engineer doesn't know enough to make an accurate estimate it is his responsibility to say so, and if you ignore that then it's not his problem when he misses a date. A relevant article here is Joel's piece on "The Development Abstraction Layer": http://www.joelonsoftware.com/articles/Development Abstraction.html

I think schedules are an interesting subject that can take pages to cover. A few thoughts anyway:

• Developers vary greatly in skill, education and motivation. Peopleware claims that the spread is 1 to 100 across industries (in other words, developer A takes 1 week for a task, developer B takes a couple of years for the same task). Personally, I've found the spread to be more like 1 to 20, which is still considerable. Joel has a nice article on the matter also.
• I've found that those at the high end require very little prodding to get things done. They work for the love of coding and for the enjoyment of shipping good code. This is the type of developer that doesn't need a deadline to get moving and may actually get frustrated and become ineffective when faced with a lot of red tape. This is also the type of developer you want to hire.
• If you have a team of mid range developers, schedules may be needed. Fortunately, I've never been in that position. That said, the company I currently work at has very detailed schedules, milestones and deadlines. Does that help or hinder all things considered? I can't honestly say. We do spend a lot of time maintaining that schedule and I get a feeling that it is a source of frustration for many. Personally, I'd rather do something productive. Working on a schedule does not result in a single line of code.
• Some developers require daily milestones and continuous supervision. Usually combined with low performance, they're both time intensive to manage and a drag on the team and the project. I've come to conclude that it is necessary to let go of this type of developer sooner rather than later.

From architect on up, one of your key job responsibilities is to push back on features, schedules and so on, and to set expectations right from the get-go. Early on, I used to laugh out loud when being told proposed dates by marketing. That didn't go over too well, of course, so I've adopted a more diplomatic way of saying 'no' since. :-)

The gist of it is that many executives believe in Spanish management (very well explained in Peopleware). This boils down to setting ridiculous schedules, asking for continuous overtime, etc. The idea being that every minute an engineer spends more will get the product out the door faster. Of course, this is not the case as Peopleware will tell you in great detail. It is also matched by my own experience.

However, if you push back with data in hand (such as a detailed sizing) and a constructive proposal what to do differently, you may very well end up with a more reasonable schedule, a good product and happiness all around.

A few more gems in Peopleware:

• Schedules are counterproductive. Teams that don't have schedules ouperform those that do by up to 50%.
• Overtime is only productive for one week.
• Cubicles are sinkholes of effectiveness. Why do Microsoft and IBM only have offices for engineers?

For those of you with a humorous bent, I highly recommend checking out Joel Spolsky's articles on project management. A few highlights:

• Human task switching considered harmful
• Joel's test to identify bad software companies

If you can get to a reasonable schedule (by way of reducing features, adding time or people), the TFA is a bit limited in its scope. I have a few recommendations that have worked for me in the past (your mileage will vary, and you should read Peopleware anyway):

• You need to have the spec in writing.
• You need to use source control, even as a single developer.
• You need to have a single button build.
• When the build breaks you roll back the change that broke it or you stop everything until it is fixed.
• You need to build daily. Or better yet, continuously.
• Unit tests are your friend. They're less useful on GUIs but for logic they're a godsend. Personally, I can crank out high quality code about twice as fast with unit tests (if you consider debug time). Reduced maintenance and improved sleep is a bonus.
• In the same vein - automated system testing (if possible) is a wonderful way to improve shipped quality. Your testers (if you have any) cannot test everything.
• Code reviews are great. We use code reviewer with great impact on code quality.
• Hire the best people only and fire those you have no hope of redeeming. It may sound harsh, but allowing an ineffective developer to remain on a team is a great way to kill both the team and the project.
• You must have a bug tracking system.

From architect on up, one of your key job responsibilities is to push back on features, schedules and so on, and to set expectations right from the get-go. Early on, I used to laugh out loud when being told proposed dates by marketing. That didn't go over too well, of course, so I've adopted a more diplomatic way of saying 'no' since. :-)

The gist of it is that many executives believe in Spanish management (very well explained in Peopleware). This boils down to setting ridiculous schedules, asking for continuous overtime, etc. The idea being that every minute an engineer spends more will get the product out the door faster. Of course, this is not the case as Peopleware will tell you in great detail. It is also matched by my own experience.

However, if you push back with data in hand (such as a detailed sizing) and a constructive proposal what to do differently, you may very well end up with a more reasonable schedule, a good product and happiness all around.

A few more gems in Peopleware:

• Schedules are counterproductive. Teams that don't have schedules ouperform those that do by up to 50%.
• Overtime is only productive for one week.
• Cubicles are sinkholes of effectiveness. Why do Microsoft and IBM only have offices for engineers?

For those of you with a humorous bent, I highly recommend checking out Joel Spolsky's articles on project management. A few highlights:

• Human task switching considered harmful
• Joel's test to identify bad software companies

If you can get to a reasonable schedule (by way of reducing features, adding time or people), the TFA is a bit limited in its scope. I have a few recommendations that have worked for me in the past (your mileage will vary, and you should read Peopleware anyway):

• You need to have the spec in writing.
• You need to use source control, even as a single developer.
• You need to have a single button build.
• When the build breaks you roll back the change that broke it or you stop everything until it is fixed.
• You need to build daily. Or better yet, continuously.
• Unit tests are your friend. They're less useful on GUIs but for logic they're a godsend. Personally, I can crank out high quality code about twice as fast with unit tests (if you consider debug time). Reduced maintenance and improved sleep is a bonus.
• In the same vein - automated system testing (if possible) is a wonderful way to improve shipped quality. Your testers (if you have any) cannot test everything.
• Code reviews are great. We use code reviewer with great impact on code quality.
• Hire the best people only and fire those you have no hope of redeeming. It may sound harsh, but allowing an ineffective developer to remain on a team is a great way to kill both the team and the project.
• You must have a bug tracking system.

From architect on up, one of your key job responsibilities is to push back on features, schedules and so on, and to set expectations right from the get-go. Early on, I used to laugh out loud when being told proposed dates by marketing. That didn't go over too well, of course, so I've adopted a more diplomatic way of saying 'no' since. :-)

The gist of it is that many executives believe in Spanish management (very well explained in Peopleware). This boils down to setting ridiculous schedules, asking for continuous overtime, etc. The idea being that every minute an engineer spends more will get the product out the door faster. Of course, this is not the case as Peopleware will tell you in great detail. It is also matched by my own experience.

However, if you push back with data in hand (such as a detailed sizing) and a constructive proposal what to do differently, you may very well end up with a more reasonable schedule, a good product and happiness all around.

A few more gems in Peopleware:

• Schedules are counterproductive. Teams that don't have schedules ouperform those that do by up to 50%.
• Overtime is only productive for one week.
• Cubicles are sinkholes of effectiveness. Why do Microsoft and IBM only have offices for engineers?

For those of you with a humorous bent, I highly recommend checking out Joel Spolsky's articles on project management. A few highlights:

• Human task switching considered harmful
• Joel's test to identify bad software companies

If you can get to a reasonable schedule (by way of reducing features, adding time or people), the TFA is a bit limited in its scope. I have a few recommendations that have worked for me in the past (your mileage will vary, and you should read Peopleware anyway):

• You need to have the spec in writing.
• You need to use source control, even as a single developer.
• You need to have a single button build.
• When the build breaks you roll back the change that broke it or you stop everything until it is fixed.
• You need to build daily. Or better yet, continuously.
• Unit tests are your friend. They're less useful on GUIs but for logic they're a godsend. Personally, I can crank out high quality code about twice as fast with unit tests (if you consider debug time). Reduced maintenance and improved sleep is a bonus.
• In the same vein - automated system testing (if possible) is a wonderful way to improve shipped quality. Your testers (if you have any) cannot test everything.
• Code reviews are great. We use code reviewer with great impact on code quality.
• Hire the best people only and fire those you have no hope of redeeming. It may sound harsh, but allowing an ineffective developer to remain on a team is a great way to kill both the team and the project.
• You must have a bug tracking system.

I couldn't agree more. Although I do find these stories completely hilarious, in many cases calling the users "stupid" is a little too much. Like you said, lots of them can be blamed on the design, and most of the rest on the fact that users have better things to do than read man pages all day. Heck, some of them even go outside once in a while. ;)

Now, if Microsoft would start learning design a decent inteface, maybe Hotmail wouldn't suck so much.

Let me quote Mr. Spolsky here:

When you design user interfaces, it's a good idea to keep two principles in mind:

      1. Users don't have the manual, and if they did, they wouldn't read it.
      2. In fact, users can't read anything, and if they could, they wouldn't want to.

http://www.joelonsoftware.com/uibook/chapters/fog0 000000062.html

I wrote a tool called Mr Schedule that's based on the Painless Software Schedules technique described Joel Spolsky. I've found the technique works very well.

Cheers
Andrew

Joel Spolsky had described a simple approach on his website:
    http://www.joelonsoftware.com/articles/fog00000002 45.html
Absolutely worth a read (like most of Joel's writings).

I've read two really good items on the subject of estimating software schedules. The first is Painless Software Schedules by Joel Spolsky, the Joel in Joel on Software. It's a quick read, and a lot of the comments here are giving the same advice all spread out. Even more useful is Waltzing With Bears by Tom DeMarco (ISBN 0932633609) (very talented author, I strongly recommend Peopleware to everyone), which is about managing risk on software projects, especially as it relates to time. This is one of the fundamental errors in the question "How long will it take?"--the inquirer wants an exact amount of time, so if you say it will take four hours, it should take exactly four hours. The problem is, you may luck out--someone may have had that feature in the program once already, and it was removed, so all you need to do is call some fully-tested code from a different place, or there may be high coupling, so that what looks like a really simple, straightforward change is insanely hard. Those two factors put together means giving an estimate should be something like "No more than forty hours, 75% probability of finishing within twenty-four hours, 50% chance of finishing within six hours, 25% of finishing within four hours, no quicker than an hour." As part of Waltzing With Bears, Tom DeMarco (and I assume others) put together a Riskology spreadsheet, intended to allow you to estimate schedule probability curves, which allows combining multiple probability curves to get an estimate more like "No faster than eight months, 75% within six and a half months, 50% within five months, 25% within ten weeks, no faster than four weeks." And always make sure the first number people hear is the worst case scenario--that's the one they're going to remember.

Other reading:
Coding Horror, How Long Would It Take If EVERYTHING Went Wrong?
Software Estimation: Demystifying the Black Art by Steve McConnell
Google on Estimating Software Projects

This might help: Painless Software Schedules.

I started watching the XGL videos. The first one was transparency. Funny: MS has had this capability since W2K--you just need Vitrite to activate it. Since I've never, ever, ever seen a really useful use of transparency* I'm glad they left this off by default.

* OS X's early use of semi-transparent title bars sucked when you had a bunch of windows in the same general area. Note that this is gone now. (On the other hand, they also got rid of tabs, and that totally sucks, so they're not exactly batting a thousand.) I've seen lots of people with semi-transparent terminal windows, but they're more in the "looks cool and doesn't hurt productivity much" camp, rather than being truly useful. Ditto for the transparent unused pallets in MS Office on OS X--I can't stand them, but they don't actually seem to hurt most people.

FYI, winzip might not be so small.

http://discuss.joelonsoftware.com/default.asp?biz. 5.331272.21

Revenues of WinZip Computing (WinZip)
2003 - $25,259,000
2004 - $24,928,000
2005 - $22,700,000

As of now, Microsoft stock is surprisingly quiet given the announcement that Bill Gates will step down. It should probably be going down. Ozzie is smart but not in the same class as Bill Gates. And it's really Ballmer that needs to go.

As of now, Microsoft stock is surprisingly quiet given the announcement that Bill Gates will step down. It should probably be going down. Ozzie is smart but not in the same class as Bill Gates. And it's really Ballmer that needs to go.

Professionaly, it is not only hard, but also a suicidal move. Read some Joel to understand.

If you work on bigger projects, you'll see that you can't just "go ahead and hack it together", cause you'll fuck your co-developers over and they need to know what you've changed in the code cause they need to work with it. And they'd like to know why you went out of your way to do a certain thing. You'd want your freedom in coding but also a system and style of coding to not be stuck with digging through spaghetti-code and what not.

It can "feel" very counter-productive cause you can't just do everything you want to (depends on the company and the team though) and have to document your code but it serves a reason things should be somewhat organized and being sure everyone is on the same level. Just look at Netscape, they were forced into a entire rewrite, because they felt it became "unmanageble" over time.

In a nutshell, programmers and computer scientists are uncomfortable with the fact that there's actual HARDWARE in the system, and this somehow taints their pure, beautiful software designs. That is to say, they unconsciously can't stand that software has to run on hardware. So, they've invented "virtual machines" to abstract away the icky hardware with all of its yucky "engineering hacks". Of course this is justified with the old, battered strawman of "portability". But really it's all about not having to worry about registers, MMUs, memory addresses (physical and virtual), I/O ports, etc.

But if you forget that ultimately, software is nothing more than machine code being interpreted by a CPU, then you've lost a huge part of what computers are all about.

Joel Spolsky says it best (OK, it's dated, but substitute Java for Pascal, and it still applies):

I've discovered that understanding pointers in C is not a skill, it's an aptitude. In Freshman year CompSci, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their Atari 800s when they were 4 years old. They are having a good ol'; time learning Pascal in college, until one day their professor introduces pointers, and suddenly, they don't get it. They just don't understand anything any more. 90% of the class goes off and becomes PoliSci majors, then they tell their friends that there weren't enough good looking members of the appropriate sex in their CompSci classes, that's why they switched. For some reason most people seem to be born without the part of the brain that understands pointers. This is an aptitude thing, not a skill thing - it requires a complex form of doubly-indirected thinking that some people just can't do.

The conspiracy is that the software industry has moved in a direction to accommodate people who don't understand pointers. To acknowledge pointers would be to admit that there's machine-addressable memory in the system, which would be to admit that there's hardware in the system.

And we can't have that, can we?

This numbering scheme will make people think this version will have the same impact as the 1.1 -> 2.0 migration, and help further the perception that Microsoft is doing this for Fire and Motion reasons.

The one problem with this, though, is that if the products they release are so-so to begin with (it's Beta!), but then don't improve over time, it disaffects those customers using those products. Google Calendar looks nice, but I can't/won't use it regularly until it has two-way Outlook Calendar syncing (which I'm not holding my breath for, either).

Also, Google Reader is rather bleh IMO compared to other online aggregating options. For me, the only really impressive, stable, I'd-recommend-it-to-others offerrings from Google are:

• Search
• Toolbar (although not for FireFox)
• Google Desktop Search
• GMail
• Google Maps

> Sometimes you simply can't patch things any more, and it is time to start over. [...] Apple realized this and moved from 6800 to PowerPC to X86.

I don't think Apple moved from PPC to x86 because of "patching", they moved because they could coerce Intel into giving them better prices on the chips (IBM didn't really care about Apple's business, and Apple's priorities and IBM's priorities didn't align). In fact, the same OS runs on both platforms with only a few changes to the kernel. 90% of the codebase (things like drivers, filesystems, etc.) run fine on either platform.

Now if you mean OS9->OSX and the ensuing rewrite, you're right. OS9 was terrible, and it was time to start over.

Joel has a different viewpoint, however: http://www.joelonsoftware.com/articles/fog00000000 69.html, "They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch."

Java is probably the best example of great technology held back by completely incompetent marketing.

Java is probably the best example of great technology that's killing the company that produced it. Java may well be the very thing that is killing Sun microsystems.

Java makes the hardware platform largely irrelevant, except in terms of raw performance and reliability. Sun Microsystems is a hardware company. Thus, the more popular Java is, the less relevant Sun Microsystems is. If you are using Java, why would you pay extra to go with Sun?

If this just doesn't make sense to you, there's a nice article that should illuminate the subject for ye...

Isn't this one of those bad ideas? Joel Spolsky seems to think so, and while he isn't an oracle, his opinion is worth something.

Suggest not rewriting the software and simply going through and improving where needed.

To quote Joel:

"What I wondered was, what happens if you take top-notch C++ programmers who dream in pointers, and let them code in VB. What I discovered at Fog Creek was that they become super-efficient coding machines. The code looks pretty good, it's object-oriented and robust, but you don't waste time using tools that are at a level lower than you need."

Check this link:
      http://www.joelonsoftware.com/articles/fog00000000 06.html

Joel Spolsky explained why CityDesk, written by a shop populated entirely by highly qualified C++ coders, is 95% VB. He has a frank discussion of VB's pros and cons as a development tool, and you may find that many points he discusses will resonate with you as you develop your reasoning. Even if you don't come to the same conclusion he does, it's an excellent discussion of just the topic you propose.

Really, reading his argument in the context of having a bunch of C++ coders build a nice Windows app in 2006, I think I'd probably conclude that C# was the way to go, as opposed to VB. But keep in mind that C#.NET and VB.NET are more alike than they are different. For most apps, the arguments for managed code (VB or other) are very potent.

My take: If you and every single developer on your team can't instantly see and explain the differences between the 4 arguments to this function:

void foo(std::string a, std::string * b, std::string & c, std::string *& d)

stop now and use managed code of some kind.

If you all can, think really hard about why you want to spend your talent managing memory instead of doing things that'll really make your application shine. (There are reasons. They don't apply to most apps.)

You have no idea what you're talking about. First, there is already such a major toolkit, but how many new Xaw apps have you seen lately?

Second, programming styles are relevant, perhaps moreso than anything else. Some programmers grok procedural code - they can write it well, they can understand what others have written, and it matches well with their conceptual understanding of the machine. Others are OOP advocates for exactly the same reasons.

Herein is the problem, though: it's basically impossible to write a single toolkit that fundamentally supports both paradigms. I know there are C++ bindings for GTK and C bindings for QT, but those are leaky abstractions that are orthogonal to how either toolkit is designed.

So, you're never going to get a single unified toolkit until you decide which basic plan you're going to follow, and then implement an abstraction layer that's featureful enough to allow the half of the coding population who hates your plan to use it efficiently anyway. These aren't minor inconveniences that a bit of handwaving can erase, but irreconcilable differences that you'll have to work around. Until that happens, we'll keep using and bitching about multiple toolkits.

According to the engineer, an Apple hiring manager named Mike Lampell is heading up a group inside Apple's storied iTunes division. The group is specifically hiring for 'C/C++ coders with a gaming background.' (Emphasis added.)

Every product in the marketplace has substitutes and complements. A substitute is another product you might buy if the first product is too expensive. Chicken is a substitute for beef. If you're a chicken farmer and the price of beef goes up, the people will want more chicken, and you will sell more.

A complement is a product that you usually buy together with another product. Gas and cars are complements. Computer hardware is a classic complement of computer operating systems. And babysitters are a complement of dinner at fine restaurants. In a small town, when the local five star restaurant has a two-for-one Valentine's day special, the local babysitters double their rates. (Actually, the nine-year-olds get roped into early service.)

All else being equal, demand for a product increases when the prices of its complements decrease. (Emphasis added.)

There is a precedent for what Apple may be doing here. Anyone remember the Atari 800? I bought one just so I could play Star Raiders. I bought it at a store outside Boston (IIRC at a Bit Bucket in Newton, MA) which had this set up on a 5-foot projection TV for video and a 100 Watt stereo driving the audio. The salesperson told me: THAT ONE GAME was responsible for something like half of their sales of the Atari 800. At the time (1980 or so), the Atari 800 cost me about $800... and I happily paid it so that I could play a ~$50 game. AND, once I got the computer, I bought many more applications and peripherals. Star Raiders was the "killer app" of its day.

Apple might be looking to do the same. Sell some subsidized games on iTunes for little money so as to encourage additional iPod sales. Once he consumer has the iPod, and has overcome paying its (non-negotiable) price, the barrier to buying more things for it is overcome. Increased iTunes sales. Even MORE profit for Apple. A larger market. Synergistic growth.

Someone else here mentioned about Disney. Kid sees friend playing Disney game on iPod. Kid Wants Game. Kid pesters parents incessantly. Parents buy an iPod for junior to play these nice kid-friendly Disney games. Kids become experienced users of an increasingly dominant platform. [Apocryphally, IBM gave (?) Selectric typewriters to schools to use in Touch Typing Classes. Said students go off into the business world and are faced with klunky manual typewriters. Secretaries all-so-often are the ones who Get. Things. Done. Not too hard to start persuading the PHBs to buy a Selectric typewriter. Lather, rinse, repeat.] Apple has done similarly with schools by offering a significant educational discount for their computers. Microsoft has a student discount for their Office suite. Hook 'em while they're young.

Here, Apple could hook 'em before they even GET to school! Like I said, Brilliant. Absolutely Brilliant!

These are two guys who have some good stuff to say about usability - Jakob Nielsen (http://www.useit.com/) and Don Norman (http://www.jnd.org/) - Don Norman is the author of 'The Design of Everyday Things', mentioned above.
Also worth a mention is Joel Spolsky - http://www.joelonsoftware.com/

• Software model should conform to user model: Always have the program do what the user expects.

I recently read "About Face 2.0" I found myself dis-agreeing with some of the details and felt there were a few ommisions but the definitions of software was sound

Also Joel on software has a great book excerpt online to get you in the mood

About face link
Joel book excerpt

I thought the article was bout one of the forums at Joel's site:

"The Business of Software"
http://discuss.joelonsoftware.com/?biz

All this anti-IDE angst, so let me give the opposite view. Beginning students should be focused on *programming.* A good IDE makes some key things standard and invisible: jumping to errors, debugging, etc. Then the students can just worry about programming, and not vi configuration problems and make files and so on.

I'm not sure that is totally true. If a person has learnt to debug programs and solve problems without those tools, they are often a better programmer. They are able to handle more complex code.

I think in some ways this is similar to teaching Latin and Ancient Greek in schools, which used to be common in English and Commonwealth schools 50 years ago. It has no real practical application (unless you need the latin words for biology, or are aiming to become a greek scholar), but in itself it was good training for the mind.

Why teach programmers assembler? Most programmers will never use it. On the other hand it makes them better programmers.

It looks like I am not the only one who thinks that.

http://www.joelonsoftware.com/articles/fog00000000 69.html

... be sure to read Things You Should Never Do, Part I from JoelOnSoftware.
 
People have varying opinions on his work, but in this situation, if you can't answer his [objections] you should not rewrite.

"Things you should never do, Part 1": http://www.joelonsoftware.com/articles/fog00000000 69.html

In addition to my other comment, be sure to read Things You Should Never Do, Part I from JoelOnSoftware.

People have varying opinions on his work, but in this situation, if you can't answer his objects you should not rewrite.

Any kernel with upwards of 2.5 million lines of code is going to be incredibly buggy, perhaps it's time to rethink and go back to the microkernel

Splitting any software into external pieces is exactly the same as splitting the software into internal pieces. Microkernel is not the answer -- encapsulation is the answer.

Besides, converting the kernel will not get rid of the bugs; it will just make different ones. 2.5 million lines is a lot to rewrite, and any rewrite will lose all the bugfixes already in place.

What you're seeing is market segmentation. The companies which make the "branded" formula sell it under their brand at every possible location, and at full price, and then license it out to the people like Wal-Mart, Costco, Sam's Club, etc.. to sell as a generic, at a much lower price. Given the choice between not selling it at all at the full price to a section of the market, and selling it at a lower price, they're going to go for selling it at a lower price every time. You can read an interesting explanation of this technique in the context of software over here.

The same is true for most of the "generic" items you're going to find at these stores. If you can get over the fact that you're not buying the branded item, you can save a boatload of money while not sacrificing quality one iota.

Welcome to slashdot!

Anyway, thanks for the contribution. I can think of cases where something like this would be VERY useful. Keep up the good work, and good luck.

P.S. You might want to also post a link at http://discuss.joelonsoftware.com/?design. The people there are just a bit less rambunctious than the slashdot crowd. Who knows, you might even get some useful feedback.

There would be BSD but the concept and ideology behind Free Software may not exist -- BSD may be filed under "university science" ideology only).

Sure. Like BSD Sockets, that's Academia, not Real World (TM), right?

What buttheads don't seem to understand is the tremendous business machine behind Linux: HP, IBM, etc. And their business is selling hardware. Not really Linux. Linux is a just a cheap commodity for those firms.(http://www.joelonsoftware.com/articles/Stra tegyLetterV.html)

Here's the problem with only learning to program on top of tools other people made: When the abstractions leak, you don't know enough about what's going on under-the-hood to resolve it.

Understanding how dynamic linking works; understanding what syscalls are, which ones there are and how they operate; understanding how virtual memory is implemented at a hardware level; understanding the processor as something other than a black box -- all of these are necessary if you're going to be the dude who comes in when the high-level-only programmers have a problem they can't solve because their tools have a subtle bug or a conflict with some aspect of their environment. If you're going to be making architectural-level decisions, it also helps to know how various high-level things work -- which mechanisms different revision control systems use for representing and manipulating history; how video codecs handle seeking; and so forth. This kind of knowledge is useful so that ideas which are used in one area (say, video codecs) can be reapplied to another (say, maintaining support for fast seeking in large, mutable text buffers).

Having the versatility implicit in knowing how the low-level stuff works as well as the high-level bits makes for more variety, prestige and job security than one would otherwise have.

Should they re-write their code? Yes or No?

Reminds me of another Slashdot post that pointed out that it is really difficult to find the real productive people just by looking at that kind of indicators. A quiet person who works mostly office hours, takes a break to read the newspaper, surf the Web or play some game might seem less valuable than a glib articulate worker that stays overtime very often

However, I've seen that several of the first kind of workers actually do get their work done, are often way smarter/better qualified but have more difficulty expressing themselves and thus don't seem as good when viewed by upper management that sees a glib talker that might be clueless, and takes so much longer than the other to finish work that has to work extra hours (see joelonsoftware for some info he has on productivity related to programming in particular, which IMO can be applied to information workers in general). Also, the image which got me thinking about that recently, from a blog: http://headrush.typepad.com/creating_passionate_us ers/2006/04/when_only_the_g.html

which I originally found here: http://www.businessinnovationinsider.com/2006/04/0 9-week/
Joelonsoftware's link: http://www.joelonsoftware.com/articles/HighNotes.h tml (very general but covers the topic briefly near the end. I can't find a more specific one ATM)

Thank you for boiling the article down to its most interesting part.

I see another problem, though. Alot of software written for the Win32 platform doesn't actually run on the documented or implemented Win32 platform unless all of the "compatibility shims" or whatever they call them are present. Read the interesting article from Joel on Software.

MS and Apple have very different attitudes about backwards compatibility. MS's attitude is, "If you got it running on X platform, it's our responsibility to make sure it continues to run, regardless of the awful undocumented things you've done." This attitude is understandable, since the less the developers have to fix, the less you have to tell them about how your software actually works.

Apple's attitude is, "Yeah you got it to run in 10.2, but we deprecated a bunch of your methods in 10.3 and you'd better watch out for 10.5." This attitude is understandable since they're currently targetting two hardware platforms, and their flagship OS is really only 5 years old and is still growing into its niche; it also lessens their testing burden (which I understand is a big part of MS's budget presently).

My point is, a lot of software written for the Win32 platform over the last 10 years doesn't really run on it as specified. From the Joel on Software article:

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it [...] The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

not to be an MS fan boi here, but just stop and think for a minute. MS has literaly hundreds of versions of their OSes. All the different language versions. There are well documented examples (ctrl-f for "polish") of specific bugs for specific language versions

There's a *lot* of testing that needs done for a windows fix

Apple don't need to get people to switch to Mac OS X; they need to get them to buy Apple's computers.

Supporting Windows makes it easier for people to decide to try a Mac, because they don't have to worry about losing familiar applications like regedt32 and minesweeper. Apple hopes that they will then discover that they don't need Windows after all.

See http://www.joelonsoftware.com/articles/fog00000000 52.html for a discussion

Both Eric Sink (the founder of SourceGear) and Joel Spolsky seem to think so. (You'll have to search for the relevant articles yourself--I'm not going to dig through years worth of archives for you.)

Their thinking is:

1. If the guy in charge doesn't understand the technology, he (or she) will make bad strategy decisions. Spolsky's example is John Scully's decision to build a device that recognized handwriting (which is impossible, or at least very hard) vs. Bill Gates' asking his developers to write a reusable rich text edit control (which Microsoft ended up reusing for everything).
2. At the small company level, business stuff (aside from law and accounting, both of which can be outsourced) tends to be easy enough that a geek can learn it without too much trouble. Therefore (says Eric Sink), it's a better use of money to get technical people than business people.

On the other hand, the business guy is your friend and anyway, he's willing to talk to investors and answer the phone during the daytime (I'm assuming) so he's probably worth keeping around.

I think that what I'd do in your situation is give the business guy the job of CEO but retain a 51% ownership of the company. That lets him do the day-to-day business stuff and give the people he talks to a sense that they're talking to the guy in charge while at the same time letting you set him right if he tries to do something stupid.

Disclaimer: I have no actual experience in this. I'm just makin' stuff up.

There is a *very interesting* article on Joel on software (http://www.joelonsoftware.com/items/2005/11/18.ht ml) on how it is essential for the Record labels to be able to control the popularity of its songs:

"...Here's the dream world for the EMI Group, Sony/BMG, etc.: there are two prices for songs on iTunes, say, $2.49 and $0.99. All the new releases come out at $2.49. Some classic rock (Sweet Home Alabama) is at $2.49. Unwanted, old, crap, like, say, Brandy (You're A Fine Girl) -- the crap we only know because it was pushed on us in the 70s by paid-off disk jockeys -- would be deliberately priced at $0.99 to send a clear message that $0.99 = crap.

And now when a musician gets uppity, all the recording industry has to do is threaten to release their next single straight into the $0.99 category, which will kill it dead no matter how good it is. And suddenly the music industry has a lot more leverage over their artists in negotiations: the kind of leverage they are used to having. Their favorite kind of leverage. The "we won't promote your music if you don't let us put rootkits on your CDs" kind of leverage.

And Apple? Apple wants the signaling to come from what they promote on the front page of the iTunes Music Store. In the battle between Apple and the recording industry over who gets to manipulate what songs you buy, Apple (like movie theaters) is going to be in favor of fixed prices, while the recording industry is going to want variable prices."