Slashdot Log In
Making Software Suck Less, Pt. II
from the he-ain't-heavy-he's-my-code-gnome! dept.
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.
Hey CmdrTaco! (Score:5)
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
How to use a debugger (Score:3)
I know when I started out, I rarely used a debugger when coding. I'd print out hard copies of my code, go over it with a pen, show it to others, but never touch a debugger. I know many professional programmers who also don't know the value of a good debugger.
My point is simple: teach aspiring programmers that no one can code perfectly, and show them how to debug their code appropriately. gdb is fine. ddd is better for beginners. There are other debuggers for other languages. I have no clue what can be used under windows or on a macintosh, but I'm sure there are good debuggers for them too.
One of the tenets of being a good programmer is writing solid code and knowing it's limitiations. Stress testing extreme conditions, and not being afraid of sanity checks. I've seen professional apps die from OBOBs (off by one bugs), come on guys, that should never happen, it's so easy to test for.
I know I've been babbling, so this is my last point. Teach people that just because a program compiles and runs without crashing, doesn't mean it always will.
---
Re:Suck Less (Score:4)
Except that tons of software is written as a kind of modern day duel. Why else would someone write a message board when ten already exist? To scratch an itch? Partially, but that only explains why they write it, not why they gift it. They gift it in order to win the acclaim of their peers.
In order to win said acclaim you must be current. The deadlines are therefore sometimes much more onerous because they are less tangible. More like a nightmare where you are terrified and running, but you don't necessarily know from what instead of a deadling where you are running, but it's only because your boss said so and he has no spine, no brain and no power. The worst he can do is fire you and then you'll just go somewhere else for more money.
--
Suck Less (Score:3)
And software is NEVER finished.
Re:Suggestions for better software (Score:3)
Mozilla is A good web browser, not spectacular but decent. It is a spectacular architecture. the ability to write code for many different platforms, to expose that code to scripting languages so relative neophytes can code applications is extremely powerful.
A brief explanation of XUL/XPCOM/JavaScript:
Most of mozilla's core class's are built in XPCOM objects. Certain methods of these objects can be exported as scriptable, meaning they can be run from javascript code.
XUL is a layout language, similiar to HTML, that uses CSS to define it's appearence. Javascript can be embeded in XUL.
The result is an architecture that allows anyone to creat an application (chrome) as long as they can learn javascript and XUL. Heavy lifting can still be done in C++ behind the scenes and then exposed to Javascript. Dev time (once you get past the sizeable learning curve) is small. The resultant apps are cross platform and fully skinnable (because they're appearance is defined in stylesheets).
Everyone should check out www.mozilla.org and learn about this. It's a much better rapid development enviornment than VB, and it's cross platform, and open source.
I sound like a groupie, but mozilla is a beautiful thing....
Writing good software is impossible... (Score:3)
There are already different methodologies to enhance the quality of the work like Rational Unified Process or Extreme Programming which correspond to different project scales. Mentoring is very good if good techies were no so contemptful with junior programmers. None of these techniques will be enough to counterweigh the human factor though. This is why I believe that writing good software all the time is impossible.
Also, it is a complete misconception that good software is only a question of technique! A good software is a software which is widely used and that people are happy with. Customers, programmers, managers and marketing people are people before anything. And this is why I strongly believe that good software is much more a question of people and not of methodologies.
Look, for the biggest majority of the users, Microsoft Office is a very good product. For the geeks community, Linux is a good software. The notion of "good" is sooo variable...
Don't teach them to program. (Score:5)
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.
--
My own efforts to help other programmers (Score:5)
For quite some time before that I have been writing GoingWare's Bag of Programming Tricks [goingware.com], a collection of articles on the business and practice of programming. Of most interest in learning how to program well would be:
- Study Fundamentals Not Tools APIs or OSes [goingware.com]
- Properly managing memory returned by transcode() in the Xerces library [goingware.com] (while about an obscure problem, it illustrates more general principles in a useful way)
-
Secrets of the Debug Meisters: MacsBug Tips and Tricks [goingware.com] (MacsBug is a Mac OS assembly debugger)
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:-
Pointers, References and Values [goingware.com] - Passing Parameters, Returning Results and Storing Member Variables, with Musings on Good C++ Style
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:-
Bounded Pointers for GCC [gnu.org]
- Spotlight [onyx-tech.com] for Mac OS PowerPC
- BoundsChecker [numega.com] for Windows
- Purify [rational.com] for Windows and Unix (but I think it doesn't support Linux)
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:- OptimizeIt [optimizeit.com]
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 [goingware.com]
But that's not FUN (Score:3)
One simple "trick" for not sucking (Score:4)
There is one simple thing you can do to make your code a lot better. It takes a bit of discipline, but once you do it for a while, it becomes second nature. It is this: whenever you write new code, make sure that you walk through every new line with a debugger. That's it.
At first blush, this seems kind of like a "duh" sort of step. After all, most people run their code through a debugger to check it. The key to it, though is the phrase "every line". Put breakpoints in every branch of the code you write. When you get into that branch, remove the breakpoint. When you think you are done, check for any breakpoints that are left. I was extremely surprised the first time I did this. I thought I had been thourough, but I hadn't checked three different branches. And there were bugs in two of them.
What I have learned after doing this for a number of years is that programmers pay more attention to the important part of a loop or branch and ignore the fringe cases. What ends up happening, then, is that the fringe cases contain a proportinally large number of the bugs. Worse, because they are fringe cases, they don't happen often, leading to bugs that are hard to reproduce.
Hey Instructors/Professors! (Score:3)
If you take this route you'll be rewarded and they will also as their project will live on instead of being part of the academic waste heap.
I also had my eyes opened- most of my students work in the "industry" but maybe 10% of them are aware of open source or what Linux, BSD et al are all about. If nothing else, you can use your classroom to spread the good word.
Justin
Re:Suggestions for better software (Score:4)
I'm a software tester by trade, and I code in my spare time. There are some cardinal sins that any peice of software can commit. They tend to be:
- Not having a clear set of features that you want in your code for at least version 1.0
- Not writing proper specs before any code is written
- Not having testers, or having testers and not listening to them
- Not having a defined roadmap or plan. At a minimum, this should cover the planing, and upto the second build of your software
Now on smaller projects, it's usually fine to sit down and start coding. With larger projects, you're going to be royally screwed about 50% ofthe way through your project, when you find you'll have to re-design part of your project to add functionality you didn't know you needed.If you don't have testers (And no, outside of unit testing, the coder cannot teste their own code properly!) your software will be full of bugs you just don't know are there, until your users start using the software under normal conditions. You'll then find you need to recode large parts of your software to fix even small bugs.
Release early, release often, is good provided you have proper controls in place before your first release!
Re:Suggestions for better software (Score:4)
The problem that you speak of is not new at all, and is definitly not confined to the realms of computer programming. When it comes right down to it, nobody wants to do the dirty work that is required to get a project done (i.e. bug squashing, documentation, general project managements) , they would rather go out and do the new and fun stuff (which in this case is adding new features).
This is just a fundamental flaw in human nature. People want to get all the glory and credit and nobody wants to do the background work that is required to make something actually work. Look at politics... everybody wants to be president, nobody wants to be his aides that actually run around and get the shit done (well, some people do, but most don't).
This was also a problem in ancient Rome, when you actually look at it. Everything used to be paid for by donations from the rich folk. However, everyone wanted their money to pay for something big and wonderful that everybody loved (such as theathers and circuses, etc), but nobody wanted to pay for the smaller bits of infrastructure that held everything together, as they wouldn't be remembered eternally if they gave money for the roads to be resurfaced or for general maintenance of the aquaducts.
Its the same thing with programming. Nobody thinks they'll get any credit for the bug fixes that they work out that makes the product actually work, they want to be known for the feature which they implemented (even if nobody actually needs it or wants it in any way).
I Was an Apprentice (Score:3)
I joined a team of 4 other programmers that were under tight deadlines to rewrite a medium-sized database and reporting system. Despite the time pressure, the lead programmer/architect made me do a several month long apprenticeship under him, where all my code was reviewed by him before released. All the programmers that joined the company, no matter their experience level, had to do one also. It made me a better programmer, and it had the side effect of forcing a common style on the entire programming staff, easing maintenance. As programming is essentially a craft, an apprenticeship is a good way to learn from a master. Just make sure you apprentice from a master and not a poseur.
The Way of the Bard (Score:5)
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...
Some software has to suck... (Score:4)
Re:Hey CmdrTaco! (Score:5)
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
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
Suggestions for better software (Score:4)
Have you tried to use Mozilla lately. It's loaded with bloat and crappy features I'd never want to use, but when it comes down to it, Mozilla is absolutely horrible as a web browser. When the Mozilla project was begun, I thought that it was an noble idea, and was eager to start contributing code, but I soon realized that human nature goes against the open source model by seeking out self gratification and promotion, often against the benefit of the group as a whole. This is an inherent flaw in the open-source philosophy. Everyone is seeking their own selfish gratification in being recognized for adding a new feature to a program, but no one is willing to try and make the existing features work properly.
I'd like to see this issue addressed more often in programming circles, because something desperately needs to be done.
Re:Could mentoring turn into a guild or a union? (Score:3)
The most important thing is Documentation (Score:3)
Without proper documentation, an idea or program is next to USELESS to future viewers.
All the greatest ideas have been well documented..take the RFC documents as an example. They are very rigoursly reviewed and follow a very strict code of documentation. And they form the basis for all that the internet is today.
Document your code!
Re:The problem with bad code (Score:3)
Hmm. There's can be a vast difference between "elegant" code and "code that works". I've seen beautifully written, well thought out code - written by incredibly knowledgeable folks with CS backgrounds - that did just plain damn stupid things when you considered the hardware or OS. Things that resulted in programs running about 10% as fast as required, or using about 10 times more memory then available... but boy, it was sweet code to review :-/
OTOH, working code - code that does the job to spec (speed/memory), runs on the target hardware - can be just plain damn ugly. Not unused-variables-scattered-all-over-the-place and no-error-checking ugly, but convoluted, non-obvious, "we did it this way to squeeze a 2% performance increase out of the system" or "we did it this way to avoid an obscure error condition" type of ugly.
There's a time and a place for both types of solution. Knowing when you have to do something ugly is as important as knowing when you need to put the thought in and come up with something elegant.
Re:Programming isn't Just About Functionality (Score:3)
My current project at work has a very fluid specification. I cannot tell you what is garbage and what is good for a particular module until the module is written and given for inspection to those who are designing the overall process to use the software. That means I have to make guesses about something I know nothing about so as to make a design that will work with something. All I have are guidelines. Should the guildelines change a week before delivery, in goes the fix--sans testing and sans rational design philosophy. In a word, I knowingly write shoddy code to fit political design decisions to meet deadlines set by ill-advised individuals who know not the first thing about how a computer operates.
Quite possibly, the single biggest problem with coding is the concept of a deadline. The second, almost because of the deadline, is the "I'll figure that out later" philosophy. Without a full blueprint of an application or system, (hell, I'd be happy with an accurate spec once in a while) it is impossible to make sound decisions. Ergo, bad software.
What you speak of are luxuries to your average code-for-a-living individual.
PerES Encryption [cloverlink.net]
The problem with bad code (Score:5)
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.
I tried this with assembly coding, once (Score:4)
He understood most of the assembler instructions, by my comparing them to the high level constructs, and showing how they are built. However, the point he got really stuck on was optimisation (which is really the point of asm coding nowadays), particularly memory access. He didn't see why accessing unaligned data was bad. So I showed him how memory is logically addressed versus the physical bus requests the CPU has to put out. I think this was the straw that broke the camel's back. He said 'thanks, but I think that's too hard for me', and he's now a Visual Basic coder. (No, really. This isn't a joke.)
Also a great way to even out the "Classes" (Score:3)
I have had this idea for a while, but it is taking me longer to implement it.
Enter a non-profit/profit company combo. It teaches, instructs, and mentors young under-privileged children in IT skills (specifically programming). It then turns around and seeks business support from the community: i.e. a local business has the company build their website for a cut rate, and the company uses the local kids exclusively for the project. Kids then get work experience and knowledge. The key focus being training the kids and getting them work experience--not necessarily profit. It wouldn't be the latest greatest way to make millions.
Perhaps I am idealistic AND stupid, but this seems like an effective way to reverse the tide a little bit. Local programmers could volunteer time for instruction, whereas someone would have to work full-time for the company to take care of project management.
No-nonsense SW Development Process, version 0.01 (Score:3)
No-nonsense SW Development Process, version 0.01
By Mats Henricson
Rule 0: Don't break a rule unless you have a very good reason for doing so.
Rec: Make sure a project manager is dedicated to your project.
Rec: Have regular project meetings, typically once a week, with all participants, where all kinds of project issues are discussed.
Rec: Manage risks (by using the likelyhood * severity formula)
Rule: Involve the user in the process. (This is the single most important reason why projects are successful).
Rec: Select a set of tools that works well, document its use, and make it the default tools for the project.
Rule: Use a version management tool, such as CVS, to handle your code and documentation.
Rec: When checking in code, write meaningful descriptions for the changes.
Rule: Before developing a completely new product, make sure you can't buy a similar product, or use an open source product.
Rule: Use short release cycles.
Rec: Create Use Cases (or stories) for how features are used by the customer.
Rec: Let developers estimate their own tasks so that they are realistic.
Rec: Use the Stories as the basis for writing test cases.
Rec: Write test cases for new features before you implement the feature itself.
Rec: Make sure test cases are easy to configure, run and automate.
Rec: Automatically run the test suite after each build.
Rec: Update the list of desired features after each release cycle.
Rec: Write a Release Note after each release, where all known issues are listed.
Rec: Use a programming standard.
Rec: Use a code style standard.
Rec: Review eachothers code.
Rule: Don't leave commented out code in the files, unless you explain why it is there.
Rule: Check in files in the correct order, so that the risk of corrupt intermediate checkouts by your coworkers are minimized.
Rule: Make a diff on your changes before you check them in.
Rec: A function should do one thing and one thing only.
Rec: You should never make. You should always "make clean;make".
Rec: If you've changed a file, don't ever close it until you've checked it in, since open files are a good way to remember which files you've edited and needs to be checked in.
Re:Hey CmdrTaco! (Score:5)
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
Re:Suck Less (Score:3)
Sure, words of praise are nice, but that's hardly the only benefit from giving.
If you've written mainly to "scratch an itch", there's little reason not to give it away. You can gift it, try to sell it, or keep it for yourself. Keeping gains you nothing (unless you've written The Program That Will Enable You To Take Over The World); and as for selling, the population of people who have the same itch and are willing to pay to have it scratched could be very small.
When you've put time into something, you want it to be seen and used. I've spent years working on projects that never amounted to anything except a dusty tape on someone's shelf - that sucks.
If you gift it, they will come - maybe only to snag parts for other program they're writing, maybe to take what you've written and keep it alive and growing. A program that only I ever use is like a poem that only I ever read...I don't share my poetry primarily for acclaim, I share it because I'm wired to delight in infecting others with my memes.
Tom Swiss | the infamous tms | http://www.infamous.net/
I will say this... (Score:3)
ALmost every programming language and application out there has a community of some sort.
Being involved in the community and being able to hands on talk with people who have been doing it a long time and have these gurus respond to you the little guy and see how they would do something can give a new programmer more insight in one email post than four chapters from a book.
Learn about the thought process from a brilliant mind and how to analyze a situation rather than learn about a specific way a book says to do something and again you have just made huge leaps and bounds over where you previously were.
Enthusiasm can take you a very long way, never giving up persistence and above all studying others works.
Its just like at chess, if you always play people worse than you your not learning much, whereas if you play someone who beats you in three or four moves the first time you play them you must work that much harder and you will become a much better player as a result. Just like having a mini Linus Torvalds with you as you write a new kernel module the benefits are quite obvious..
you will find that langauges and platforms with the etter communities can some of the time attract developers much easier than other language.
Jeremy