Slashdot Mirror

We don't need engineering, we need mind-readers. If users had enough time to sit and be thoroughly interviewed about needs and preferences, they wouldn't need automation to begin with.

And further, how to make software maintainable in the longer run is highly disputed largely because it depends on "wetware" and unknowns, such as developer perception of code, and unknowable future domain changes.

It's more akin to writing technical documentation than to building a bridge: how do you write documentation that's clear to the audience, but flexible enough that it doesn't have to be largely reworked for every change.

There is no magic modularity formula: domain issues inherently intertwine (or can intertwine in the future even if not at original launch.) You can't hide intertwining, you have to find a way to manage it well.

To deal with this what we do is go quickly to the UI.. once you show them they can give you better feedback. There's also some research supporting this.

http://www.construx.com/Though...

The integration with the third party systems does make it more difficult, but cetainly better is possible. You could even rent space in many linux virtual private servers across the country to act as testing nodes. Finally, why roll it out to the whole country at once? That seems quite risky without a lot of testing, including perhaps a few public betas. I also wouldn't require a login to browse. Let people put in the bare minimum needed to compare plans and see what subsidy they are eligible for without a login.

As for as the nonsese with firing Kathleen Sebelius (sp?) that is largely useless and just another cheap stunt by republicans to hurt democrats and or their policies while at best contributing nothing to solving what they are complaining about. Sure if it is later found out she failed to exercise due dilligence or contributed to the mess do it then, but short term find the right people to first look at what is going on and make sure that things are fixed asap, and for that you likely need everyone who participated in a non hostile environment. After all, people that know or expect they are about to get let go are hardly likely to help you fix the mess very well, and given the convuleted nature of interfacing with all those legacy systems there could be reasons behind some of the mess.

Still it is clear that there were mistakes made in the process. If what is here is accurate they only got sufficient requirements far too late in the process so failure was almost assured. This kind of thing really needed to be done and under major load testing a year ago.. Finally, this poster usually fits the situation. Construx Poster

FACT: A good team of average people, working together, will accomplish more than a single person over the course of two months.

This is categorically false. Individual output of programmers vary by an order of magnitude (10x source). Literally one guy can be worth ten others. And this is why the "do you really need rockstars" is always a yes. Even if you are not trying to solve hard problems you can either hire 10x guys @ 50k a year or one guy at 150k a year. You make the choice.

It's not just developers. This is why we have unions and labor regulations. They can always find replacements: even in good times, one person in twenty is unemployed at any given time, a figure that the Federal Reserve works very hard to maintain lest it create upward pressure on wages. And most people prefer shitty working conditions to the uncertainty of finding another job, never mind actual unemployment.

This has to be balanced with the fact that the unemployment rate for programmers tends to be *much* lower than the general employments rate. Also, the skill difference between an average programmer and a great programmer is a factor of 10 in productivity which means that programmers are not commodities. If you're good at programming and well connected you can do very well.

By the way, 5% unemployment is basically full employment. It gets disproportionately harder to do better the closer you get to 0% unemployment. Programmers (especially good ones) are extremely rare and hard to hire.

Scores of people have investigated this in the past. A good reference is Steve McConnell's "Software Project Survivial Guide". He has a company, Construx, with some excellent tools for scoring a software project.

Steve McConnell is one of the good guys, and deserves the huge amount of respect he's earned; but I've really got to wonder about his web site's EULA:

By viewing, downloading, and/or using material from this web site you agree to be bound by the terms defined in the license agreement ... This is the License Agreement for Construx CxOne Basic (the "Product").... You may not use the Product as your organizational software process. You may not use the Product in conjunction with all or with multiple software projects in your organization, division, department, or company....

This appears to be describing, not only what you can (and can't) do with some evaluation software, but also with the information you get from reading HTML and PDF files on the site.

Words fail me.

There's good resources on the Construx web site too.

Resources

I am surprized that I haven't seen others mention this, but make sure you are getting the right education for you. People learn different, and you may of had a problem with the learning / study methods used at university.

There is a difference between difference schools, state vs. private universities, two and four colleges, polytechs, and distance education vs. correspondence. Research the options, and pick the right one for you.

In this day and age you do not need to attend classes in person to earn a meaniful degree, in UK, the Open University leads the way, and in Canada there is Athabasca University, I am not as familiar with US schools, but there is the University of Phoenix as well as many others.

Define your goal(s) of attending a post-secondary school. Also an idea for your career goals might be useful, but you need specific education goals. Write them down. I said, write them down. This is how you will evaluate schools, programme and course choices.

Is it just to have a degree? Do you want more a fundamential understanding (i.e. theoric) of computing? Do you want business skills? To become a better rounded software engineer? Understand business, so you can grow your own business? Get a MBA? Meet women? For technical training? To earn more money? Continue doing what you already do, or so you can do something new? Certification?

An university degree is suppose to be based upon a theorical understanding, which while being less specific (i.e. more abstract), is more lasting and will not be outdated every 3 years. That is the #1 source of frustration and confusion I see from young computer science students. An university degree is not a career training programme. You get to do the career training in your own time.

Make use of your electives, do not choose courses because you think they will be easy like "Rocks for Jocks" and "Clap for Credit", find introductary courses you will be interested in, and will benefit you either personally or professionally.

Most schools have some means of providing tours of their facilities, especially in the summer. Since this is an investment that will cost approx. $40,000, you should research this investment as being right for you. If possible, arrange a talk with someone from the department that you are looking at majoring in.

Bone up on time management and planning skills, and study skills if you find studying difficult. University is about learning, but unfortunately very little is taught about how best to learn (for you). Read Stephen R. Covey's The 7 Habits of Highly Effective People it will help in setting your priorities, and planning. To help learn about learning, John L. Adams book Conceptual Blockbusting: Care and Feeding of Ideas, and George Polya's How to Solve It.

Practice reading, seriously if you do not do a lot of non-fiction book reading, start doing some more. A list of books any /.er should enjoy is Steven C. McConnell's Top 10 Reading List.

Steve has left Microsoft and started his own company Construx Software. There are some good Software Engineering references and links on their web site.

Some other good Steve McConnell books:
Software Project Survival Guide ISBN: 1-57231-621-7
After the Gold Rush: Creating a True Profession of Software Engineering ISBN: 0-73560-877-6

Steve has left Microsoft and started his own company Construx Software. There are some good Software Engineering references and links on their web site.

Some other good Steve McConnell books:
Software Project Survival Guide ISBN: 1-57231-621-7
After the Gold Rush: Creating a True Profession of Software Engineering ISBN: 0-73560-877-6

Steve has left Microsoft and started his own company Construx Software. There are some good Software Engineering references and links on their web site.

Some other good Steve McConnell books:
Software Project Survival Guide ISBN: 1-57231-621-7
After the Gold Rush: Creating a True Profession of Software Engineering ISBN: 0-73560-877-6

• Extreme Programming explained page 60: ...no one can put in 60 hours a week for many weeks and still be fresh and creative and careful and confident. Don't do that. and on the same page: Overtime is a symptom of a serious problem on the project. The XP [ = Extreme Programming ] rule is simple - you can't work a second week of overtime. The XP philosophy works on the basis that software development is a creative process, and therefore needs a clear mind.
  
• Rapid Development pages 599-608: Don't require [developers to put in] overtime; it will produce less total output. In this chapter, McConnell states that voluntary overtime is a good thing, but that requiring overtime all the time is bad.
  

I don't work for them, but I find the Construx Software Reading List to be an excellent guide. It has preferred and alternates for various topics. Here's a sampling:

Introduction to Algorithms, Thomas H. Cormen, et al
Code Complete, Steve McConnell
201 Principles of Software Development, Alan M. Davis
The Design of Everyday Things, Donald A. Norman
Fundamentals of Database Systems, Ramez Elmasri and Shamkant B. Navathe
Design Patterns, Erich Gamma, et al.
Software Runaways, Robert L. Glass
Wicked Problems, Righteous Solutions, Peter DeGrace and Leslie Hulet Stahl

The reading list also includes classic articles and recommended periodicals.

My experience has shown that the number one way to find defects is code reviews performed by other developers who can read the code and also understand the intended functionality. This will catch 90% of all defects before they are even released to QA.

Overally, good testing catches perhaps 63% of all defects. Code inspections alone catch about 63%. Combined on a project, they catch about 95+% of all defects. That's the key. (My copy of Code Complete is at the office and I'm still at home, but that has the exact numbers and study).

And remember, a good testing regiment will include all kinds of testing. Unit tests and integration tests are both needed (Usually it's only the latter that happens in QA). And it's quite handy to have started the unit tests before you start coding the units.

Please note that you are asking a question similar to "Are there any good books that cover the process of living? You know, what it's all about, and particularly what rituals to follow for success?" You are likely to get religious answers to religious questions.

For a good overview of development practices, though, pick up McConnell's Rapid Development . The main thing to come along since then is the various agile processes like XP. For the scoop on that, pick up Extreme Programming Installed . (Don't get Beck's book, Extreme Programming Explained to start with; it's a manifesto, not a practical book.)

As with religion, you should probably ignore the people who claim to have The Answer ("Use UML!" "Use XP!" "The word of the Architect shall be as law, and you verily must smite the coders who stray from it." "Only infidels use COBOL/VB/C++/Java!" "There shall be no editor but Emacs!").

Instead look at it more like home maintenance or martial arts. Is a screwdriver better or worse than a hammer? Is a punch better than a kick? Those questions can be entertaining, but they are never helpful. The right questions are more subtle: "Given the problem I'm facing, what tools might help? How should I adapt them to the situation? And how can I tell when they help rather than hinder?"

The OReilly CD bookshelves are really really good value for money, and the space saving on a bookshelf is nothing short of phenomenal (in addition to searchable pages and indexing)

Not all of them are of the same quality, though.. as mentioned earlier, the Perl CD bookshelf is excellent, I'd also highly recommend the Oracle PL/SQL bookshelf (for anyone interested in doing database programming in particular)..

In addition to Code Complete, Rapid Development is also a great book for anyone in the IT industry (this is also written by Steve McConnell).. another couple of great programming books are written by Steve somebody (McGuire ? yup, google tells me that's right.. link here )

Another book highly recommended to me is The Pragmatic programmer, although I haven't gotten hold of a copy yet :).. You've also missed out some literature on Extreme Programming which might come in handy...and here's the link for the FreeBSD book, mentioned earlier...

Kimba is spot on.

Code Complete also goes over layout and style, the other two pillars of readable code. Check out the link in the previous sentance, it is to the author's site which includes sample chapters, the table of contents, and a link to deal pilot where you can help the author by giving him the referal commission and get the book on the cheap.

Yep! The "first pancake" approach is a good one. And, as other posters have noted, a venerable one. Why? as you point out, you discover a lot as you go, both about the user needs and about how to do them well.

But you can go further with this! Any short-cycle iterative model will give you this sort of feedback every couple of weeks, rather than at the end of every version.

For more info on it, take a look at Rapid Development's discussion of evolutionary delivery. Or try a process that's built around feedback, like Coad's Feature Driven Development or, my personal favorite, Beck's Extreme Programming (XP) (dumb name, but a great process).

I just read an interesting quote from IEEE Software, Vol. 13, No. 5, September 1996: "The 1994 Standish Group survey found that the average IT project took about 220 percent of its planned schedule."

Perhaps we've become a lot better about setting up reasonable schedules since 1994, but I have a don't have enough faith in humanity to believe that.

Productivity: A Personal Choice

Chief Programmer Teams

Intermittent Aberrations: Can Mature Companies Innovate?

How to Defend an Unpopular Schedule

The Mythical Man-Month by Fred Brooks. A classic, and is not tedious to read. 2nd edition 1995 ISBN 0201835959

Peopleware: Productive Projects and Teams by Tom Demarco and Tim Lister. 2nd edition 1999 ISBN 0932633439

These are both readable and relevant to developers and managers. I think anyone involved in software development should read these books.

Check out Steve McConnell's Construx recommended reading list: http://www.construx.com/ladder/index.htm

It doesn't matter. It doesn't matter because the techniques are basically the same. You want to learn the concepts of programming, of abstractly representing information, writing a series of logical statements. Concepts like structured programming, modular programming, object-oriented programming, functional programming, and software engineering are vastly more important then whether you use GKT+ or KDEfoobar.

For ground-zero programming experience, I think Deitel& Deitel ___ How to Program books are a good choice.

Practice what you learnt in step zero.

Step two, I would strongly recommend reading comp.risks, The Mythical Man-Month, Code Complete, Programming Pearls, and The Practice of Programming. These focus on high-level knowledge, which is more important that low-level details. Other requirements include understanding computers, see Computer Architecture : A Quantitative Approach by Patterson and Hennessy. A hard-core introduction to programming, used at MIT, is Structure and Interpretation of Computer Programs by Hal Abelson and Gerald Sussman.

Honestly the details will become clearer and easier if you have a good understanding of the big picture first.

I started out writing code with a four year degree, and while it was a good living, I had one problem with that career path: lack of control. My projects could be scrapped without warning, or sent in directions by Marketing that were totally without technological merit. That's why I went back to school - I got my MBA from Johns Hopkins through their three-year night school program. I was able to work my way through the experience, and I feel that it was totally the right way to go for me personally.
It's not the right path for everyone. If you have bad social skills, don't like to make command decisions, or don't feel that you're a pro-active person, you should probably just keep on writing code. But if you feel that you can combine your technical expertise with leadership abilites, an MBA is a great stepping stone.
Managing a technical project is very stressful work (I've heard the task of managing developers compared to "herding cats") but it can be very rewarding. Last year I finally had the opportunity to fire the office "Open Source Zealot" - the guy who wasted everyone's time complaining how "Outlook is insecure" and "I only use Linux on my notebook computer". The things you can do as a good manager:
- Refining your working unit only to productive, focused people,
- Refining your product definition to a technologically innovative, easy-to-use product
- Keeping your team in touch with the latest advancements in the marketplace
... can be part of the most rewarding career experience you will ever undergo.

For more information, Sharon is the man (so to speak).

Good luck!

My employer (who, like me, shall remain nameless) used Viant. What a complete fucking disaster. They couldn't be bothered to really understand what we were doing, or sometimes what their predecessors had done. They had lots of meetings to discuss The Process. The Process involved many, many more meetings [...]

Facinating! (Hey moderators! Moderate the AC post up so others can see the whole thing.) This sounds a lot like Verde.com's experience with sound-alike consulting shop Scient, at least as told in the article How Scient helped Verde.com go from launch to bankruptcy in less than 60 days. And everybody there had to remain anonymous, too.

I broadly agree that putting somebody else in charge of the very heart of your business is a dangerous thing, and I generally discourage it. But people can also tell in-house development disaster stories, so that's no silver bullet. Indeed, I've seen projects fail because management couldn't resist meddling in in-house projects. An external vendor has more power to deflect or channel insane client demands; that power can be very beneficial to a project if used wisely.

One important distinguishing factor is whether or not you have a lot of ongoing development needs. Some projects have a huge amount of inital work and then a much smaller amount of ongoing work; it doesn't make sense to build up a big in-house staff, get them to work as a team, train them to your needs, and then fire half of them when the project is done.

On the other hand, most clients (and non-technical bosses) tend to overestimate the need for a big initial push and underestimate the need for ongoing work. As any developer knows, what people initially imagine they want and what they actually end up wanting once they've been through several iterations of development are usually pretty different. And if you're doing a web site or other Internet-delivered service, you can usually roll new features out gradually, further reducing the need for a huge initial dollop of work. So if your project can use an evolutionary delivery model building an in-house staff can make a lotta sense.

For people interested in these topics, I recommend Steve McConnell's Software Project Survival Guide. And if you're a developer, project manager, or somebody else actually working on a project, his Rapid Development is also great. And hey! I hadn't seen this before, but he wrote a magazine article on Managing Outsourced Projects.

My employer (who, like me, shall remain nameless) used Viant. What a complete fucking disaster. They couldn't be bothered to really understand what we were doing, or sometimes what their predecessors had done. They had lots of meetings to discuss The Process. The Process involved many, many more meetings [...]

Facinating! (Hey moderators! Moderate the AC post up so others can see the whole thing.) This sounds a lot like Verde.com's experience with sound-alike consulting shop Scient, at least as told in the article How Scient helped Verde.com go from launch to bankruptcy in less than 60 days. And everybody there had to remain anonymous, too.

I broadly agree that putting somebody else in charge of the very heart of your business is a dangerous thing, and I generally discourage it. But people can also tell in-house development disaster stories, so that's no silver bullet. Indeed, I've seen projects fail because management couldn't resist meddling in in-house projects. An external vendor has more power to deflect or channel insane client demands; that power can be very beneficial to a project if used wisely.

One important distinguishing factor is whether or not you have a lot of ongoing development needs. Some projects have a huge amount of inital work and then a much smaller amount of ongoing work; it doesn't make sense to build up a big in-house staff, get them to work as a team, train them to your needs, and then fire half of them when the project is done.

On the other hand, most clients (and non-technical bosses) tend to overestimate the need for a big initial push and underestimate the need for ongoing work. As any developer knows, what people initially imagine they want and what they actually end up wanting once they've been through several iterations of development are usually pretty different. And if you're doing a web site or other Internet-delivered service, you can usually roll new features out gradually, further reducing the need for a huge initial dollop of work. So if your project can use an evolutionary delivery model building an in-house staff can make a lotta sense.

For people interested in these topics, I recommend Steve McConnell's Software Project Survival Guide. And if you're a developer, project manager, or somebody else actually working on a project, his Rapid Development is also great. And hey! I hadn't seen this before, but he wrote a magazine article on Managing Outsourced Projects.

My employer (who, like me, shall remain nameless) used Viant. What a complete fucking disaster. They couldn't be bothered to really understand what we were doing, or sometimes what their predecessors had done. They had lots of meetings to discuss The Process. The Process involved many, many more meetings [...]

Facinating! (Hey moderators! Moderate the AC post up so others can see the whole thing.) This sounds a lot like Verde.com's experience with sound-alike consulting shop Scient, at least as told in the article How Scient helped Verde.com go from launch to bankruptcy in less than 60 days. And everybody there had to remain anonymous, too.

I broadly agree that putting somebody else in charge of the very heart of your business is a dangerous thing, and I generally discourage it. But people can also tell in-house development disaster stories, so that's no silver bullet. Indeed, I've seen projects fail because management couldn't resist meddling in in-house projects. An external vendor has more power to deflect or channel insane client demands; that power can be very beneficial to a project if used wisely.

One important distinguishing factor is whether or not you have a lot of ongoing development needs. Some projects have a huge amount of inital work and then a much smaller amount of ongoing work; it doesn't make sense to build up a big in-house staff, get them to work as a team, train them to your needs, and then fire half of them when the project is done.

On the other hand, most clients (and non-technical bosses) tend to overestimate the need for a big initial push and underestimate the need for ongoing work. As any developer knows, what people initially imagine they want and what they actually end up wanting once they've been through several iterations of development are usually pretty different. And if you're doing a web site or other Internet-delivered service, you can usually roll new features out gradually, further reducing the need for a huge initial dollop of work. So if your project can use an evolutionary delivery model building an in-house staff can make a lotta sense.

For people interested in these topics, I recommend Steve McConnell's Software Project Survival Guide. And if you're a developer, project manager, or somebody else actually working on a project, his Rapid Development is also great. And hey! I hadn't seen this before, but he wrote a magazine article on Managing Outsourced Projects.

My employer (who, like me, shall remain nameless) used Viant. What a complete fucking disaster. They couldn't be bothered to really understand what we were doing, or sometimes what their predecessors had done. They had lots of meetings to discuss The Process. The Process involved many, many more meetings [...]

Facinating! (Hey moderators! Moderate the AC post up so others can see the whole thing.) This sounds a lot like Verde.com's experience with sound-alike consulting shop Scient, at least as told in the article How Scient helped Verde.com go from launch to bankruptcy in less than 60 days. And everybody there had to remain anonymous, too.

I broadly agree that putting somebody else in charge of the very heart of your business is a dangerous thing, and I generally discourage it. But people can also tell in-house development disaster stories, so that's no silver bullet. Indeed, I've seen projects fail because management couldn't resist meddling in in-house projects. An external vendor has more power to deflect or channel insane client demands; that power can be very beneficial to a project if used wisely.

One important distinguishing factor is whether or not you have a lot of ongoing development needs. Some projects have a huge amount of inital work and then a much smaller amount of ongoing work; it doesn't make sense to build up a big in-house staff, get them to work as a team, train them to your needs, and then fire half of them when the project is done.

On the other hand, most clients (and non-technical bosses) tend to overestimate the need for a big initial push and underestimate the need for ongoing work. As any developer knows, what people initially imagine they want and what they actually end up wanting once they've been through several iterations of development are usually pretty different. And if you're doing a web site or other Internet-delivered service, you can usually roll new features out gradually, further reducing the need for a huge initial dollop of work. So if your project can use an evolutionary delivery model building an in-house staff can make a lotta sense.

For people interested in these topics, I recommend Steve McConnell's Software Project Survival Guide. And if you're a developer, project manager, or somebody else actually working on a project, his Rapid Development is also great. And hey! I hadn't seen this before, but he wrote a magazine article on Managing Outsourced Projects.

The problem with going to Java from C++, is that when you dumb down the language, you also dumb down the programmers.

As we covered elsewhere in this thread, it's true that Java tends to penalize developers (and users) for programmer error a little less than C/C++. That's not intrinsically good or bad; that's just how it is. It's practical goodness/badness depends on circumstance.

If you're using the language mainly as a training tool, then this insulation is bad. It allows developers to become sloppy, and keeps them from learning why sloppy is bad. A more raw language is a steeper learning curve, but that just means that you get to the high ground more quickly.

But if you're using the language to deliver a real-world product, then this insulation is good. Your goal is to deliver a useful thing quickly. SEGVs are certainly helpful to the developer, but the user of a piece of crashing software generally doesn't share that opinion.

And really, the goals of developer improvement and user satisfaction aren't mutually exclusive; you just have to use different tools than crashing code. Instead, you use things like walk-throughs, design review, code review, and pair programming. All of these techniques results in better people, better code, and happier users. And this is true regardless of how forgiving your language of choice is.

Note also that your argument applies even better to, say, assembler. The closer you are to the hardware, the better your code is likely to be, because there's less to take up your slack. But I take it you don't do most of your work in assembler, right?

[...]chasing marketing-driven rainbows.

The silver-bullet syndrome has been around much longer than Java. Indeed, many people had exactly the same gripes about OO programming or, for that matter, C.

The so called "evils" of C/C++ [...] Are solved quite well with tools [... and] good disciplined techniques.

Instead of C/C++, you can insert any language in that statement. A skilled developer with the right tools and a sense of discipline can do good work in almost any language. Comparing the work of experts in one language with the work of fools in another is not a very useful thing to do.

What's interesting is that another rather sophisticated software development book, Software Project Survival Guide by McConnell says that one or two person offices are much better than more open, less private cube farms. He cites "After 15 Years," an essay by Tom DeMArco and Timothy Lister, that was published in the book Peopleware: Productive Projects and Teams. They claim that workers who work in the top 25% of environments are 2.5 times more prodcutive than those in the bottom 25%. Maybe the addition of being in extremely close contact is enough to overcome the distractions.

I'd like to see more research. Take the same team, put them in cubes, offices, and war rooms, and see how they do. It strikes me as entirely possible that the practices they talk about in the article as only being possible in "extreme collocation" are in fact applicable to any development team. Thus, the real factor is the implementation of software development best practices, and not the work environment. And there's plenty of studies that show good software process to be helpful, so it's not surprising that there was a big jump in productivity.

Well, I'm off to do some software process, by myself in my office. Gotta get those requirements written down...

Walt

For anyone wanting to begin using a quality methodology in their programming, I make the following suggestions:

1) Read [Steve McConnell's] three books. It's a good start. What he writes is based on solid research, which he shares with you. His books aren't the complete answer to all problems, but reading them and using a bunch of the tools/methodologies he describes is a great way to begin doing things better.

2) Do a Google search on "Software Capability Maturity Model" and start researching. Eventually you'll come across the Software Engineering Institute, and their [summary of CMM], which is well worth reading.

3) Do a Google search on "Bell Canada Trillium" and start researching. The [Trillium model] is well-respected, and is based on ISO, CMM and other best practices. Where it differs is that it actually tells you what to do; the others tell you what you need.

4) Do as much as you can with the structures that are described, plan on how to do them all, and adapt them to your needs. Identify what works and what doesn't, and fix those things that don't.



--

Bravo, bravo, bravo!

I'd like to suggest that everyone who is a web author, and certainly everyone who makes any claim to be a web designer, should read Steve McConnell's "Rapid Development: Taming Wild Software Schedules" and "Software Development Survival Guide." They are recognized as authorative, leading texts on Best Practices in software design.

Web design is similar to software design, and you will learn how to do your work faster, better and with fewer mistakes. You will learn the importance of emphasizing up-front design (it's a minimum twenty times cheaper to catch your errors early than later) and how to control risks, client change demands and schedules.

You can visit Steve's site [here], where you'll find some outtakes from his books, his columns on software development best practices, and other good stuff.


--

Coding distinguishes Software Enginneering from other engineering fields. However, it is not the entire field by any means. Project management, Requirements and Analysis, Architecture, and testing are also vitally important. Steve McConnell has written a book "After the Gold Rush" based on his IEEE essays on Software Engineering. I found it interesting, but not very deep - perhaps it would be a good start for a student. His home page has biblographies and links that I've found very useful.

The points made in the comments "Most open source projects are really only the work of one or two people" and "how many people ever read the source code to something they download?" are well made. I can't say for certain, because I haven't carried out a poll or seen any statistics. What I know from the literature (such as CatB), experience and observation is that most open source projects start out as an itch that a programmer decides to scratch. The majority of people who find out about the project don't do anything except download the binary, a few download the code, a fraction of them comments and a fraction of that fraction hand back some modifications. Only a small portion of the much-vaunted "many eyes that make bugs shallow" are actually being harnessed. That's not a bad thing -- the closed source model exposes the software to even fewer eyes. It's just that there are many obstacles to fixing or modifying someone else's code: how the original programmer wrote it, availability of documentation, availability of the programmer to answer questions, whether it's written in a language you know, the complexity of the program's problem domain, how good a programmer you are, and the big one -- how much time you have.

The primary advantage provided by open source to a program's developer is the potential peer review and fine-grained testing that freely handing out your source gives you. There's a large body of evidence that code review is one of the best ways for incresing software quality. However, as Fred Brooks says, there's no silver bullet for the problems of software development, and peer review is only one step in making good software. Without good planning and process, all you have is a bickering committee. And we know why they don't make statues, painting or memorials of committees, right?

There's a very good article by Steve McConnell (author of Code Complete, Rapid Development, Software Project Survival Guide and After the Gold Rush) covering some of the issues around open source software. He points out that if open source wants to really reach its potential, the following needs to be done:

1. Create a central clearinghouse for the open-source methodology so it can be fully captured and evolved.

2. Kick its addiction to Code and Fix.

3. Focus on eliminating upstream defects earlier.

4. Collect and publish data to support its claims about the effectiveness of the open-source development approach.

===

Getting back to the original reason for this post -- could I ask one of you moderators to consider cancelling out the "troll" rating for the previous post with an "underrated"? A contrarian opinion does not constitute a troll.

Wow.. the number of people who are recommeding this microserf's books is amazing. Just because someone writes a metaprogramming book does not make them a guru. I just love the whole article he has about Microsoft's "fantastic working environment". People begging to be locked in a room and whipped with break neck schedules does not make a good working environment. I just love the "non-monetary rewards" he talks about.. T-Shirts, beach towels and mouse mats.. as opposed to enjoyable and stimulating work or peer recognision. Sure, they strike every reference of your name from your code but they give ya a free hat!

I actually like Code Complete better. Written by Steve McConnell, who is a veritable font of programming wisdom for both developers in the trenches and project managers. Though both books are well worth it.

--GnrcMan--

Steve McConnell is president and chief software engineer at Construx Software, where he divides his time between leading custom software projects, teaching classes, and writing books and articles. He is the author of the Microsoft Press books Code Complete (1993), Rapid Development (1996), and Software Project Survival Guide (1998). His books have twice won Software Development magazine's Jolt Excellence Award for outstanding software development book of the year. In 1998, readers of Software Development named Steve one of the three most influential people in the software industry along with Bill Gates and Linus Torvalds. In his spare time, Steve serves as editor in chief of IEEE Software magazine. He is on the panel of experts that provides advice to the Software Engineering Body of Knowledge (SWEBOK) project, and is a member of IEEE and ACM.

Steve earned a bachelor's degree from Whitman College and a master's degree in software engineering from Seattle University. He lives in Bellevue, Washington with his wife, Tammy; daughter, Haley; and dog, Daisy. If you have any comments or questions about this book, please contact Steve via e-mail at stevemcc@construx.com or via his web site at http://www.construx.com/stevemcc/.

I known I've seen his books on the shelf, but only laugh we I see such titles by MS Press. Fun to read I suppose, but nothing exactly insightful, or even surprising.

Steve McConnell is president and chief software engineer at Construx Software, where he divides his time between leading custom software projects, teaching classes, and writing books and articles. He is the author of the Microsoft Press books Code Complete (1993), Rapid Development (1996), and Software Project Survival Guide (1998). His books have twice won Software Development magazine's Jolt Excellence Award for outstanding software development book of the year. In 1998, readers of Software Development named Steve one of the three most influential people in the software industry along with Bill Gates and Linus Torvalds. In his spare time, Steve serves as editor in chief of IEEE Software magazine. He is on the panel of experts that provides advice to the Software Engineering Body of Knowledge (SWEBOK) project, and is a member of IEEE and ACM.

Steve earned a bachelor's degree from Whitman College and a master's degree in software engineering from Seattle University. He lives in Bellevue, Washington with his wife, Tammy; daughter, Haley; and dog, Daisy. If you have any comments or questions about this book, please contact Steve via e-mail at stevemcc@construx.com or via his web site at http://www.construx.com/stevemcc/.

I known I've seen his books on the shelf, but only laugh we I see such titles by MS Press. Fun to read I suppose, but nothing exactly insightful, or even surprising.

I agree with the assertion that there should be a standard statement of ethics for software engineers. In fact, I believe that a Professional Engineering certification should be mandated by law before anyone can refer to themselves as Software Engineer". Software has assumed an all important role in our society. People responsible for designing, developing, and deploying software systems should demonstrate some minimal level of competence. If you are interested in this topic, I have some links on the subject available at this site. Also check out Construx for other sources.

Strong second on Steve McConnell's books, though my personal favorite is Code Complete. Steve continues to write on this topic, and is using his current position as editor of IEEE Software to continue spreading the gospel^H^H^H^H^H^Hmessage.

He's been getting curious about the open source movement and the Linux phenomenon -- note Software's Jan/Feb 1999 Linux edition, and the editor's column and response in the current (Jul/Aug 1999) issue. Access is limited to IEEE and ACM members, but editor's columns tend to show up after a month or so at the Construx website.

Among Steve's criticisms of OSS are that design and architecture documentation are sorely lacking. As others have noted here, there are many instances where free software has set sights on existing functionality -- implementing systems the way they should have been in the first place, often closer to the design documentation than the proprietary application.

#1 - Steve McConnell is NOT an employee of MS. He is a consultant that they have used (occasionally to bring their products back on track when they start slipping).

Quite often he also uses his experience from MS as examples of something NOT to do.

Just because he wasn't involved in the development of Unix Or C doesn't mean he isn't a highly capable programmer.

To find out more about him, chekc out his
home page (http://www.construx.com/stevemcc/)

Despite the irony of being published by Microsoft, this really is quite a solid book. It's the best of the three titles produced by McConnell (others are Rapid Development and Software Project Survival Guide). McConnell maintains related information at his web site.