Slashdot Mirror
Making Software Suck Less, Pt. II
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.
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
I think one major point which has been missed in the previous discussion was the aspect of debugging code.
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.
---
---
"Of course, that's just my opinion. I could be wrong." --Dennis Miller
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.
--
There's a deadline, and how much you're going to do. As time approaches deadline, the suckfactor goes up. It's a simple equation. :)
And software is NEVER finished.
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....
... most of the time. Because there is not one person alone who can build a whole system, you need to do team work and dispatch responsibilities. You need some managers who usually are quite distant with technical realities (deadlines, budgets). You need techies who are quite distant with the real world (what do you need a GUI for ?). You need a nice working environment and what's more you need to communicate. Eventually, you need a customer who knows what he wants and have precise ways to describe what he wants. In addition, get me some heavy competition and so the problems start!
:)
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...
É que os desafinados também têm um coração
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
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:
- Study Fundamentals Not Tools APIs or OSes
- Properly managing memory returned by transcode() in the Xerces library (while about an obscure problem, it illustrates more general principles in a useful way)
-
Secrets of the Debug Meisters: MacsBug Tips and Tricks (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 - 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
- Spotlight for Mac OS PowerPC
- BoundsChecker for Windows
- Purify 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
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
Presumably, people who write Open Source code are doing it for their own enjoyment, which means they will tend to concentrate on the things they enjoy (adding new features) not the things they dislike (debugging someone else's code, documentation). This is one area where I feel the Open Source methods can be weak... there's no real imperative for quality control, since everyone's doing it for the enjoyment. A prestigous project may be able to enforce some quality, but for smaller projects, I can't think of any way to induce people to concentrate on the necessary but boring tasks as opposed to the fun (and maybe not necessary) tasks.
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.
I'd suggest all of you who teach at any level to encourage your students to contribute to an on-going open source application as their class project. I do this for my web enabled database development class for UMASS and I think if nothing else it's exposed a lot students to a cooperative method of developing software.
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
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!
Syllable : It's an Operating System
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).
My first real job out of college was with a small startup doing a turnkey system for medical labs on PDP-11s. I was an Astronomy BA with a couple of coding classes (FORTRAN, APL and PL/I) under my belt and a couple of summers working in the DP shop (COBOL, RPG II, and PL/I) of a Fortune 500 company as an operator and programmer. I'd read a few classic books on programming and software engineering. In other words, I knew enough to be dangerous.
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.
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
There are too kinds of software that you'll find on download sites. Software that is intended to get the job done and software that is intended to help the programmer learn wtf he is doing. You'll very often find more of the latter than of the former, but each plays its own role in the programming community. If you see a piece of software that sucks, dont just delete it, email the author and tell him that it sucks. Let him know what you think is good and bad, so he can learn. Who knows, you may be helping out a future alan cox.
I am !amused.
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.
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
Sure. Join the ACM.
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!
-
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.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
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
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."-
I'm on several mailing lists, including ones regarding oldskool music ripping. One particular person had written a ripper in a high level language, and wanted to know more about assembler language so he could make it rip much faster. I quite happily offered to help teach him assembler.
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.)
Does my bum look big in this?
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.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
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.
The "network of peers" cant be expressed enough.
:)
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