Slashdot Mirror

I agree with the idea to study mathematics, as a useful exercise, that would in many cases benefit programmers by giving them a good mental workout, and hopefully reinforce if not expand their understanding of mathematics, logic, and reasoning.

Beyond that I would argue for the study of writing, in a natural (human-oriented) language of your choice.

Programming as a profession, and as an art, is about the meaningful expression of ideas; in a detailed, unambiguous manner that can be processed by a computer. Programming languages are tiny, simplistic, and restrictive in their ability to express ideas, and the execution of these ideas. Writing in a natural language is much more complex, particularly when you strive to remove undesired ambiguity*. The other issue is that as a professional, programming is not done in isolation. Even if you are an independent contractors, you must be able to communicate effectively with clients and users.

*) Ambiguity can be desirable in humor and poetry.

I think that any programmer can benefit from the abilities to make logically sound, comprehensible arguments in a written document; that these abilities will make them better in their ability to understand, and be understood by users, customers, or colleagues.

The argument has been made in the past by Steven C. McConnell in Code Complete, in The Pragmatic Programmer by Andrew Hunt and David Thomas, Coding Horror by Jeff Atwood, and Joel Spolsky (of Joel on Software) in his Introduction to Best Software Writing I and College Advice. And like tons of other software developers, and their managers; repeatedly.

You see, communication is the only really important aspect of software development that people really have trouble with. The rest are details and small bugs, but for really big screw-ups you need miscommunication (or greed)

Shouldn't they be computer scientists? Software engineering, while related, is not the same thing as computer science. Would you ask a scientist to build a bridge, or an engineer?

I hate unions. I'm a member of a professional association.

Completely with you. Professional standards, with professional practices, held to account for delivering professional output.

Start doing that repeatedly and we can start exploring territory the lawyers and doctors have already carved out: mandatory professional body accreditation, as a guarantor of the professional outputs.

Reading material: http://www.stevemcconnell.com/psd.htm

GOTOs can be a useful language feature, improving program speed, size and code clearness, but only when used in a sensible way by a comparably sensible programmer.

Linus Torvalds: http://kerneltrap.org/node/553 (mirror at the Wayback Machine)
Steve McConnell: http://www.stevemcconnell.com/ccgoto.htm

It doesn't make sense that a software engineer would need a degree in computer science. They are two different domains.

Maybe software tends to be so buggy because it isn't always engineered to be reliable. It's cobbled together in the lab, and if it works in the lab, the assumption is that it will work in the field.

As a programmer it scares me genuinely to see your post get rated +5 Informative. GOTOs have no place in man made code. There are so many reasons why not to use GOTOs, and only very few situations that GOTOs make for cleaner code (specifically, the usually implemented break, last and next GOTO surrogates). If one of the people in my team uses GOTOs I tell them off.

A brief study of the pros and cons: http://www.stevemcconnell.com/ccgoto.htm

As you can tell from that, and many other sides, there are no major pros to using GOTOs, but very major negatives. Many modern languages don't support GOTO, or only include it to support machine generated code (ADA).

Have you counted the number of GOTOs in the linux kernel?

The problems you describe under "capital-M Methodologies" sound similar to "Cargo Cult Software Engineering" http://stevemcconnell.com/ieeesoftware/eic10.htm

Steve McConnell

Project management is not only for the managers. Grab some basic books on the subject (hopefully based around software development) and have the coders read them.

If nothing else, it gives everyone a shared vocabulary for the situations and approaches that they'll face.

If nothing else, read a website on it.
http://www.stevemcconnell.com/rdenum.htm
or
http://www.stevemcconnell.com/rdmistak.htm

Project management is not only for the managers. Grab some basic books on the subject (hopefully based around software development) and have the coders read them.

If nothing else, it gives everyone a shared vocabulary for the situations and approaches that they'll face.

If nothing else, read a website on it.
http://www.stevemcconnell.com/rdenum.htm
or
http://www.stevemcconnell.com/rdmistak.htm

Microsoft just spent $9 billion and many years to create Vista, so it does not sound reasonable that some new alternative could just snap into existence overnight like that. IBM tried, and spent a huge amount of money developing OS/2 but could never keep up with Windows.

Is this a joke?

Or maybe it's just someone who doesn't understand that less buggy software is easier (cheaper/faster) to build than buggy software.

The first thing I'd recommend is to get the Software Project Survival Guide. It doesn't apply to all projects, of course, but it's an invaluable guide and source of best practices for team-based software development.

http://www.stevemcconnell.com/sg.htm

The second thing, of course, is to actually read it. (I'm still working on that part myself.)

The article seems to be equating IT with software engineering - especially when he linked "it's debatable whether IT qualifies as a profession" to a page on the professional status of software engineering.

Where I work most of our software engineers aren't in the IT department, and there are certainly a lot of IT people who don't routinely call their customers idiots, lusers, or clueless.

However, I am a UNIX sysadmin and freely admit that I willfully piss off my "customers". Yes, it's true. I deny requests that are against policies and procedures established by the business. The sad thing is that the customer is 99% of the time fully aware of the policy and are merely trying to circumvent it, often by trying the different sysadmins, especially the newer ones who are still learning.

Most often reason for me to deny a request? Failure to follow change control procedures and obtain the appropriate approvals from all stakeholders before requesting the change. Change control procedures aren't just put into place by IT - they are demanded by the business and for some systems are required by regulations. The second most often reason is that the request violates security policy or procedure.

Yet, when I deny such a request because proper procedure hasn't been followed, I get to hear about how "IT gets in the way and we could do this so much (better|faster|easier) by ourselves."

I also do evil things that inconvenience users such as requiring them to change their passwords four times a year. I personally make their life rough by setting the system to lock their account after three unsuccessful logins - and I do it on purpose. I make it so hard for the developers by not giving them accounts on the production systems, and I interfere with the ability of the QA teams to do their jobs by not giving them access to unscrubbed logs containing containing the personally identifiable information of real people using our online services.

Believe me, I've heard about what a jerk admin I am.

So what you're left with is not much of an idea of what is going on outside academia other than perhaps "really large programs." That is why everybody that I interviewed with coming out of school in the 90s asked if I had taken a projects class.

If I were to design a curriculum to get people ready for how things are after school, I'd make a two semester course requirement:

The first semester I would have the students go through a survey-type class where different types of methodologies were explained, along with the advantages and disadvantages of each, with an example of representative types of applications that used each method. Perhaps a telephone switch used with a Waterfall methodology. And go on from there. This would go up to whatever the latest fad was. This would also include the prerequisites for starting a project, which hopefully are common to all projects -- you would use something like the material from The Software Project Survival Guide. You'd also look at different maturity measurement methods, such as SEI CMMI levels. And then a dose of the real-world with mistakes that people make during software projects, such as excessive "tailoring" of the process, giving up the process during mid-iteration to code like mad, etc., and ways to get out of such software development mistakes.

You would also get taught concepts such as Configuration Management (with a survey of different tools, such as CVS, Subversion, ClearCase), unit- versus integration- versus system-testing and tools to perform each.

The second semester would be the actual project where you would use the appropriate methodology for the size, number of people, and time to work on the project. You would try to make it as realistic as possible, including requirements gathering with inadequate requirements, bad business contracts, interacting with QA for getting a test plan up and running, etc. Then halfway through the project you could have additional requirements added by the customer and see how to successfully manage such changes.

Another course or portion of a projects course would be doing what most of us end up doing anyway: modifying other people's code. This would also go over the different types of code modification: new features addition, optimizing code for better speed, user interface changes, etc. It would also survey different tools, such as debuggers and profilers. It would also look at the hows and whys of refactoring.

All of these are necessary to successful real-world software development, IMHO. Unless you go to an underfunded start-up ("OMG, why aren't you coding!!!), or you work at Google.

Without this, I think a lot of people are going into software development thinking it's all fun, with this rosy picture of working on original code, and thinking that testing what you do after it all works.

DT

I wonder...why is that, exactly? Why is Vista such a massive project? It's a serious question. I mean, it's not like they're building HAL-9000 here. It's an OS. A microcomputer OS. Which really, as far as I can tell, doesn't do a whole lot more than a bunch of other OSes that are on the market already. What does it do that's so much more complex, fundamentally, than what OS X does? Or Linux? Or any number of other OSes? Why, exactly, is it such a freaking huge project?

Consider the following links:

"By the time it was released, Microsoft Windows NT 3.0 consisted of 5.6 million lines of code spread across 40,000 source files. A complete build took as many as 19 hours on several machines, but the NT development team still managed to build every day (Zachary, 1994)." -- Best Practices

'There are no other software projects like this," Lucovsky said, "but the one thing that's remained constant [over the years] is how long it takes to build [Windows]. No matter which generation of the product, it takes 12 hours to compile and link the system." Even with the increase in processing horsepower over the years, Windows has grown to match, and the development process has become far more sophisticated, so that Microsoft does more code analysis as part of the daily build. "The CPUs in the build lab are pegged constantly for 12 hours," he said. "We've adapted the process since Windows 2000. Now, we decompose the source [code] tree into independent source trees, and use a new build environment. It's a multi-machine environment that lets us turn the crank faster. But because of all the new code analysis, it still takes 12 hours."' -- Windows 2003 Server, The Road to Gold

Now, take what that says into consideration. Effectively, Windows is one giant source tree. Even though they're able to decompress the source tree into a few sub-trees, you've got one giant source tree. That's a horribly bad thing. There's two main reasons for this.

One, by having everything in the same tree, programmers have a tendency to create all sorts of deep dependency issues in attempts to "speed up" the system. It's these sort of problems that push people against monolithic designs, as those "speed up"s tend also create all sorts of virtually untrackable bugs. It's one major reason that Xorg was split up into modular parts.

Two, by having everything in the same tree, it becomes incredibly difficult to make modifications and improvements in the design. This is partially due to the fact that compile times have a tendency to be dragged out as excessive linking has to be accomplished each compile. And it's partially due to the fact that monoliths are incredibly difficult to adequate comprehend. This latter part means that a person searching to make an addition ends up spending possibly hours trying to figure out just where the changes should be made. Those unwilling to devote the time to do the "right" thing end up just shoving a solution in as a hack and forcing it to run even when the run location is bad. And as we all know, hacks have a tendency to not be fixed. With Microsoft's anal-retentive backwards-compatability standard, this can lead to having to *maintain* such hacks because they become a standard part of the API for people.

Now, you might ask why Microsoft doesn't just divide up this large project into a collection of smaller projects. There's probably five main reasons for this. The first I've already touched on, such would almost certain break compatability. This comes down to the fact that when a hack is included, it almost always resides on the wrong side of what should be a clean break between two different interfaces. The result, then, is that the hack would require a stub across the break, and even with that in place, the timing change (which could involve a memory swap now that the main chunk of actual cod

Yeah, that is BS! Especially when you have Donald Knuth, Brian Kernighan and Ken Thompson on record in defense of goto when it's warranted. References: Knuth's "Structured Programming with GOTO" (link appears dead), Kernighan, and Ken Thompson: "If you want to go somewhere, goto is the best way to get there."

And then there was the famous "'GOTO Considered Harmful' Considered Harmful" by Frank Rubin, and a a decent section in Steve McConnell's Code Complete that takes an even-handed view.

Anyway, swinging carefully back on topic, it sounds like Mr. Goto's work is at the instruction level, not the C or Fortran or even really at the algorithmic level (except maybe tricks like tiling). I program in the embedded space, where getting as close to 100% efficiency is a continual challenge. I wonder if any of his techniques scale down...

--Joe

1. Set up a development process for projects that will be improved iteratively.
2. Start your next project.

Step 1 is a lot harder than it would appear. Check out Steve McConnell's websites and books http://www.stevemcconnell.com./

And in fact, that law was also quoted in Steve McConnell's "Rapid Development", published by Microsoft Press. They should know better.

• The Mythical Man-Month

• Code Complete
• Rapid Development

But the most important book is Software Project Survival Guide by the same author. This is exactly what you need. Get it and read from cover to cover. Repeat that once a year until the people manage can finish your quotes from it.

• The Mythical Man-Month

• Code Complete
• Rapid Development

But the most important book is Software Project Survival Guide by the same author. This is exactly what you need. Get it and read from cover to cover. Repeat that once a year until the people manage can finish your quotes from it.

Those are all very good books. You'll want them. And especially take note of Peopleware, it's often overlooked.

But there are two good ones missing:

• Rapid Development
  by Steve McConnell
• Agile Software Development with SCRUM
  by Ken Schwaber, Mike Beedle

I'd say you'd definitely want to read Rapid Devlopment before Code Complete. And the Scrum book will save you.

For instance, I have a web site that tracks my team progress against deadlines, lists what they are working on, major risks, etc. Set it up according to the suggestions in the Software Project Survival Guide but it applies to any kind of management.

Read, and follow the suggestions of, the One Minute Manager. Be sincere, I ignore a lot of the touch feely stuff, but the delegation, goal setting etc. is key and easy with this method. Use advanced management techniques later.

Neither of which would actually be a software engineer. Yes, even the CS grad is most likely not an engineer. There's a difference between science and engineering. The fact that so many "software engineers" are graduates of science programs goes a long way towards explaining why "software engineering" as a discipline is still such a mess.

For a good discussion of the differences between CS education and SE education see either David Parnas' excellent paper Software Engineering Programmes are not Computer Science Programmes, or Steve McConnell's comments on why software engineering is not the same as CS.

The phrase is not generally meant for customers. It's for developers, testers, and project managers: the entire development team. It has nothing to do with marketing. Yes a USER might become confused. A developer that has read the links posted and understands them will understand the difference.

Of course there should be a balance between development time and squashing bugs, and ZDSD takes that into account. Read the above links. Read Steve McConnell, Rapid Development, PP.69-71: a 95% defect-removed rate appears to be optimal from the perspective of schedule, effort, and user satisfaction. Removing defects EARLIER IN THE PROCESS is the goal, a goal which also reduces cost, user satisfaction, and schedule. Reworking a requirements defect which has made it to production costs 50 - 200 times that of reworking the problem DURING the requirements phase. There's hard data on this from 1988 and probably earlier: 60% of all defects exist at design time. So again, we're talking about DEFECTS, not "bugs". A wrong requirement isn't a "bug". The rate chosen will also depend on the application: a nuclear power plant should have a different defect rate than Joe Six-Pack's personal web page.

To make the point: the concept is aimed at those PRODUCING a product, not those CONSUMING it. Yes, those that use the term to sell to people who won't properly understand the term shouldn't do so. A DEVELOPER should understand its context in the SDLC.

Wait for Code Complete 2 -- should be out in June.

Really. The degree you want is a Bachelor's in Software Engineering. Yes, there is such a degree, even though not many schools offfer it yet, but take a look at that link and learn how such a degree with distinguish yourself from the next hotshot programmer.

BTW, Steve McConnell is the author of some of the more important books on software engineering, such as Code Complete (a new edition is coming in June) and others.

There are people besides Gates who might disagree with your opinion of goto. Read what Steve McConell has to say in his -balanced- portrait of goto: http://www.stevemcconnell.com/ccgoto.htm

Notice that one of goto's defenders (for appropriate circumstances) is none other than Don Knuth.

I generally avoid goto like the plauge... but sometimes it's the right tool for the job.

I cannot help with your first 2 questions, but the answer to your 3rd is yes.
See Business Case for Better Software Practices from Professional Software Development (2nd Edition of After the Gold Rush).

This issue has been around for awhile. I remember reading Yourdon's books on this topic:

Decline And Fall Of The American Programmer

and the sequel:

Rise & Resurrection of the American Programmer

To this list, I would add Steve McConnell's:

After the Gold Rush: Creating a True Profession of Software Engineering

and Cem Kaners:

Bad Software: What to Do When Software Fails

Considering this discussion, these books are worth reviewing.

In Yourdon's view, the response of American Programmers should be to develop better quality through better Software Engineering. As some of the Indian Software Houses are trying that approach, we need to respond.

McConnell would add the point that Software needs to become more of a real Engineering Discipline, complete with professional licensing.

In "Bad Software", Kaner advocates for better quality software and "software consumer rights". Some of these points can go into a "Software Building Code", something we also need to add in making IT more professiobal.

Just hire more people...

Two books that I've read come to mind that deal with this sort of "omg wtf 12 hour days stupid management" deal.

The first is "Death March Projects" by Edward Yourdon. The book deals with so-called Death March projects that everyone expects will end in failure (and similarly doomed situations). There are several sections on how to cope with situations like 12/7 work situations (as well as how to avoid them, but those passages might not be too useful at the moment). The book is interesting and (especially if you've never BEEN in a death march project) rather entertaining. Available at a local University library near you. Roughly 4 hours to skim through it.

The second is a book that should be on every programmer's bookshelf. I speak, of course, of "Code Complete" by Steve McConnell, the manual of 90s programming (when widescale 12/7 programming enforcements took place). In addition to much useful content about creating software, the last few sections deal with how to manage the product team, including help on how to deal with situations such as an enforced overtime. And yes, I know the book is published by Microsoft Press, so go ahead and post "ha-ha MS sux" and all that, thankyouverymuch now please sit down, because this is a GOOD book.

I highly recommend reading both these books, and keeping a copy of Code Complete handy. Now, as to when you'll find the TIME to read such things if you're working 12/7... all I can say is, I have no idea; I'm just a CS student, so I have plenty of time.

This Microsoft: article by Steve McConnell is interesting to read.

In its local area, Microsoft is known as "The Velvet Sweatshop," which suggests that, if anything, Microsoft might be doing too good a job of motivating its employees.

McConnel has a great book with a chapter about morale: Rapid Develpment

This Microsoft: article by Steve McConnell is interesting to read.

In its local area, Microsoft is known as "The Velvet Sweatshop," which suggests that, if anything, Microsoft might be doing too good a job of motivating its employees.

McConnel has a great book with a chapter about morale: Rapid Develpment

And people wonder why it is so hard to make money in the computer game industry...

Let me quote from the article:

"We're undeniably late and we know it. We've switched engines a couple of times, and we've started over a couple of times. We've made some mistakes, and we've learned from them.
--George Broussard, President, 3D Realms

The least they can do is hire a competent project manager to slap those ho's back on track.

Way I figure it, if they had 3 developers and one manager working full time for five years, they've already burned through close to two million dollars and have nothing to show for it. Hope they figure they can sell enough copies to *cough* at least break even. Do'o!

Rapid Development by Steve McConnell is an excellent book with case studies and descriptions of a variety of development cycles that you can use to get your projects through.

I'm guessing when you say that your main problems are bidding and software development, you mean:

Bidding is usually too low and doesn't cover costs, or is perceived by clients as too high and they don't bite. Unfortunately, there's not much you can do to control how a client responds to a bidding process. Ideally, you bid once you have a clear idea of all the work that will go into the project; if you can display just how much work it will be to the client (all the different use cases, all the different interfaces that will be involved, all the testing and re-testing that will be required) they may be more understanding of your bid -- they won't feel they're being ripped off.

In the software development process, there are so many things that can go wrong. The first is that it takes too much time. (Or is over budget, but from my experience budget *is* time--a piece of software is purchased to reduce time, or additional people are hired to reduce time.) This generally occurs because there isn't a clear understanding of the scope of the project in the beginning. The other cause for taking too long is slow response from the customer on its needs.

The solution to this can be creating a non-working prototype that shows every screen and page that the program will use. This doesn't mean creating 26,000 screens if there are 26,000 records in the program. You create screens for one or two sample records (say, one for each major "condition", such as "Approved", "Unapproved", "Expired", etc.). You also create a screen for every entry form and a sample of each report that the program will have.

You show this to your customer and get their approval. Make sure that each form matches all of the fields that they want. Ask them if there is any information they would want to know that isn't on any of the reports or forms. Then you say to your customer, "Is there anything else this program needs?" If they say no, you say, "Okay, judging by x forms, y reports, and z interactive screens, we estimate that it will take at least n months and no more than m months, with a probable time of p months."

The customer is happy because you're giving them what appears (and is) a much more firm time estimate than something off the top of your head, and they understand the complexity and process that will go into the development.

The other advantage to this process is that it kills the other software development dragon: developing the wrong software (it doesn't do what the customer wants, and offers features the customer doesn't need). By developing a prototype of all the screens, you can do a "sanity check" on the software to make sure you have the same understanding of the final project as your client does. Also, once the prototype is built, you hopefully will not have any features that need to be added on mid-project.

I hope these tips work for you. They sure have helped me out. Keep in mind I've only used these for web development, but I'm fairly confident they will work equally well in other areas.

Don't talk to management, ever, for any reason, until you read some Steve McConnell, such as Rapid Application Development: Taming Wild Software Schedules. Also, check out some of the stuff from SEI, such as Investment Analysis of Software Assets for Product Lines. If you're going to commit millions of dollars of your employer's money, you'd better have some research and data to back it up.