1. Code level documentation. Having good code-level comments is vey important for figuring out the nuts and bolts of how things work. Well commented and well structured code can make or break a long term project. The important thing is to keep the comments up to date so that you aren't providing misleading information. This is easy to do, however. All it takes is a little dicipline.
2. Process and Design Documents. There are many ways to handle these, but one simple way to do it is to create a development "Intranet" and keep all of your developer docs in HTML format. HTML documents are easy to create, easy to organize with hyperlinks, and easy to view. Keep a copy of your HTML documents in CVS or some other version control tool. That way you can have a record of your changes.
Code level docs are pretty easy to get started. If you have a good development team, you probably already have your code well organized. If not, assign pieces of your project to different programmers and have them document their assigned code.
Design and Process docs can be handled the same way. Make a list of things that you need to document (ex: build instructions, class hierarchies, etc) and assign these out to programmers.
The key to any documentation system is to keep things up to date. The best protocol is to have people make changes to the docs as they change the system, or as they discover bugs in the docs. Treat your docs just like you would source code. Strive for "bug free" docs. If you can't make a change to a document for whatever reason, log it as a bug so the change doesn't fall through the cracks.
Once people get used to treating docs as code, they will keep them up to date. If people have the attitude of "I'll document it when I have the chance" your system is doomed to fail.
I also am a small time HP stockholder and I was amazed at the amount of money both sides put into campaigning. I must have gotten dozens of letters, proxies (white and green), and phone calls about the merger. It sickens me that the company would spend its revenue (i.e. my dividend dollars) campaigning so that a few execs can get big bonuses. That is one of the reasons why I voted against it.
It doesn't seem smart to me that the company should want to get into the low-margin business of commodity PC's. Besides, Compaq and HP have such a poor track record with mergers (i.e. DEC and what they did to the Alpha chip) that I am very skeptical that this one will work.
I think it may be time to get out of HP (if it isn't too late already).
I've read a lot of the comments on here, and I think that many of you are missing the point of his argument that rewriting is bad. If you re-read the article and if you read his original rant about rewriting code on his web site, you will see that he doesn't say that you should never rewrite code. He is saying that if you choose to rewrite code, you better have a sound business case for rewriting the code.
I think his position stems from the fact that we coders out there love to rewrite things on a whim. Often times we as coders like to work with pristine code, and we find ugly code offensive (even if the ugly code works). However, his take is that unless you can show that the cost of rewriting outweighs the benefit, you should leave the code alone.
In most cases when you have a piece of working code that does the job, the cost of rewriting it from scratch is very VERY high (higher than we coders think). Therefore, you should think long and hard before going down that path.
At the first company I worked at out of school (a large financial institution), I had the misfortune of working on a large, monolithic FORTRAN app. This app was one of the worst messes I have ever seen. It was originally written by a financial guru who knew just enough about programming to be dangerous. In time, many programmers had come and gone and added their own bug fixes and feature to the code. By the time I had gotten to it, it was a bear to make changes to. My first thought was that this app should be rewriting from the ground up. In fact, I started working on a project to replace the app. After a few weeks I came to the realization that rewriting the app was a waste of time.
The fact is that old FORTRAN app worked! To create an new app that would completely mimic the old thing would take many, many man-years. Sure modifications to the old app were a pain. However, it took less time to make the modifications to the old app than it would take for me to rewrite the whole thing.
In the end I put aside my snobbish attitude and learned a little FORTRAN!
No offense, but it doesn't sound like you know what refactoring is. Refactoring, as defined in the book by Fowler of the same name, has little to do with redesigning. Refactoring involves restructing code without breaking it. Usually this involves incremental changes to the code, and running unit tests in between each change to ensure that the code doesn't break. I would argue that refactoring is a much lower-level activity than redesigning.
Here is an interesting tidbit that I gleaned from the article. In the first anti-trust investigation of Microsoft (circa 1995), the original judge disapproved the weak settlement that had been reached between Microsoft and the DoJ. However, the appeals court removed the original judge and replaced him with none other than Judge Thomas Penfield Jackson!
From the article:
"The following June, a federal appeals court ruled that Judge Sporkin had overstepped his authority and assigned the case to a different judge, Thomas Penfield Jackson, who had a freshly inked rubber stamp."
It is ironic that in the second anti-trust trial, it was this same Judge Jackson who was removed from the case on appeal.
Read the article... he sent it CERTIFIED mail, not registered mail. In any case, you have to pay for a "Return Receipt" in order to get proof of delivery.
As far as your point about it "legally" considered mail goes: my understanding is that you aren't "legally" served until you receive the summons.
I am not surprised that Baltimore is mentioned in the article. I lived there for three years and it was definitely a great city to live in. It is big enough so that there are things to do (culture, food, night life, sports, shopping), but it doesn't have the problems that a lot of big cities have. The cost of living is very low (especially compared to Philly and DC), and it hasn't been overdeveloped so there's still isn't the same amount of traffic and crowding as in other big cities.
As far as high tech goes, there are a surprising number of software and tech companies in the Baltimore region. If you don't mind commuting to the DC area (45 mins south) there are even more jobs.
Of course, don't forget the crab cakes!!
PS: I had to move away because my better half got an academic position in another city. Otherwise, we would have stayed there.
I am not a manager, but I have worked for a few of them in my time. From what I can tell, there are two separate tasks that any manager must perform.
First, they must handle all of the administrative/business stuff. This means doing things like schedules, purchasing, calculating ROI, budgets, etc. From talking to people that have gotten their MBA's, this is the sort of thing that they learn about in their "management" classes. Most managers that have gone through some sort of formal management training seem to have this part of the job down pat.
The second aspect of managing is motivating and leading the people who work for you. This doesn't seem to be taught in any sort of formal way (note that MBA stands for Masters of Business ADMINISTRATION, not Business Leadership). It seems that most managers fail at this aspect of the job, and failing seems to be at the heart of most complaints that we technical people have about our managers. Most of the complaints on this topic are the result of managers who either don't know how to motivate their techies, or who do things that actually DE-motivate their techies. Apparently, this is a subject that isn't taught in those management classes.
Steven McConnell's book _Rapid Development_ devotes several chapters to the subject of motivating developers. He makes the case that developer motivation is the number one most important factor in determining whether or not a project succeeds. He then goes on to discuss ways in which developers can be motivated, and ways in which they can be de-motivated.
One of the the more interesting things that he mentions is that surveys have shown that managers and developers are motivated by different things. He suggests that this may be one of the reasons why there is often a disconnected between managers and developers. For example, while managers are often motivated by "rah-rah" speeches, technical people are put off by these sorts of things because they seem phony. On the other hand, developers are often motivated by working on interesting projects where there is the possibility for growth, while managers are less concerned with this sort of thing. The trick is to motivating developers is understand what motivates them, and then to deliver.
Also, he mentions that developers are often motivated by the work itself, meaning they want to feel "good" about the work that they are doing. Developers derive a lot of satisfaction from a job well done. However, managers often undermine this by demanding that developers cut corners, that they do not get to use the latest tools and techniques, that they do not have any control over the techical decisions, etc. There is nothing more de-motivating than when you do not feel good about the work that you are doing. Nobody ever felt a sense of accomplishment over a mass of spaghetti code that was thrown out the door.
Anyway, if you are looking for a good read about motivating developers and technical management in general, I suggest you read _Rapid Development_. In my opinion, it should be required reading for all technical managers!
In college I majored in EE with a concentration in Computer Engineering. Although I knew I wanted a career doing computer science/programming, I decided NOT to major in straight CS. I had been programming since a fairly young age, and so by the end of high school, I considered myself to be a fairly knowledgable programmer (whether or not that was true is a subject for debate, but it is hard to convince an 18 year old the error of his ways!). I figured that by majoring in EE/CE I would be broadening my horizons because the main focus of this major is computer hardware design. I figured that learning the hardware of a computer system would best compliment the knowledge I already.
During my undergraduate program, I ended up taking the usual array of engineering core courses, EE courses, and the like. I also took a number of CS courses as technical electives. Although the lower level CS courses (intro and sophomore level courses) were somewhat of a waste, the ones I took beyond that were very helpful. In the end, I realized that there WAS a lot about programming that I needed to learn, and I ended up completing a Masters in CS after my BSEE.
Getting back to the original question, personally I thought that doing the BSEE and MSCS was the best choice FOR ME. Because my interests lie in programming and technical things, this course of study was definitely the way to go. Also, although I like to think that I could be a good technical manager, the fact is that I really don't have any interest in being one.
As far as the other degrees go (MIS, CIS), I don't have personally experience with these. From what I can gather, the MIS degree is focused a lot more on technical project management and business-related computer applications. The content is a lot less technical than what you'd find in a CS degree. I'm not saying that that's bad or anything; it's just different. In general, the feeling that I get is that because the MIS degree is less "hardcore", it is easier. For a pure technical position, a CS degree is probably a better preparation. For a project management type position, a MIS degree is probably a better preparation.
However, let me just say that in my opinion it is a LOT easier to take a CS person and turn them into a manager than it is to take an MIS person and turn them into a technical contributor. You can teach management skills on the job through experience and mentoring, but it is much harder to teach technical skills on the job unless the individual already has a good technical foundation.
I am surprised that Road Runner isn't supporting Windows XP at this time. Obviously, they aren't the only ones - this seems to be commonplace. However, this doesn't make it any less surprising.
Consider these facts:
- Everybody, including RR, knew that Windows XP was going to launch this week. It wasn't like this was a surprise to anyone.
- The Beta and RC versions of Windows XP have been available for months. Certainly they could have been testing it out and developing support scripts for it.
- There are going to be a lot of people moving to Windows XP. With new PC shipping with it pre-installed, and with the big XP marketing push, they are probably going to be flooded with questions about XP support. I imagine that they will scare a lot of non-tech users away from using their service with blanket statements like "we don't support XP". The non-tech uses are going to be driven to some other ISP.
- As others have pointed out, offering XP support is probably not that difficult. It's probably a matter of figuring out what icons to click and what buttons to push. Certainly some bright tech should be able to write up a support document in a couple hours (if that).
I can at least understand dragging their heels on Windows 2000 support to some extent. After all, the average home user isn't going to get a PC with it pre-installed. However, given that XP is supposed to be the consumer Windows operating system, not offering support for it seems like dumb from a PR standpoint.
Re:Come see the violence inherent in the System!
on
Globalization
·
· Score: 1
As for the Middle East, look at what they're getting. They see the worst of globalism - Coca-Cola and Britney Spears - while getting nothing of the best of it, like freedom of speech and a growing economy. And we're crushing the strong and beautiful tribe of Arab and Islamic culture. No wonder they are fighting back! However, i don't think the medievalists like bin Laden can win in the long run, either, because they don't offer anything BUT tribalism.
The problem with your argument is that nobody is forcing people around the world to embrace American culture. People are embracing this culture because they want to. Nobody is forcing people to drink Coke, eat at McDonalds, or hang out at a Starbucks. The question you have to ask is why are they embracing American culture. My theory is because America represents freedom & prosperity & leisure, and by buying American products, perhaps somehow they can live the "American dream" in a small way...
Or perhaps it is just that they actually like American products on their own merits!
Some cultures are threatened by the encroachment of this global culture on their way of life. They fight this either by closing ranks and keeping their people from coming in contact with it (ex: pre-industrial China, Taliban, Soviet Russia), or they fight it by letting their people choose for themselves what they want to embrace and hoping they make the "right" choice.
There's a key... globalist culture provides huge economic incentives to participation, but you pay with your soul. It's great to have a Starbuck's everywhere so you can always get good coffee, but it sucks that Starbuck's is putting the funky individualistic cafes out of business. T-shirts are wiping out tribal dress because they're cheaper (unless you're a geek like me, where the t-shirt and its logo IS your tribal dress. I'm wearing a Klingon Kultural Ekchange shirt under my business casual).
This kind of reminds me of the _South Park_ episode where the town rallies around the local coffee shop to try and prevent the out-of-town chain coffee shop from opening a store. In the end, the local shop goes out of business because (gasp!) the out-of-town coffee shop has BETTER COFFEE!
I kind of feel the same way when it comes to my "consuming preferences". I give my business to the shop that best satisfies my needs. If it is a local place, so be it. If it is an out-of-town place, that doesn't bother me.
Actually, I live in a rural college town where there are a lot of "pressure" to support local businesses. While I have sympathy for their cause, the fact of the matter is that many of the local business could use a little competition. Many of them charge high prices, have terrible selection, and have inconvienent hours.
Recently, I tried going to the local hardware store to pick up a few things, and much to my surprise, they were closed! It turns out they close at 6pm on weekdays. I ended up driving 30 minutes to a national hardware chain store to get what I needed. The same local hardware store is fighting to keep the national chain from expanding into our town! Needless to say I have very little sympathy for the local store.
At the end of the day, it's about selling a product or service that the customer wants. It seems that some local business have forgotten this little lesson. Maybe a little competition will help them to remember...
Actually, there are a lot of reasons why exceptions are better than return values:
Checking return codes often leads to messy code filed with lots of conditional statements, while handling exceptions allows you to separate your error code from the logic of your program.
With return codes, you are forced to handle the error in the routine that called the function. With exceptions, you have the option of handling the error locally or allowing the error to propogate up the call stack to the appropriate place. Again, this helps to organize your error handling better.
With judicious naming of your exceptions, you centralize error handling for different classes of errors in one place. With return codes, it is more difficult to do this.
In short, exceptions allows you to better organize your error handling. On small programs, exceptions may seem like "overkill", but for large projects they yield big dividends.
Of course, exceptions can be misused and abused just like any other language construct, but in the hands of an experienced developer, they are vastly superior to return codes.
Commercial Developers are just as bad. If you ever see an "Access Violation" or "Unhandled Exception in blah...", chances are, the programmer didn't do proper error handling or checking for error conditions.
Shouldn't OS developers aspire to be better than that? Just because some commercial app has cryptic error messages doesn't mean that it's okay.
Think of all the medical and financial information that insurance companies have about the people that they insure. People should be more worried that somebody is going to hack into Prudential's database. Frankly, my medical records are a lot more private to me than the books that I buy online.
It's amazing that some people will bitch about Microsoft when they are small potatoes compared to the other organizations out there. But then again, Microsoft is the evil empire...
If you find a NEW bug in an MS product then you get the call for free (they actually re-credit your call count, I think). If you call about an existing bug, one that someone else located your paying for the call, like it or not.
This hasn't been my experience, but perhaps the support techs I've dealt with were feeling generous!
"and I've never heard of a case where a product was intentionally shipped with bugs"
Software is always delivered with bugs. Just because the testers didn't find them, does not mean they are not there. We often sent out systems riddled with bugs, accompanied by a huge rap sheet of listed, but unfixed bugs. A found bug is still a bug, it still gets delivered if found too late.
I know what you mean. I was talking about the situation posed in the article where a software company intentionally introduced bugs in order to make money off of support contracts and upgrades.
I don't think Fred Brooks ever said anything was a Silver Bullet, he pre-dates the concept of Silver Bullets, and is a little too sensible to fall for that one.
I reread my original post and I think I might not have been clear with that sentence. I was referring to Fred Brooks' assertion that there was no such think as a silver bullet to fix the problems associated with large scale software development. It seems that the original article is holding up the Open Source paradigm as some sort of magical thing that will eliminate all bugs in software. From what I can tell working with various open source products, open source is not immune to bugs as the original author suggests. I hope that clarifies things.
I can sympathize with your plight. I have been in your shoes. I have been bitten by bugs in software that I have purchased. However, in my experience, there isn't some grand conspiracy to introduce bugs into software to force you to upgrade. Like it or not, bugs are a fact of life in all software products. Most companies realize this, and they try their hardest to fix issues with patches and service packs that they provide free of charge.
I can't speak specifically about your issue with NT, but I know that there are bug listings in the MS Knowledge Base that are "known issues" that aren't fixed. However, looking at it from the software company's point of view, they have a finite amount of time and resources to dedicate to fixing bugs. Somebody has to decide which bugs should get fixed and which ones shouldn't. Sure it would be great if Service Pack N+1 fixed all known issues, but to do that, they might have to push back the release of the Service Pack, and until they release the service pack NO bugs get fixed.
Also, I have had a number of cases where I've gotten a "hot fix" (a fix to a specific problem that isn't in any service pack). This depends on the severity of the problem.
You do have to give credit where credit is due though. They DO release service packs free of charge. They DO tell you where they may be unresolved issues and what the workarounds are (they could just as easily deny that the bugs exist). I understand that Microsoft is buggy, but all software is buggy and they do make an effort to correct problems.
Also, my experience with Microsoft support has been that you don't get charged if it's "their fault". Sometimes you have to be adamant about this with some of the support techs, but most won't give you a hard time about it.
I agree with you that open source software makes it easier to find and fix bugs if you have the expertise available to do it. I was taking issue with the original article's assertion that by switching to open source software that you will automatically be getting "bug free" software. You won't. Even open source software is going to have bugs in it.
Getting back to my main point.... I don't think that there is this big conspiracy to release buggy software just to bill people for support. Software is going to have bugs; that is just the nature of the beast.
This article obviously was written by somebody who doesn't have a clue about IT.
First of all, there is no conspiracy among software companies to intentionally ship buggy code with the intention of making money off support/upgrades. I have worked for a number of "shrink-wrap" software companies & I know people who have worked for others, and I've never heard of a case where a product was intentionally shipped with bugs. Obviously, bugs exist in software. Software is a complex thing, and it is very difficult (if not impossible) to test every single possible usage. Anyone who took an elementary course in software engineering knows this.
It is corporate suicide for a company to release buggy products and then ask you to pay to fix these bugs. Most companies (including the evil empire) bend over backwards to resolve issues, deliver timely service packs and patches, without charging a dime for their time. If you call Microsoft's support line and your issue is related to a bug, you don't get charged for the service call. I guarantee you that they are losing money on this, not making money. Anytime anyone tries to use a "conspiracy theory" to explain something, it is usually total bull droppings.
Also, to suggest that the subscription model is the way to keep software companies honest is also complete nonsense. The thing that the article is missing is the fact that once you start using a particular piece of software, it is hard to switch to another piece. This is called "lock-in" and I'm surprised a magazine aimed at executives didn't mention this once. You can threaten to cancel your subscription all you want, but if the vendor knows that it will cost you X million dollars to switch over to another product, you lose all of your leverage. It doesn't matter if you pay for your crack in one lump sum or if you pay for your crack on a monthly basis; you are still addicted to the crack.
Finally, to tout open source as the solution to these CIOs' problems is garbage. The pieces of software mentioned in the article are big time accounting packages. There is no open source equivalent for these things. Even for things where there is an OSS equivalent (web server, database), just because it is open source doesn't mean that all the bugs are going to go away. All software, whether it's open or close source is going to have bugs. To suggest that open source is the "silver bullet" of software development a la Fred Brooks is silly.
It is scary to me that CIO actually are going to read this drivel.
Let's say this bill is turned into law, and let's say the FBI uses the new rules to help capture and prosecute some members of bin Laden's group. What will happen if the Supreme Court decides that these rules are unconstitutional? In the worst case, the terrorists would go free because the evidence against them is thrown out.
It would seem to be that if Congress, in its haste, creates new unconstitutional laws, it could end up sabotaging the efforts to bring these terrorists to justice. Congress would sure look foolish if bin Laden was able to walk out of court a free man because of some technicality.
I went to this conference two years ago, and I thought it was excellent. It is sponsored by a magazine publisher, I believe, so it is pretty much technology and company agnostic. Also, there were a lot of in-depth technical sessions (the one I went to suggested that participants bring laptops with compilers), so it was a lot more than just a sales pitch type of thing. You actually got some good technical know-how from it.
I believe there is also a SD conference on the West Coast (SD West?), so that may be more geographically convienent. From what I understand, it is basically the same conference.
There are a number of big hurdle that the Net still needs to overcome before it complete with TV, Radio, and Newspapers.
As others have already pointed out some other shortcomings (low signal-to-noise ratio, major sites can't handle the traffic) I won't repeat those arguments. I would like to point out another shortcoming in that many of the news sites out there simply repeat the same stories almost verbatim from AP, Reuters, NY Times, CNN, and other major news organizations. On Sept 11, most of what I saw on IRC, Slashdot, etc was simply rehashing of what was being reported on TV. Instead of being a source for new and novel information, it was simply an alternative distribution medium for the same information that was being presenting by "primary" news sources. Until there is a major web-only news site that hires its own reports and develops its own content, the Net will be dependent upon the "old world" new organizations for its content.
Another shortcoming of the Net is it's transitory nature. The Net doesn't have the permanence of print or even broadcast news. When the NY Times prints an article, it is out there for all times. News on the web, on the other hand, comes and goes as new pages are added and old ones are retired. There is a reason why the NY Times is often called the "newspaper of record". Until the Net gains the ability to archive a snapshort of its content and retrieve it, it won't have the same utility as other media.
A lot of what Katz talks about it is how the Net isn't acting as a news source, but as a community where people can share their views and opinions. This is great, but the opinion of Joe Blow from Iowa isn't what I would call news in the sense that the NY Times is news.
I think people like Katz have a tendency to hype up the Net to the point of ridiculousness, like it is the be-all-and-end-all of life. Yes, it is a new and wonderful invention, and yes it does add some new dimensions to human interaction, but does it change the fundamental rules of nature somehow? I find that hard to believe.
First off, the purpose of a school isn't to be pseudo-companies. The purpose of a school is to teach. Schools need to ask themselves if group projects achieve this goal. In most cases, I think the answer is a resounding no.
In classes that teach basic programming and other CS concepts, I think students are much better off writing their own programs and doing their own work. How else are they going to learn these basic skills?
There are classes where group projects may be appropriate if done right. The classes I'm thinking of are software engineering type classes where much of the subject matter centers around being able to organize projects into modules, code the modules, and integrate these modules together.
However, if a class is going to teach teamwork, it's actually got to teach it. Professors can't just divide up the class in to groups of N, give them a project that is N times a normal, single-person project, and let them go. As others have pointed out, that is a recipe for disaster!
They actually have to instruct them in how to go about dividing up the work, designing interfaces between modules, integrating code, using source control to track changes, etc. Otherwise, they aren't really learning how to program as part of a team.
Seems the only meaning they had ever leared for the term "solder" was that was the name of the hot iron to melt the wires together with. I sure would have loved to see what their disserations were about... I always like good humor.
I was an EE major in college, and I never had to touch a soldering iron during my 4 undergraduate years. All of our projects were either done using a breadboard, a wirewrap board, or using a computer simulator.
This is something that I've been thinking about for a long time.
It seems to me that one reason why all of these techno-stupid laws get passed is because the people who represent us don't know a darn thing about computers and technology. If there were a few engineers/computer scientists in Congress, the odds of these things getting passed and signed into law would decrease.
A friend of mine is a veterinarian, and she tells me that there are a couple of Vets who are in the House and Senate, and they have a lot of influence when it comes to laws relating to animal welfare and biology in general. When a bill comes before Congress that has to do with their area of expertise, there view carries a lot of weight among their collegues.
Also, groups that lobby on behalf of Vets (the American Veterinary Medical Association, for instance) has automatic allies in Congress because of their professional affiliation. If something concerns Vets, you can be sure that these politicians will know about it, and will be doing something about it.
I think it would be great of the tech establishment has somebody who could do that for us. Perhaps one of those dot com millionaires would be willing to put up some of their riches (a la Ross Perot) to make a run for Congress. There are enough rich geeks out there that we can't use lack of money from fundraisers as an excuse.
To take the point even further, I think it would be great if Congress represented the true cross-section of professions, and not just lawyers career politicos. Of course, that's just a pipe dream...
Slashdot Mirror
1. Code level documentation. Having good code-level comments is vey important for figuring out the nuts and bolts of how things work. Well commented and well structured code can make or break a long term project. The important thing is to keep the comments up to date so that you aren't providing misleading information. This is easy to do, however. All it takes is a little dicipline.
2. Process and Design Documents. There are many ways to handle these, but one simple way to do it is to create a development "Intranet" and keep all of your developer docs in HTML format. HTML documents are easy to create, easy to organize with hyperlinks, and easy to view. Keep a copy of your HTML documents in CVS or some other version control tool. That way you can have a record of your changes.
Code level docs are pretty easy to get started. If you have a good development team, you probably already have your code well organized. If not, assign pieces of your project to different programmers and have them document their assigned code.
Design and Process docs can be handled the same way. Make a list of things that you need to document (ex: build instructions, class hierarchies, etc) and assign these out to programmers.
The key to any documentation system is to keep things up to date. The best protocol is to have people make changes to the docs as they change the system, or as they discover bugs in the docs. Treat your docs just like you would source code. Strive for "bug free" docs. If you can't make a change to a document for whatever reason, log it as a bug so the change doesn't fall through the cracks.
Once people get used to treating docs as code, they will keep them up to date. If people have the attitude of "I'll document it when I have the chance" your system is doomed to fail.
Good luck!
It doesn't seem smart to me that the company should want to get into the low-margin business of commodity PC's. Besides, Compaq and HP have such a poor track record with mergers (i.e. DEC and what they did to the Alpha chip) that I am very skeptical that this one will work.
I think it may be time to get out of HP (if it isn't too late already).
rewriting from the ground up != refactoring a function
[Ooops... I see that your post is modded as Flamebait. You win :-)]
I think his position stems from the fact that we coders out there love to rewrite things on a whim. Often times we as coders like to work with pristine code, and we find ugly code offensive (even if the ugly code works). However, his take is that unless you can show that the cost of rewriting outweighs the benefit, you should leave the code alone.
In most cases when you have a piece of working code that does the job, the cost of rewriting it from scratch is very VERY high (higher than we coders think). Therefore, you should think long and hard before going down that path.
At the first company I worked at out of school (a large financial institution), I had the misfortune of working on a large, monolithic FORTRAN app. This app was one of the worst messes I have ever seen. It was originally written by a financial guru who knew just enough about programming to be dangerous. In time, many programmers had come and gone and added their own bug fixes and feature to the code. By the time I had gotten to it, it was a bear to make changes to. My first thought was that this app should be rewriting from the ground up. In fact, I started working on a project to replace the app. After a few weeks I came to the realization that rewriting the app was a waste of time.
The fact is that old FORTRAN app worked! To create an new app that would completely mimic the old thing would take many, many man-years. Sure modifications to the old app were a pain. However, it took less time to make the modifications to the old app than it would take for me to rewrite the whole thing.
In the end I put aside my snobbish attitude and learned a little FORTRAN!
Visit the refactoring web site if you want to learn more about what refactoring is (and isn't).
Here is an interesting tidbit that I gleaned from the article. In the first anti-trust investigation of Microsoft (circa 1995), the original judge disapproved the weak settlement that had been reached between Microsoft and the DoJ. However, the appeals court removed the original judge and replaced him with none other than Judge Thomas Penfield Jackson!
From the article:
"The following June, a federal appeals court ruled that Judge Sporkin had overstepped his authority and assigned the case to a different judge, Thomas Penfield Jackson, who had a freshly inked rubber stamp."
It is ironic that in the second anti-trust trial, it was this same Judge Jackson who was removed from the case on appeal.
Read the article... he sent it CERTIFIED mail, not registered mail. In any case, you have to pay for a "Return Receipt" in order to get proof of delivery.
As far as your point about it "legally" considered mail goes: my understanding is that you aren't "legally" served until you receive the summons.
I am not surprised that Baltimore is mentioned in the article. I lived there for three years and it was definitely a great city to live in. It is big enough so that there are things to do (culture, food, night life, sports, shopping), but it doesn't have the problems that a lot of big cities have. The cost of living is very low (especially compared to Philly and DC), and it hasn't been overdeveloped so there's still isn't the same amount of traffic and crowding as in other big cities.
As far as high tech goes, there are a surprising number of software and tech companies in the Baltimore region. If you don't mind commuting to the DC area (45 mins south) there are even more jobs.
Of course, don't forget the crab cakes!!
PS: I had to move away because my better half got an academic position in another city. Otherwise, we would have stayed there.
I am not a manager, but I have worked for a few of them in my time. From what I can tell, there are two separate tasks that any manager must perform.
First, they must handle all of the administrative/business stuff. This means doing things like schedules, purchasing, calculating ROI, budgets, etc. From talking to people that have gotten their MBA's, this is the sort of thing that they learn about in their "management" classes. Most managers that have gone through some sort of formal management training seem to have this part of the job down pat.
The second aspect of managing is motivating and leading the people who work for you. This doesn't seem to be taught in any sort of formal way (note that MBA stands for Masters of Business ADMINISTRATION, not Business Leadership). It seems that most managers fail at this aspect of the job, and failing seems to be at the heart of most complaints that we technical people have about our managers. Most of the complaints on this topic are the result of managers who either don't know how to motivate their techies, or who do things that actually DE-motivate their techies.
Apparently, this is a subject that isn't taught in those management classes.
Steven McConnell's book _Rapid Development_ devotes several chapters to the subject of motivating developers. He makes the case that developer motivation is the number one most important factor in determining whether or not a project succeeds. He then goes on to discuss ways in which developers can be motivated, and ways in which they can be de-motivated.
One of the the more interesting things that he mentions is that surveys have shown that managers and developers are motivated by different things. He suggests that this may be one of the reasons why there is often a disconnected between managers and developers. For example, while managers are often motivated by "rah-rah" speeches, technical people are put off by these sorts of things because they seem phony. On the other hand, developers are often motivated by working on interesting projects where there is the possibility for growth, while managers are less concerned with this sort of thing. The trick is to motivating developers is understand what motivates them, and then to deliver.
Also, he mentions that developers are often motivated by the work itself, meaning they want to feel "good" about the work that they are doing. Developers derive a lot of satisfaction from a job well done. However, managers often undermine this by demanding that developers cut corners, that they do not get to use the latest tools and techniques, that they do not have any control over the techical decisions, etc. There is nothing more de-motivating than when you do not feel good about the work that you are doing. Nobody ever felt a sense of accomplishment over a mass of spaghetti code that was thrown out the door.
Anyway, if you are looking for a good read about motivating developers and technical management in general, I suggest you read _Rapid Development_. In my opinion, it should be required reading for all technical managers!
Here is my two cents to throw into the mix:
In college I majored in EE with a concentration in Computer Engineering. Although I knew I wanted a career doing computer science/programming, I decided NOT to major in straight CS. I had been programming since a fairly young age, and so by the end of high school, I considered myself to be a fairly knowledgable programmer (whether or not that was true is a subject for debate, but it is hard to convince an 18 year old the error of his ways!). I figured that by majoring in EE/CE I would be broadening my horizons because the main focus of this major is computer hardware design. I figured that learning the hardware of a computer system would best compliment the knowledge I already.
During my undergraduate program, I ended up taking the usual array of engineering core courses, EE courses, and the like. I also took a number of CS courses as technical electives. Although the lower level CS courses (intro and sophomore level courses) were somewhat of a waste, the ones I took beyond that were very helpful. In the end, I realized that there WAS a lot about programming that I needed to learn, and I ended up completing a Masters in CS after my BSEE.
Getting back to the original question, personally I thought that doing the BSEE and MSCS was the best choice FOR ME. Because my interests lie in programming and technical things, this course of study was definitely the way to go. Also, although I like to think that I could be a good technical manager, the fact is that I really don't have any interest in being one.
As far as the other degrees go (MIS, CIS), I don't have personally experience with these. From what I can gather, the MIS degree is focused a lot more on technical project management and business-related computer applications. The content is a lot less technical than what you'd find in a CS degree. I'm not saying that that's bad or anything; it's just different. In general, the feeling that I get is that because the MIS degree is less "hardcore", it is easier. For a pure technical position, a CS degree is probably a better preparation. For a project management type position, a MIS degree is probably a better preparation.
However, let me just say that in my opinion it is a LOT easier to take a CS person and turn them into a manager than it is to take an MIS person and turn them into a technical contributor. You can teach management skills on the job through experience and mentoring, but it is much harder to teach technical skills on the job unless the individual already has a good technical foundation.
Consider these facts:
- Everybody, including RR, knew that Windows XP was going to launch this week. It wasn't like this was a surprise to anyone.
- The Beta and RC versions of Windows XP have been available for months. Certainly they could have been testing it out and developing support scripts for it.
- There are going to be a lot of people moving to Windows XP. With new PC shipping with it pre-installed, and with the big XP marketing push, they are probably going to be flooded with questions about XP support. I imagine that they will scare a lot of non-tech users away from using their service with blanket statements like "we don't support XP". The non-tech uses are going to be driven to some other ISP.
- As others have pointed out, offering XP support is probably not that difficult. It's probably a matter of figuring out what icons to click and what buttons to push. Certainly some bright tech should be able to write up a support document in a couple hours (if that).
I can at least understand dragging their heels on Windows 2000 support to some extent. After all, the average home user isn't going to get a PC with it pre-installed. However, given that XP is supposed to be the consumer Windows operating system, not offering support for it seems like dumb from a PR standpoint.
The problem with your argument is that nobody is forcing people around the world to embrace American culture. People are embracing this culture because they want to. Nobody is forcing people to drink Coke, eat at McDonalds, or hang out at a Starbucks. The question you have to ask is why are they embracing American culture. My theory is because America represents freedom & prosperity & leisure, and by buying American products, perhaps somehow they can live the "American dream" in a small way...
Or perhaps it is just that they actually like American products on their own merits!
Some cultures are threatened by the encroachment of this global culture on their way of life. They fight this either by closing ranks and keeping their people from coming in contact with it (ex: pre-industrial China, Taliban, Soviet Russia), or they fight it by letting their people choose for themselves what they want to embrace and hoping they make the "right" choice.
There's a key... globalist culture provides huge economic incentives to participation, but you pay with your soul. It's great to have a Starbuck's everywhere so you can always get good coffee, but it sucks that Starbuck's is putting the funky individualistic cafes out of business. T-shirts are wiping out tribal dress because they're cheaper (unless you're a geek like me, where the t-shirt and its logo IS your tribal dress. I'm wearing a Klingon Kultural Ekchange shirt under my business casual).
This kind of reminds me of the _South Park_ episode where the town rallies around the local coffee shop to try and prevent the out-of-town chain coffee shop from opening a store. In the end, the local shop goes out of business because (gasp!) the out-of-town coffee shop has BETTER COFFEE!
I kind of feel the same way when it comes to my "consuming preferences". I give my business to the shop that best satisfies my needs. If it is a local place, so be it. If it is an out-of-town place, that doesn't bother me.
Actually, I live in a rural college town where there are a lot of "pressure" to support local businesses. While I have sympathy for their cause, the fact of the matter is that many of the local business could use a little competition. Many of them charge high prices, have terrible selection, and have inconvienent hours.
Recently, I tried going to the local hardware store to pick up a few things, and much to my surprise, they were closed! It turns out they close at 6pm on weekdays. I ended up driving 30 minutes to a national hardware chain store to get what I needed. The same local hardware store is fighting to keep the national chain from expanding into our town! Needless to say I have very little sympathy for the local store.
At the end of the day, it's about selling a product or service that the customer wants. It seems that some local business have forgotten this little lesson. Maybe a little competition will help them to remember...
Checking return codes often leads to messy code filed with lots of conditional statements, while handling exceptions allows you to separate your error code from the logic of your program.
With return codes, you are forced to handle the error in the routine that called the function. With exceptions, you have the option of handling the error locally or allowing the error to propogate up the call stack to the appropriate place. Again, this helps to organize your error handling better.
With judicious naming of your exceptions, you centralize error handling for different classes of errors in one place. With return codes, it is more difficult to do this.
In short, exceptions allows you to better organize your error handling. On small programs, exceptions may seem like "overkill", but for large projects they yield big dividends.
Of course, exceptions can be misused and abused just like any other language construct, but in the hands of an experienced developer, they are vastly superior to return codes.
Shouldn't OS developers aspire to be better than that? Just because some commercial app has cryptic error messages doesn't mean that it's okay.
Think of all the medical and financial information that insurance companies have about the people that they insure. People should be more worried that somebody is going to hack into Prudential's database. Frankly, my medical records are a lot more private to me than the books that I buy online.
It's amazing that some people will bitch about Microsoft when they are small potatoes compared to the other organizations out there. But then again, Microsoft is the evil empire...
This hasn't been my experience, but perhaps the support techs I've dealt with were feeling generous!
"and I've never heard of a case where a product was intentionally shipped with bugs"
Software is always delivered with bugs. Just because the testers didn't find them, does not mean they are not there. We often sent out systems riddled with bugs, accompanied by a huge rap sheet of listed, but unfixed bugs. A found bug is still a bug, it still gets delivered if found too late.
I know what you mean. I was talking about the situation posed in the article where a software company intentionally introduced bugs in order to make money off of support contracts and upgrades.
I don't think Fred Brooks ever said anything was a Silver Bullet, he pre-dates the concept of Silver Bullets, and is a little too sensible to fall for that one.
I reread my original post and I think I might not have been clear with that sentence. I was referring to Fred Brooks' assertion that there was no such think as a silver bullet to fix the problems associated with large scale software development. It seems that the original article is holding up the Open Source paradigm as some sort of magical thing that will eliminate all bugs in software. From what I can tell working with various open source products, open source is not immune to bugs as the original author suggests. I hope that clarifies things.
I can't speak specifically about your issue with NT, but I know that there are bug listings in the MS Knowledge Base that are "known issues" that aren't fixed. However, looking at it from the software company's point of view, they have a finite amount of time and resources to dedicate to fixing bugs. Somebody has to decide which bugs should get fixed and which ones shouldn't. Sure it would be great if Service Pack N+1 fixed all known issues, but to do that, they might have to push back the release of the Service Pack, and until they release the service pack NO bugs get fixed.
Also, I have had a number of cases where I've gotten a "hot fix" (a fix to a specific problem that isn't in any service pack). This depends on the severity of the problem.
You do have to give credit where credit is due though. They DO release service packs free of charge. They DO tell you where they may be unresolved issues and what the workarounds are (they could just as easily deny that the bugs exist). I understand that Microsoft is buggy, but all software is buggy and they do make an effort to correct problems.
Also, my experience with Microsoft support has been that you don't get charged if it's "their fault". Sometimes you have to be adamant about this with some of the support techs, but most won't give you a hard time about it.
I agree with you that open source software makes it easier to find and fix bugs if you have the expertise available to do it. I was taking issue with the original article's assertion that by switching to open source software that you will automatically be getting "bug free" software. You won't. Even open source software is going to have bugs in it.
Getting back to my main point.... I don't think that there is this big conspiracy to release buggy software just to bill people for support. Software is going to have bugs; that is just the nature of the beast.
First of all, there is no conspiracy among software companies to intentionally ship buggy code with the intention of making money off support/upgrades. I have worked for a number of "shrink-wrap" software companies & I know people who have worked for others, and I've never heard of a case where a product was intentionally shipped with bugs. Obviously, bugs exist in software. Software is a complex thing, and it is very difficult (if not impossible) to test every single possible usage. Anyone who took an elementary course in software engineering knows this.
It is corporate suicide for a company to release buggy products and then ask you to pay to fix these bugs. Most companies (including the evil empire) bend over backwards to resolve issues, deliver timely service packs and patches, without charging a dime for their time. If you call Microsoft's support line and your issue is related to a bug, you don't get charged for the service call. I guarantee you that they are losing money on this, not making money. Anytime anyone tries to use a "conspiracy theory" to explain something, it is usually total bull droppings.
Also, to suggest that the subscription model is the way to keep software companies honest is also complete nonsense. The thing that the article is missing is the fact that once you start using a particular piece of software, it is hard to switch to another piece. This is called "lock-in" and I'm surprised a magazine aimed at executives didn't mention this once. You can threaten to cancel your subscription all you want, but if the vendor knows that it will cost you X million dollars to switch over to another product, you lose all of your leverage. It doesn't matter if you pay for your crack in one lump sum or if you pay for your crack on a monthly basis; you are still addicted to the crack.
Finally, to tout open source as the solution to these CIOs' problems is garbage. The pieces of software mentioned in the article are big time accounting packages. There is no open source equivalent for these things. Even for things where there is an OSS equivalent (web server, database), just because it is open source doesn't mean that all the bugs are going to go away. All software, whether it's open or close source is going to have bugs. To suggest that open source is the "silver bullet" of software development a la Fred Brooks is silly.
It is scary to me that CIO actually are going to read this drivel.
It would seem to be that if Congress, in its haste, creates new unconstitutional laws, it could end up sabotaging the efforts to bring these terrorists to justice. Congress would sure look foolish if bin Laden was able to walk out of court a free man because of some technicality.
I believe there is also a SD conference on the West Coast (SD West?), so that may be more geographically convienent. From what I understand, it is basically the same conference.
As others have already pointed out some other shortcomings (low signal-to-noise ratio, major sites can't handle the traffic) I won't repeat those arguments. I would like to point out another shortcoming in that many of the news sites out there simply repeat the same stories almost verbatim from AP, Reuters, NY Times, CNN, and other major news organizations. On Sept 11, most of what I saw on IRC, Slashdot, etc was simply rehashing of what was being reported on TV. Instead of being a source for new and novel information, it was simply an alternative distribution medium for the same information that was being presenting by "primary" news sources. Until there is a major web-only news site that hires its own reports and develops its own content, the Net will be dependent upon the "old world" new organizations for its content.
Another shortcoming of the Net is it's transitory nature. The Net doesn't have the permanence of print or even broadcast news. When the NY Times prints an article, it is out there for all times. News on the web, on the other hand, comes and goes as new pages are added and old ones are retired. There is a reason why the NY Times is often called the "newspaper of record". Until the Net gains the ability to archive a snapshort of its content and retrieve it, it won't have the same utility as other media.
A lot of what Katz talks about it is how the Net isn't acting as a news source, but as a community where people can share their views and opinions. This is great, but the opinion of Joe Blow from Iowa isn't what I would call news in the sense that the NY Times is news.
I think people like Katz have a tendency to hype up the Net to the point of ridiculousness, like it is the be-all-and-end-all of life. Yes, it is a new and wonderful invention, and yes it does add some new dimensions to human interaction, but does it change the fundamental rules of nature somehow? I find that hard to believe.
In classes that teach basic programming and other CS concepts, I think students are much better off writing their own programs and doing their own work. How else are they going to learn these basic skills?
There are classes where group projects may be appropriate if done right. The classes I'm thinking of are software engineering type classes where much of the subject matter centers around being able to organize projects into modules, code the modules, and integrate these modules together.
However, if a class is going to teach teamwork, it's actually got to teach it. Professors can't just divide up the class in to groups of N, give them a project that is N times a normal, single-person project, and let them go. As others have pointed out, that is a recipe for disaster!
They actually have to instruct them in how to go about dividing up the work, designing interfaces between modules, integrating code, using source control to track changes, etc. Otherwise, they aren't really learning how to program as part of a team.
I was an EE major in college, and I never had to touch a soldering iron during my 4 undergraduate years. All of our projects were either done using a breadboard, a wirewrap board, or using a computer simulator.
It seems to me that one reason why all of these techno-stupid laws get passed is because the people who represent us don't know a darn thing about computers and technology. If there were a few engineers/computer scientists in Congress, the odds of these things getting passed and signed into law would decrease.
A friend of mine is a veterinarian, and she tells me that there are a couple of Vets who are in the House and Senate, and they have a lot of influence when it comes to laws relating to animal welfare and biology in general. When a bill comes before Congress that has to do with their area of expertise, there view carries a lot of weight among their collegues.
Also, groups that lobby on behalf of Vets (the American Veterinary Medical Association, for instance) has automatic allies in Congress because of their professional affiliation. If something concerns Vets, you can be sure that these politicians will know about it, and will be doing something about it.
I think it would be great of the tech establishment has somebody who could do that for us. Perhaps one of those dot com millionaires would be willing to put up some of their riches (a la Ross Perot) to make a run for Congress. There are enough rich geeks out there that we can't use lack of money from fundraisers as an excuse.
To take the point even further, I think it would be great if Congress represented the true cross-section of professions, and not just lawyers career politicos. Of course, that's just a pipe dream...
Well, I guess it's beer so who cares who good it tastes as long as it's cheap and potent, right?