Same goes for other configuration or settings files. For instance, connection strings in web.config files (connection string file:web.config), Movable Type passwords (file:mt-db-pass.cgi), keygen name serial, backdoor passwords (backdoor.*password), MySQL root passwords (file:config.inc.php “MySQL password” root, etc.

Of course, one could search for code vulerable to cross-site scripting, SQL Injection (lang:php mysql_query\(.*\$_(GET|POST|COOKIE|REQUEST).*\)), remote code execution (lang:php (include|require)\s*(\(|\s).*\$_(GET|POST)), header injection, and on and on.

Spammers can cull email addresses from code with a simple code search as well ([a-z]*@[a-z]*.com)

So what have we learned?

• Do not put passwords in public code, including zipped code archives.
• Be more diligent to protect against SQL Injection and similar exploits. I.e. do not trust user input of any sort.
• Do not put email addresses in public code.
• In general, keep your eyes and ears open for security exploits and protect against them.

We can’t be perfect, but we ought to try.

Seen here, here, and here.

It is often tough for developers to detach themselves from their code. Code reviews are feared because they essentially invite criticism, but if such criticism is given in a cooperative manner, it is good for all involved. Participants in a code review should go into it hoping to learn and maybe teach at the same time.

However, it is important to keep in mind that you can only get a handle on your ego and learn to respect others’ egos. Pride in one’s craft is a great motivating factor for quality in any trade and should be fostered. Sharing be used to improve each individual’s work, not to strip them of their technical “ownership” of a component.

Builder.com has condensed some rules for accepting Weinberg’s concepts of egoless programming in The Ten Commandments of Egoless Programming. (Via Coding Horror.)

One Great Programmer?
Tom Evslin proposes that one great programmer is worth those fifty good programmers working on Hoozit and Whatsit.

Cutting to the chase, he’s grabbed the pivot point of competing problems; a great programmer can be far more valuable than fifty good programmers, particularly if you need a slick, efficient system built quickly and in a sustainable manner; and a great programmer can be far less valuable than fifty good programmers if you need a large mess of code written quickly. Sometimes a business needs a large mess of code completed quickly and the only thing that will fit that bill is a decent architect and a bunch of decent coders. And money, but that’s beside the point.

Evslin does make some good points, though. His notion of fixing a budget but removing individual salary caps is interesting, but I think upper-management school is taught that engineers are interchangable, so this would not make any sense to them. More important, he stresses that throwing additional people at a problem adds additional complexities, additional interface inconsistencies, additional meetings — all sorts of kruft that goes away if you have just one “superstar” programmer.

Superstar Problems
But problems abound with that one superstar programmer. Businesses do not operate in the ideal vacuum of programmer space. They are ill-advised to bow at the feet of a single engineer with a well-earned ego. What if he leaves? What if he takes his ideas to build a competing business? How can you stop him? Threaten him? Will that work or will it buy yourself more trouble?

Coping with Really Good Employees
A better solution is to hire a couple really good architects, several really good programmers and test engineers, and if you need them, a bunch of good programmers. Then make sure you hire or train and promote great managers. Poor schedules are most often due to unreasonable demands from management or pressure from sales folk. Poor designs are due to little or no coordinated system architecture and design. Poor programming is due to laziness or even bad morale.

What’s missing from the process is discipline. Plan carefully. Permit realistic sizings and set schedules after you know how long it will take to build the thing. Keep some pressure to deliver, but allow for relaxed design and code reviews that involve all available engineers. Good engineers cut corners when quality isn’t encouraged, or they’re run ragged and aren’t valued.

Programmers can dream of being that one superstar with the superstar salary, and they might find a place in a small shop. For most companies building great Hoozits and Whatsits is a matter of hiring good people for the right jobs, allowing them to put the cart behind the horse, then respecting and valuing them and their work.

A Retooling Project
Nevertheless, it is an interesting article and got me thinking about a side project that has me rewriting and updating (in C# and some SQL) much of an old system, a mix of ASP, VB DLLs, C++ DLLs, and SQL. (The VB and SQL are getting the overhaul.) I am finding maybe 35% of members, columns, functions, methods, and stored procedures are not used. At all. Some have me scratching my head, wondering how a GetRequest differs from a RetrieveRequest — turns out they differ only in the spelling of the function and in who calls them, but otherwise they’re twins, as are their corresponding stored procs. Neither is strictly dead code, but we certainly don’t need two of them.

The rub is that it is primarly my code. It was a project that was driven to market too fast by the sales force. They held development hostage, claiming they could not sell other products unless they could offer this “bonus” product as well. Well, the product made it to market on-time and fully-functional — or, it appears, extra-functional. But it is awfully complex and I was much greener in this environment at the time, leading to some unforseen issues. Since its introduction the product has worked well except for some ill-handled conditions that I patched over manually, behind-the-sceens.

This behind-the-sceens patching occurred whenever a certain error condition was met — an error condition that has been more prevalent lately, leading to a lot of behind-the-sceens scrambling. In the past, management would not commit any resources to fix the problems since customers were not complaining, but we’re now in a position to allocate time to clean things up. Plus, a retooling allows us to leverage some new technology and some old lessons.

Lessons Learned
It has me thinking about lessons learned in the life cycle (so far) of this product.

1. As always, don’t let sales drive development schedules too hard — everyone knows this rule but it still happens. Continue to educate them on the downsides to driving things too fast. Tip: Sales people have very short attention spans and want a few quick, punchy points to take away. Another tip: if developers are driven too hard up front, they often are too burnt out to go back and “make it right” after the fact, not to mention convincing management that it will be worth the time when other things are waiting for attention.
2. Wherever possible, lean towards simple designs; complexity can get to a point where it starts to breed.
3. Without getting at-odds with simplicity, anticipate future requirements and create flexible systems to handle them.
4. Triple-check your work to eliminate duplicate or unused code. The point above about anticipating the future does not mean write code that sits dormant. Code for today’s possibilities.
5. Try to allow time to re-organize and re-factor throughout the project; you are bound to learn something once you get started.
6. Take care to handle unanticipated error conditions along with the obvious ones. Carefully think through the side-effects of failures. For example, would the system be left in an indeterminate state? This sounds obvious, but it does not go without saying.
7. Include monitoring and administration in your design. It is sickening to find out that a previously-reliable system hasn’t been working for a week and you have to go back and reconstruct data out of log files.
8. Document lightly as you code, then heavily when done. The heavy documentation stage will sometimes catch bugs before customers do.

Most of the above points I have read before, but for some reason they often get brushed to the curb in the rush to market. They really all boil down to one rule: slow down, look around, and walk with care.