Slashdot Mirror

← Back to Stories (view on slashdot.org)

Making Software Suck Less, Pt. II

Posted by timothy on from the he-ain't-heavy-he's-my-code-gnome! dept.

Not long ago, chromatic wrote about one aspect of the quest to create software that doesn't suck. This time he's back with a proposal that's simultaneously practical and idealistic. Namely: If you as a whiz at a certain language or other aspect of programming want the world of programming to be better, you can help other people become programmers, or better programmers, with well-considered instruction. I hope someone in the Computer Science department at a high school near chromatic gives him a call, because he outlines here something more important than a "learn to program" curriculum.

Making Software Suck Less, Pt. II Coders Code Whether You Like It Or Not The insidious thing about Free software, the really subversive part, is that it takes so little to start writing it. Anyone with a few tools, spare time, and the wherewithall to start hacking can. Witness the long listings of low-version-number IM clients and MP3 players on software announcement sites. People like to code.

Every new project represents a coder who wants to write free software, but chooses not to work with an existing project for whatever reason. How many more people would like to contribute but don't know where to start? Hundreds, even thousands of free software projects could use another coder, some testers, and someone -- anyone -- offering suggestions and attaboys. For each veteran programmer, battle-hardened and wizened by experience, a dozen novices spend evenings honing their skills.

Mentoring Beginning Programmers The obvious solution is to match availability with opportunity and enthusiasm with experience. The free software community can produce better programmers by giving new recruits mentors to emulate. It offers the possibility for programmers to learn by improving existing projects, instead of reinventing wheels. This doesn't require expert programmers. It takes people with practical experience, patience, and the willingness to invest time in another person's education.

Though this article draws from experience with free software, there's no reason similar procedures could not succeed in commercial settings. Computer science sophmores (and higher) would benefit from internship programs organized similarly.

The Usual Suspects Candidates for mentoring exhibit a combination of at least three different characteristics. These are expressable as three different archetypes: the self-taught hacker, the computer science student, and the new programmer. Individual personalities and experiences also come into play. These are gross generalizations, but serve the purpose of categorizing the types of information to present.

Self taught hackers learn by experimentation. They dissect existing code, copying and modifying implementations. Their technique gradually coalesces from dominant influences. Hackers often amass a library to improve their education. One danger for members of this class is that they may pick up questionable practices from questionable code ("cargo cult programming").

Computer science students learn theory and are expected to teach themselves various languages and implementations. (This category does not cover degrees like 'information services.') The education covers ideal solutions, often emphasising aesthetics and mathematical perfection. Students may not be exposed to practical issues in specific languages and techniques, focusing on working code.

New learners enter the world of coding with a strong sense of need. Management might pick a hapless victim for a project of undefined scope. A home user may just wish to do more with her computer. People in this category often don't know where to turn. They may not all grow into dedicated coders, but can fend for themselves with some guidance and direction.

Besides these categories, recruits may include artists, musicians, writers, and testers. Though direct mentoring from programmers may not awaken nascent coding abilities, these folks are certainly welcome. Even experienced programmers new to the idea of free software or to a class of software can benefit from directed guidance. (Many people in this position just need to see how to contribute.)

Course Requirements Mentoring must provide examples of secure, clean, and idiomatic programming. It should also include issues related to the practice of programming -- time management, software design, tools and classes of tools, and project leadership. Additionally, mentors should introduce their students to a network of peers, whether on IRC, through mailing lists, or in user groups.

Benefits of Mentoring Besides the warm glow of humanitarianism, being a mentor bestows personal benefits. Your project immediately gains an extra set of hands and eyes. Each new person brings a fresh point of view, with different expectations and stories for the code and unique experiences. At first, the additional overhead of explaining will slow progress; wise mentors invest slightly more time to turn these lessons into improved documentation and tutorials. After a short period of training, the project gains another person familiar with internals.

The discipline of explaining your personal technique, especially the more reflexive elements of your coding style, will also improve your skills. ("Why do I do it that way?") Describing system architecture and complex codes in words forces you to organize your thoughts. It can even clarify future design decisions. Your student must be free to ask questions and to challenge your assumptions. Either strengthen your arguments or discover a better alternative.

Leaving the Nest If you've mentored correctly, at some point you'll have taught every lesson you can. The student will have met the right people and will have tasted the fruit of hard work. Your example will still teach him, but he will make his own way. You will be peers.

Prepare for this from the beginning. Allow the student to lead subprojects with the freedom to make mistakes but the supervision to produce working results. Provide opportunities for personal growth. Your job is to remove obstacles from the path of enlightenment. Writing good software is hard, but teaching people to contribute is very rewarding.

7 of 209 comments (clear)

  1. Hey CmdrTaco! by Shoeboy · · Score: 5

    Rob,

    I'm willing to be you mentor.

    I've seen the database structure for slashcode. I know you need some help. I'm willing to offer it.

    Our first lesson will be on denormalization for better performance. I'll try to be a patient and dilligent instructor, but the fact that you fetch the sig from the users table for every comment rather than storing it in the comments table may render that impossible. It's quite possible that I may have to beat you. Particularly when I look at some of the 3 and 4 tabe joins you do for really common operations. I know Hope College isn't much of a school, but surely at some point they explained that joins were slower than single table selects, right?

    Anyway, I'm more than willing to help you with your database design and implementation problems.
    Drop me an email.

    --Shoeboy

    1. Re:Hey CmdrTaco! by Shoeboy · · Score: 5

      A select is slowed down by joins, true, but its also slowed down by the size of your tables.
      That's more true for the length of your table then the width. As long as you're doing index scans rather than table scans, width isn't all that important. In fact, on systems that support page level locking but not row level locking, it's sometimes in your interest to widen columns.

      The whole purpose of normalization is to reduce the size of your database by eliminating redundant data. Reducing the size of the data searched will then speed up the selects.

      But (assuming that your database system uses b-trees to store and index the data) it won't speed index searches by much. And if you're doing something besides an index search on a large table, stop.

      For example, if you are an online music store and you have 250,000 music titles in your database, but the vast majority of those titles comes from 7 different record companies, it doesn't make a whole lot of sense to repeat the record company name in each title row. I would join the little table to the big table and index the record company id in the title table itself.
      Actually, having a record company id is redundant data. Using the name as the primary key is the proper method. ID's are actually non-relational. It all depends on how you query your database though. Data warehousing schemas and oltp schemas are very different beasts.

      I think slashdots problems are more related to mySQL's locking mechanisms. I have to deal with this sort of thing myself. IMHO, if you have an online database at all, you should completely separate the "read" database from the "update" database. In other words /. should have all the comments posted to another database and implement a once-per-minute table swap with the table used to display comments.

      Yeah, I've been made aware of this. I took a look through the MySQL manual, and I'm shocked that people describe it as a real database. It's barely more advanced than Access. I personally recommend Microsoft SQL server for this sort of application. It's simple, fast, full featured, highly tunable, quite stable (versions 7.0 and above, 6.5 and below is a stability nightmare) and scales very well up to 8 processors. On commodity intel hardware, it's the fastest database there is. (numa machines don't count) Once you outgrow the capacity of a 8-way proliant, it's time for DB2 or Oracle.

      It's a pity the free databases all suck so much. PostgresSQL has actually improved a lot, but the pricey overhead for new connections makes it unsuitable for client-server environments.

      --Shoeboy

    2. Re:Hey CmdrTaco! by Shoeboy · · Score: 5

      Hi,
      Your comment on denormalization demonstrates a lack of real world experience. Denormalization on databases where reads massively outnumber writes (which is slashdot) is a very useful thing.
      As far as making it difficult to make future modifications goes, this is complete B.S. As long as you encapsulate your data retrieval and manipulation through stored procedures (which slashcode doesn't do) all changes to the database schema are easy to make and very few modifications to front end or middleware code are ever required.
      The simple fact is that no perfomance critical system should ever run in 3rd normal form. Period.
      --Shoeboy

  2. Don't teach them to program. by Black+Parrot · · Score: 5

    Don't teach them to program at all -- teach them to solve problems. After you have a sensible solution strategy, expressing it in the syntax of a given programming language is trivial (boring) work.

    The problem that I see over and over and over again, among both students and "professionals", is that they sit down and start throwing code at a problem without knowing a solution strategy for that problem. And for many of these people, if you try using the Socratic method to bring out their solution strategy you'll find that they not only don't know what strategy they're trying to encode, but that they also don't even want to talk about strategies -- they want to talk about the details of the incorrect code they've already written.

    I'm not against hacking, and I certainly don't think every program anyone writes needs to be supported by an engineering discipline, but I do feel, very strongly, that people need to think of programming languages as a tool for expressing a solution to a problem, not as being the solution itself.

    --

    --
    Sheesh, evil *and* a jerk. -- Jade
  3. My own efforts to help other programmers by goingware · · Score: 5
    First, my effort to improve the quality of free software can be found at the Linux Quality Database. While the database hasn't started being written yet, I have started writing articles on the top of quality assurance and writing better free software. The first such article actually to be posted is Using Test Suites to Validate the Linux Kernel.

    For quite some time before that I have been writing GoingWare's Bag of Programming Tricks, a collection of articles on the business and practice of programming. Of most interest in learning how to program well would be:

    I worked on an article on C++ programming style that is not done yet, and has some errors in it. But I'll post the URL here with the understanding that you're to take is as a preview and not gospel truth:

    Finally, if you program in C or C++, you need to be using one of the following tools, appropriate to your development system and platform:

    If you use Java, you don't have to worry about dangling pointers, but you do have to worry about memory leaks (quiz: why do you in a garbage collected language?), deadlocks and so on. For that we have:

    Don't let another day pass without availing yourself of one of these tools. I know most aren't Free Software and some are very expensive. I want to tell you that the money I spent on Spotlight is some of the best money I have spent on anything in my life. I wouldn't dream of shipping a Mac application to my clients unless it tested completely cleanly under Spotlight; on the other hand, the first time I'm given a client's code to work on, Spotlight usually reveals a multitude of sins.


    Mike

    --
    -- Could you use my software consulting serv
  4. The Way of the Bard by Ricdude · · Score: 5

    A more applicable model might be similar to the way of the bard:

    Seven years learning
    Seven years playing
    Seven years teaching
    Repeat.

    The idea is that the would-be bard spends some period of time under the apprenticeship of one learned in the art. After acquiring some basic skills (melody, harmony, scales, etc.), and some examples of how to combine those skills (a repertoire of songs), the bard is then sent off to earn a living in the world. While doing so, the bard experiments with new ideas, merging them with the body of knowledge acquired from the master. After some time, the bard takes on apprentices, and shows them what they've learned from their master, and from their own experimentation.

    All too often, what's lacking in the free software world of half finished IMs and mp3 front ends, is the "combinations" of those skills. A lot of these programmers barely understand pointers and event driven programming, yet they're building full GUI programs as a method of learning more about how to program. Frequently, they bite off more than they can chew...

    --
    How's my programming? Call 1-800-DEV-NULL
  5. The problem with bad code by Faizdog · · Score: 5

    Is partly due to the inexperience/naiveness of the coders. But another factor IMHO that i've noticed in my experience has been big is simply human laziness. So many coders I know don't document, "can't be bothered to", they just write code that works, but don't worry about "elegant," algorithimically well thought out code. You can never just sit down and begin to code. And please don't tell me you can, I can just sit down and crank out a buncha programs too, but I mean well thought out plans. ( I dont' mean the BS stuff like Requirement's Engineering, Software Architecture, etc. although that stuff is sometimes useful), but just to sit down and think about what you wanna do and what's the most efficient way to do it.

    I'm not trying to be troll at all, so please don't think that. I'm just saying something that I've noticed. Plus I can't emphasize the importance of documentation. Currently I'm expanding upon a project that has a few thousand lines of code, and it's hardly documented. Hacking the code and trying to figure out what it's doing is tedious. Please document, it doesn't mean you are a bad programmer, actually means you are a good one.

    --
    -"Those who fought today will die tommorow."-