The future of programming

[NecrosIhsan]

...it irks me very much when people dismiss adherence to good coding practices as "elitism" ...

I think I know why people consider this 'elitism'. Coders have their own methods, and someone telling them that they're 'coding wrong' is rather insulting to them, especially if their way has been effective and/or profitable in the past. So who decides what is 'good coding practice'?

[Moneo]

CHA0S: On your subject of "breaking things down into small steps." In practice, that's what's done. One programmer cannot undertake a large project by himself. However, each of the contributing programmers must have very good undertanding of the entire system, even though he is only going to code a small part. A catcher on a baseball team only plays one position, but he better understand what's going on in all the other positions.

NECRO: Regarding "good coding practice." Many have tried to decide this in the past. In my years of experience in many major U.S. companies, I have seen many attempts at publishing and enforcing coding standards, and have never seen one of these succeed. The best I've seen is when your boss is also a programmer and he tells you how he wants the code to look. Him being your boss responsible for your paycheck, you listen up.

What I meant by standards was in a more general sense, such as project management standards, like SDLC (Software Development Life Cycle). Follow the intent and essence of a set of standards like this, but don't try to do every single nitpick step or you'll never complete your project.

Then there are general programming guiidlines like defining all you variables before assigning them, writing modular code, avoid using gotos, commenting main processes and tricky code, etc. These kinds of "standards" are easy to conform to and help a great deal in the testing and maintenance of the programs.

*****

[Anonymous]

I would have to say that the method that results in the least amount of net "wasted time" is the best coding practice.

[Deleter]

Yeah, and on a team, that probably will not be one coder's style, as the other people would have to adapt to it and that wastes time.

[Moneo]

The following is an article by an old friend of mine, George Trimble who is one of the giants of the computer industry. Please read it so that you can appreciate that coding practices and coding styles have nothing to do with wasted time or successful completion of a programming project.

Regards,
Moneo

**************************************************
Development WorkBook (DWB)
by George R. Trimble, Jr.

Over the years I have developed a Management Control/Documentation technique that has proven to be very useful and effective. I call it the Development WorkBook. It started out as nothing but a sheet of paper with the project name, the date, the programmer's name, and a title. The pages were placed in a three ring binder and available to all of the people on the project. It has evolved into a highly structured organization of all of the information generated and required to manage a project.

With the advent of networks, the DWB can now reside on a server or other commonly available data file. The principle is that all information pertinent to a project is contained somewhere in the DWB. This includes not only requirements, design specifications, detailed program designs, test plans and procedures but also administrative material, such as schedules, hardware configurations, user manuals at various stages of development, and contractual or other reference documents, either directly or by reference, as well as notes and memos.

There is a spot for everything pertinent to the project, and everything pertinent should be somewhere in the workbook. The organization, once one becomes familiar with it, enables the user to locate material fairly quickly. The DWB enhances project management and control by increasing visibility. For example, if a program design specification is due on a certain date and the design specification is not in the DWB, you know that part of the project is late. If the specification is there on time, it can be determined if it is adequate or whether potential problems exist for that particular item. The DWB facilitates program reviews, program walk-throughs, and finding inconsistencies or holes in the system's design and implementation.

I strongly feel that one reason software development projects are late and overrun their budgets so often is a lack of control. Yet programmers vehemently resist the idea of documenting their programs, want to start writing code on day 2 of the project, and promise to document when they are done, but never do. Managers see this approach as non-productive (code is not being written), taking extra time, and costing more money. Someone once asked me, on a $300,000 project, what it would cost if we didn't do all of this "paper work." My answer was, "It will cost at least $600,000 and won't be done on time." If you don't do it right the first time, you will have to do it over or will spend lots of time and money on program maintenance.

It doesn't have to be done using the DWB. That is just one structured means of controlling a project. But it is essential that you plan, document, review, document, revise, document, then start programming. In my opinion, 45% to 50% of a project's development duration should be spent in planning, designing and documenting. Not a single line of code should be written until you know exactly what you are doing. At that point coding is largely mechanical and trivial.

****************************************************

[wallace]

I would say that "coding right" is a delicate balance of minimizing time and space. I think things are starting to make way to big of a footprint.

I have a question: Why has both Windows XP and Mac OSX minimum requirements gone from 128MB RAM to 512MB? What have they added to the OSs since their original releases that takes up that much space? Other programs bug me too because of their footprints on the system. .NET, Eclipse, and XCode come to mind.

[Deleter]

@Moneo. While I think that is an excellant strategy for a definite project, I am not sure how well it tranlates to open source, where not only is there no schedule (its usually hobbyists, who can't make such deadlines), but the program itself doesn't necessarily have a definite shape. What I mean is, that the program may be redefined or redesigned or a new functionality added, which is the whole point of open source.

I suppose though there is still something to be said for good designing and documenting as you go rather than later. I'll keep that in mind on my own projects. I definitely am the "program on day 2" type of guy at this point. Nevertheless, thank you for posting that, it was pretty informative.

[na_th_an]

I would say that "coding right" is a delicate balance of minimizing time and space. I think things are starting to make way to big of a footprint.

I have a question: Why has both Windows XP and Mac OSX minimum requirements gone from 128MB RAM to 512MB? What have they added to the OSs since their original releases that takes up that much space? Other programs bug me too because of their footprints on the system. .NET, Eclipse, and XCode come to mind.

You know, MSDOS ran in 256K. That's called... technical advance. That an OS needs 512Mb doesn't mean that it will take all that memory. It means that it will "move" better within such amount of memory. A lot of support for new devices has been introduced, and most of them can be plugged/unplugged "in hot" - lots of stuff to keep track, etcetera. Then all that eye-candy. In Windows 95, when you pulled a menu or moved a window there was no animation: the menu was drawn directly and you just got the frame displayed when moving a window. Such things, plus skins, big backgrounds, animated buttons, etcetera take system memory.

Anyway, latest Windows and MacOS versions are designed for computers you buy brand-new TODAY, not your past relics now every computer has a minimum of 512Mb, so it's not a problem.

That's why Windows XP performs worse than Windows 2000 with just 128Mb, but it outperforms it with more than 256.

[marzecTM]

[quote="cha0s"] So who decides what is 'good coding practice'?

the big team in a company that gets $$$ for code that you probably never worked in :p

[Anonymous]

heyyy.... misquote! =( lol

but marzec is one of the people i know will agree with me about good coding practice. In fact, he taught me quite a few things I know now, and I wouldn't be as good of a coder if I didn't learn from him, and the refernces he generously gave me.

and of course, documentation is absolutely KEY when working with a team. Even on my pet project, I've learned the virtue of it (a bit late, but I made it, and I also started it before I knew ANYTHING about good practice, and refactored it many times, and pulled it out of that hole...)

this i guess is one of those things that can never really be concluded, as some people see it as opinion.

However, there have been people that have been studying/working with projects larger than we have touched, for the most part. and it's definitely a good idea to learn from them.