Slashdot Log In
Making Software Suck Less
from the like-frank-lloyd-wright dept.
Making Software Suck Less - Processes
Once upon a time, a prominent writer and programmer rose to declare "I want software that doesn't suck!" He then explained that certain successful free software projects have similar development features that contribute to software quality. Most of us aren't gifted with the organizational clarity of a Linus, or the brilliant non-orthogonal design of a Larry.There's hope, though. Improving the ways in which we produce software can dramatically improve the software itself. Extreme Programming suggests that simple habits, acting in concert, produce extremely powerful results. By adapting these techniques to the unique world of free software, we can improve the quality of our programs. We start by restating some common truths about free software development.
Distributed Development
Open development, of course, means that anyone with the time and the inclination can look at the code. Developers and dabblers have the opportunity to modify it to their needs. This by no means guarantees that anyone will do so. Making source code available is no silver bullet. Many qualified eyes actively looking for bugs make bugs shallow.To harness the power of additional developers, you must attract them to the project. A simple design and clear documentation reduce the amount of work needed to come to grips with the system. XP suggests an overall metaphor to describe the system as a whole and to provide good names for the components and subsystems.
Test First
The most powerful weapon in your toolbox is comprehensive unit testing. (Unit tests are automated, independent procedures that exercise the smallest possible pieces of functionality individually.) Extreme Programming recommends a test-first approach. Before adding a new feature, the programmer writes a test for the feature and runs all the unit tests. The new test fails, so he writes code to pass the test. When all tests pass, the feature can be checked in. Tests cover everything that could possibly break.When a bug appears, the programmer writes tests to demonstrate it. After fixing the bug in the code, he runs all tests again. This not only proves that the fix corrects the defect, but it proves that the correction did not break any other features. Besides that, it can prompt the programmer to write additional tests he had not previously considered.
Test-first programming ensures that all features have unit tests. Coders receive immediate feedback -- it's almost like a game. It produces a different mindset, freeing the programmer to concentrate solely on the task at hand. Code becomes easier to write, in the same way that finding the correct piece for a jigsaw puzzle is easier with its neighbors in place. Finally, it gives programmers the confidence to refactor, modifying existing code, by identifying the effects of a change.
Consider providing your test suite with the project. Add a 'test' or 'check' target to the Makefile. Projects designed to run on multiple platforms and distributions can generate better bug reports by including test results. Make it easy for users to report failures.
Simple Solutions First
After writing a test, write the simplest possible code that could pass it. Resist the tendency to make things more flexible than you need at the moment. Concentrate only on the task at hand, programming only what you need to pass the test. Don't sacrifice current elegance and simplicity for a feature months down the road.Good tests free you to change things in the future by identifying the effects of a change. Simple code localizes changes, reducing interconnections. Besides that, your design will change. Adding a feature will take the same amount of time whether you do it now or in the future. Don't spend time and energy overgeneralizing for something six months away when no one will use it in the meantime. Reduce the need for costly and time-consuming rewrites by avoiding extraneous complexity."It's true that 'simple and tested code means less bugs'.... Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs. Using your brain before you code something up reduces bugs."
Have a Plan, Code For Your Users
Write a plan for the software. Describe each feature in a paragraph or less, with sufficient detail that people will know when it is complete. Arrange the stories by importance, then tackle them in that order. This allows you to identify the work that will provide the most value to the customer. (In a free software project, the lead developers may be the customers.)Dividing the project into stories allows delegation, especially in free software projects. Some tasks require an experienced hacker, while others serve as a gentle introduction to the program. Writing stories also provides sane goals and a project roadmap. Choose a few stories for each release. This gives end users a clear view of project progress.
Continuous Design, Refactor
With tests in place, you have the freedom to refine your initial design. By using the simplest solution first, you avoid investing time in hard to follow and difficult to maintain code. Your initial design will change. Your plan will change. Expect this and allow it to happen.When you see an opportunity to refactor, do it! Eliminate duplicate code. Relocate common features into a new object or a function. Reduce complexity and interconnections. Don't maintain the same functionality in multiple places. Use simple, well-defined, and consistent interfaces. This, along with your test suite, will allow you to overhaul individual pieces without having to track down holes in far-flung files."Premature optimization-including premature low-level design--is the root of all evil."
Release Often, Release Working Features
Commit to regular release dates. This shortens the feedback loop. Users who can count on regular, stable releases with valuable new features will be more likely to use the software. It also provides more frequent entry points for new developers.Follow your plan to add a few important features to each release. Focus programmer time and effort towards a simple, reachable goal. Allow time for design, testing, documenting, and packaging. The more often you have to do this, the more likely you are to streamline these processes. Resist the urge to add features you cannot complete in time. Instead, break them up into smaller stories and implement the most important parts. As usual, the unit tests help to stabilize the codebase and keep it in a state of stability. After completing a release, take time to modify your stories, shuffling priorities as necessary. Then commit to the next release.
Re:Software Engineering will make software suck le (Score:3)
I know many programmers that, despite having no 'formal' training, can run rings around the Software Engineers I know. IMO, formal training often reduces the ability to think creatively -- once you are taught "the right way", it's hard to break new ground.
All of that said, I do agree that companies hire people without checking thier abilities. When I interview a potential candidate, I ask them to design code for a small, arbitrary problem. If the design is solid and the code functions smoothly, it goes a long way.
--
Re:Configuration Management Tools? (Score:3)
The one lesson which has been hammered home again and again and again is that a tool is just that, a tool. It can not, and will not, substitute for good programming practices and procedures which control who does what and where. It cannot be used to enforce policy; all it can do in the best of circumstances is assist a policy. Any time that a tool or process is bypassed in some way it is an indication of a problem -- either with the process, or with the business environment surrounding the process.
These are lessons many of us know, but few have learned, and fewer still apply. I know that we try, but we do not always succeed.
--
Say no to stupid fucking requirements (Score:3)
C'mon scope creep and stupid fucking requirements (SFR) are what generate sucktocity and general sucktitude. How many times have you listened to some account weenie get on all 4s and scarf the customer over and over. "Sure we can do that, no problem !!!!!!!"
But it's an SFR and it will kill you.
It
will
kill
you.
Re:Software Engineering will make software suck le (Score:5)
The ability to hack, and knowledge of computer system internals, cannot be compared to software engineering. Software engineering requires knowledge of the design process, understanding of system design, and understanding of scheduling. It requires the ability to manage design, complexity, schedule, and people. These are the points where most programmers of all grades fall down... It is the core of why software sucks. Most of the people writing code don't want to manage. They want to design. They don't want to schedule. To them management and scheduling are a burden that takes them from the pure thought stuff that they love to work with it. The price that is then paid, is that people who have no concept of the tasks at hand are asked to do the management component. Unreasonable deadlines are set, features are changed without the proper estimate of the effor to make the changes...
There is another thing to add to this. It is that people have been building things for millenia. Yet very little of this experience has been transfered to software design. Consider the planning and construction of a ship. Surely the techniques that are applicable in the engineering of that ship (remeber what I said about the management component of engineering -its what makes you and engineer not a scientist) should be to some extent applicable with in software engineering. Yet from my reading of software engineering texts this transfer has not happend. I think it has specifically to do with the sort of backgrounds from which people come to software. The theoretical underpinnings of software have always come from mathematics, where practical things like getting resources can be assumed away. A large number of the remainder have come without any education at all (self taught). They are not in a position to draw these links. They don't know where to look for the information.
--locust
Re:Software Engineering will make software suck le (Score:3)
In Steve's case, both he and his father worked out detailed prints on a drafting table and built the house themselves. They passed all the zoning commission rules at every step. Neither of them is an architect. Steve's a "software engineer" and his dad's a coal miner.
Anyway, I know for a fact that degrees prove nothing. I've met plenty of folks with CS and Enginerring degrees who couldn't write decent code to save themselves. I've had to fix their crappy designs. I've met plenty of "hackers" w/out degrees who can program circles around me, and yes, I have a MS in Information Science so I have *some* formal programming training.
The reason most software sucks really has nothing to do with the qualifications of the people writing the code or with anything that was cited in the original feature above. The real reason that most software sucks is that business managers impose ridiculously tight deadlines on the programmers, so there isn't time for adequate testing, code review or even real design. Real design involves a lot of prototyping and trial and error before you actually begin work on the final product. That's the real problem.
The real reason that Free Software is better than commercial is that there is no definite release schedule, so you, as the programmer, have the luxury of releasing the code when you think it's ready and not when some arbitrary deadline set in a board meeting tells you have to.
It has also been my experience that managers tend to have one view of what happens in software development, and what actually happens is something totally different, and that has occurred even with managers who had programming experience in the past. They seem to think we're all wizards and we just pull this stuff out of thin, and everything is "a fifteen minute fix" including refactoring and rewriting the entire application from scratch.
Re:Software Engineering will make software suck le (Score:3)
I still have a standing offer: will anyone have an architect without a degree design a house they would then live in?
Le Corbusier, detested by his contemporaries (they built a high wall around his exhibition house to hide it), got, if I recall, a third (just passed) at college. But he's now considered generally one of the greatest architects of, er, last century.
An architecture tutor once told me that, effectively, the lower your degree qualification, the more you'd end up earning.
Certainly I don't wish to dismiss university qualification. It's not a free ride. You do have to work, do the necessary things, to achieve it.
The debate here is whether those necessary things are the best/only way to produce a skilled individual. Especially in a field like architecture, where creativity and practicality have direct effect on the cost of a project, not to mention the highly intangibles like cultural depth, style, social engineering concerns, and philosophical and ethical standing (what's more valuable: reducing energy consumption, or reflecting the Zeitgeist?).
Re:Software Engineering will make software suck le (Score:4)
Would you hire an architect to design a house for you without formal training?
Just to pick up on this point, I read an old book written before architecture was professionalised in the UK. It argued against professionalisation, and made many "good points". I can't remember them all, but one that stuck in my mind is that the qualities of a good architect cannot be formally tested.
Prior to professionalisation, people who were artists, perhaps sculptors, and who were also builders, could work as architects. Both the qualities of a good artist, and the qualities of a good builder, were proven by practical experience. Reading art books does not make you a good painter. Nor does looking at diagrams make you a sound builder.
One of the main complaints that the book tried to make, was that while the natural artist/builder may be excluded from practicing architecture, the good bookworm would easily 'qualify'.
So indeed we end up with only those 'architects' who are good at passing exams.
Being able to remember textbook diagrams and calculations and history essays, for exam regurgitation does not guarantee any practical understanding. Note that doctors spend a lot of time training in hospitals. But architects are trained in studio/lecture theatre conditions that bear little relation to real world practice. Still confident about that architect you want to hire?
Re:Software Engineering will make software suck le (Score:3)
And if you yourself were not well-versed in the art of architecture, how would you be able to judge?
Well, you might rely on the opinions of others who were able to judge. Perhaps there would be some sort of professional organization you could check with, see if this architect is a member.
And how does the professional organization let members in? Usually some sort of coursework or test must be passed.
And how does one prepare for this test? Well, probably some practice, as well as some instruction from others versed in architecture.
Gee, sounds a lot like getting a degree and going through formal training, eh?
As I've now said repeatedly in this thread, a CS degree is NOT proof of skill as a software engineer. But lacking other tests, it's the best we've got. Discounting it because it isn't perfect is, quite simply, dumb.
-jon
Re:Software Engineering will make software suck le (Score:4)
Bah. Would you hire an architect to design a house for you without formal training? (I don't want to hear about Howard Roark; he's a fictional character in a poorly written book) Would you hire an untrained civil engineer to build a bridge for you?
There is no relationship between formal training and creativity. There IS a relationship between formal training and knowing what will work. Geniuses know how to push the limits on what will work and create new paradigms. Most untrained people in any field (and heck, most people in any field) are not geniuses, and the less people know, the more likely that they think they are geniuses. That's the real danger.
-jon
Software Engineering will make software suck less (Score:5)
How many times have people heard of programmers with no degree working on or designing large-scale projects? It's insane. No one would hire an architect or mechanical engineer who didn't have at least a piece of paper from a college. But it happens all the time in software. The costs of the defective systems being turned out by untrained programmers is starting to matter.
Even a CS degree really isn't a sufficient solution to the problem. Software Engineering is NOT computer science, just as Chemical Engineering is not Chemistry. You need knowledge of the latter to do the former, but there is a different skill set which must be learned. Unfortunately, I'm not aware of any school which is teaching it to potential software engineers. When they do, real software development can finally begin.
-jon
Re:Software Engineering will make software suck le (Score:5)
No it isn't ground-breaking to know that ignorant people don't know they are ignorant; the authors of the paper quote Charles Darwin: "as Charles Darwin (1871) sagely noted over a century ago, 'ignorance more frequently begets confidence than does knowledge'."
What was ground-breaking was showing that people who weren't ignorant downplayed their skills; they "knew what they didn't know."
He makes the flawed assumption that college graduates make a better effort to continuously hone their skills than non-graduates - a claim with little to no evidence, at least none that he has shown.
The evidence is the college degree. It's a hoop to jump through; a painful, stupid hoop sometimes, but a hoop nonetheless. Get a science or engineering degree from a top-tier school and it says that, at the very least, you know how to work and to think. Skip that process and pretend that it doesn't have any value and it says volumes about you.
I trust in top-tier universities to separate wheat from the chaff because I don't know of any other process which is a better way to judge someone just starting out. Can you name one, or do your skills only lend themselves to criticism?
I still have a standing offer: will anyone have an architect without a degree design a house they would then live in?
-jon
This is not groundbreaking, but it's IMPORTANT (Score:3)
A similar strategy is set forth in some of the newer computer programming books i've seen including "The Practice of Programming" and "The Pragmatic Programmer", both of which aim to develop habits in programmers that cause them to produce cleaner saner code in a practical and intuitive way.
I think this is important because it is a practical alternative to the people who say "all programmers should be licenced and regulated, they should all have degrees, and all their code should be mathematically proven and group audited" while this will produce space-shuttle or medical-instrument grade applications, it will also produce space-shuttle grade costs. When you have to pay $125,000 per seat to use your word processor, but it's bug free, it's just not worth it.
These common sense practical approaces are more efficent than standard high pressure, low quality, commercial software development in terms of man-hours spent developing the same software, and as an added bonus, the software works better, and when it does have bugs, they are easier to track down.
So, no it's not new, it's the advice from older programmers who have been doing this since _way_ before i was born, so i should listen to it, not ignore it because it's not new....
Configuration Management Tools? (Score:3)
The design, development, testing and deployment of software is a very iterative process. What kind of tools do you use that you have found to match this process and be very sucessfull?
I realize that these tools have to be easier to use and have more benifits to using them than not to use. But what would be an ideal situation for the development of "software that doesn't suck?"
XP is no panacea (Score:4)
OK. With all due respect to its creators and proponents, I think this XP meme has just gotten out of hand. Even some of XP's most ardent supporters admit, in moments of much-appreciated honesty, that its value depends on a certain set of assumptions about project type, size and environment. Check out this article [extremeprogramming.org] for an example.
XP uses iteration as a central theme. Iteration is great. I've hardly ever seen a program that wasn't significantly better on the second try than the first. Many older methodologies are based more on decomposition as a central theme...and you know what? Decomposition is great too! Divide and conquer, oh yeah. These are both incredibly useful tools which should be considered to complement rather than compete with one another. Any experienced programmer knows to use both, instead of being seduced by the abstract simplicity of methodologies based on only one.
I see it as an issue of "step size". XP and other iteration-oriented methodologies work best in systems where functionality can be added in small increments without requiring deep structural changes every time. A very large class of programming tasks, including GUIs, meets this requirement. XP tends to fall down, though, in cases where a huge number of things all have to work in concert to get any positive results at all. OS kernels come to mind. Decomposition should be the first tool you reach for in those cases. Maybe you can apply XP or other iteration techniques once you've broken things down, but there's no way around the fact that you have to break them down first.
Another difference is that XP is experiential and interactive, while other methodologies attempt to be more predictive. We all know the problem of trying to predict the unpredictable. However, prediction is not entirely without value. A thorough familiarity with the problem domain, combined with some elementary application of statistical principles, can yield predictions that are startlingly accurate for most projects. Those predictions can be used to achieve near-optimal resource allocations throughout the life of the project, instead of keeping "excess capacity" available for the project's peaks and troughs. Much of standard methodology is about making such predictions as accurate as possible. Nobody expects them to be perfect, but the better they are the saner life will be - not only for managers and customers but also for developers who won't have to put up with absurd expectations during an extended "crunch time" at the end of the project when everything they punted on comes back to haunt them.
I guess what I'm saying is that XP is half a solution. It's great, get the word out by all means, but adopting XP will not solve all "software sucks" problems and in some cases it will make things worse. If you know anything about horizon effects and hill-climbing problems from AI, you should know the dangers of incrementalism, and XP is an incremental approach.
Re:Software Engineering will make software suck le (Score:3)
Oh and the reason why we call people "geniuses" is because they are a minority that have higher intellect (or whatever the hell you want to call it) than the majority of the population. So I think pretty much everyone (except you obviously) knows that they are not hiring geniuses, nor do they expect geniuses (actually that's one of those things about geniuses, you never really expect to run across them).
Process and Testing (Score:5)
I recently helped to add that CALEA surveillance garbage to a certain cellular system that was kinda news recently due to working with Sega on games for the subscriber unit, etc, etc. I didn't want to do it, most people I worked with didn't want to do it, but we still took the time to do it right.
We followed software processes, tailored to eliminate unnecessary steps, and adding ones useful to us. We did quality unit testing on everything we touched, including functions that had been around for years. We re-wrote any DOL and function comments that were hard to read or out of date. And that was most of the old ones we touched.
We took the time to break old functions that had grown complex (20+ cyclomatic complexity) into smaller pieces.
Guess what? Not only were we just about on schedule (even with the extra time fixing problems left by other people), we found defects that had been sitting around that nobody knew about, and within maybe a month from the time we hit the system test lab, the area of the box we worked on was more or less defect free.
We put more effort into process and testing than people had before, and had one of the best quality releases the department has seen. In fact, we've been spending months trying to find things to do because time that was set aside for us to fix defects found in testing and the field has been idle, because they haven't been coming in.
We're not talking about minor changes either. 13 people, months of work each. The other feature that was in the release at the same time as us was smaller, and had fewer people, yet more defects, and took longer.
A process for the sake of process, well, isn't a good idea. One that is based on doing things that work, and changes with feedback, becomes a great thing to have.
---
Frank Lloyd Wright (Score:5)
Wright saw things as a whole object. He spent months thinking about the construction of Fallingwater and visiting the site. He drew the first concept draft in about 3 hours. (he actually called the client to come over and see what he had drawn before sitting down to draw it) It changed Very little from that initial drawing. Most experts at the time said the horizontal balconies would not stay floating out into space the way they do and would collapse. The workers were constantly changing the plans because they did not have faith in Wright's design. (Modern analysis now shows that these workers acually ended up weakening the structure)
As someone who has actually walked through fallingwater, I think one could easily say that the design is the most elegant, natural design you could possibly want.
To apply Wright's ideas to the concept of software engineering: I would say you either have to be very gifted in how your brain processes/sees information, data and functionality, or create a system that is whole and complete through lots of careful adjustments and evolution. The latter seems to be the common OSS approach however the former is the more respected/impressive way.
I think the important lesson here would be that all of these people create something that stands as a whole unified concept that doesn't sprawl out where it doesn't belong and is fundamental enough to change the way other people see the world or problem space. They all thought about their designs A LOT! They are all artists and craftsmen.
Wright's work inspires me and fills me with awe, as does perl and the linux kernel. Does your software?
-pos
The truth is more important than the facts.
Unit testing isn't all it's cracked up to be (Score:4)
It's this kind of thinking that causes too many of the problems you are trying to prevent.
According to _Programming Productivity_ by Capers Jones, unit testing, will only find 25% of the defects. At its best, unit testing finds 50% of the problems. Compare this to, for example, formal inspections, which find 60% of defects on average, 70% at best. Modeling and prototyping (build one to throw away) can find up to 80% of defects.
None of these methods will build a completely defect-free program, but by combining a number of them, you can get extremely close (99%).
Re:leaky roofs -- cheating contractors (Score:3)
They sent me an interesting article a few years back. It seems some archietcture professors ahve been doing some digging into Wright's more ntoeable failures. ity turns out his design in every case was correct-- it was contractors cheating on the quality of the materails that caused the problems.
(It was fairly common at the time for less then honest concrete contractors for inatance to water down their concrete mix feeling this was "good enough". Over the entier course of s tructure they could shave a fair bit of additional revenue.)
As to your "what Wright would say", I noticed no quotation marks. Is this conversation in your minds eye or do you have a direct Wright quote and attribution for it?
As long as non-coders are involved in coding... (Score:4)
Most people in software development these days are clueless. Having a university degree, college diploma and/or MCSE does not make one any better at coding, from what I've seen. Programming is something that requires both inate talent and experience.
Second, making development environments supposedly more accessible and "fun", while stripping away useful language constructs because they are "too complicated for the average programmer", only makes for sub-par software. Try making a 30-screen database app in Visual Basic. Actually no; don't ever try that. Just beleive me when I say that it's damn near impossible to produce a good product that way!
Finally, most new programmers are thrown into difficult tasks without much background knowledge at all, and very little if any mentorship. Still they're expected to produce exemplary results. Sure it's fun to be "challenged", but that's not the way to have a good end result.
What's important is allowing people to gradually gain experience in programming, to guide them along the way, to show them how to improve their skills, and to give them the proper tools to get the job done. This is how it's done in every industry, except for that of software.
First Names... (Score:4)
Okay, I just noticed this sentance...
Most of us aren't gifted with the organizational clarity of a Linus, or the brilliant non-orthogonal design of a Larry.
Why is it that geeks feel the urge to call celebrity geeks by their first name only? You sound like thirteen year old girls reading Tiger Beat magazine!
--
There is a difference (Score:3)
On the other hand, software engineers with a home computer have all the tools they need to go full life cycle. They can get hands on experience doing everything a professional engineer would do. They can learn from their mistakes, and explore techniques and possibilites.
All the knowledge they need is avaiable online. You can buy books for any level of software enginnering learning cheaply, if you prefer dead-tree medium. There are huge online and IRL communities to give you free help as well.
College is porbably irrelevant so far as becoming a good software architect goes. Noone can make you learn; Its something you have to take for yourself.
I know this first hand- Ive been coding my entire life. When I looked at the curriculae at a few colleges offering degrees in CS, I had to laugh. They teach almost nothing.
So I went straight into the industry- got a job. Ive met PhD's I wouldnt wipe my shoes on. It seems like programming skill is inversely proportional to academic accreditation.
Re:Software Engineering will make software suck le (Score:3)
A couple of famous people in the industry you may have heard about: Bill Gates, Larry Ellison, John Carmack - no degrees. Are you going to tell me you are a better programmer than John Carmack? Do you really think you have a better handle on software engineering than Microsoft's Chief Software Architect(funny, but yes, thats his title).
Something like 100,000 software jobs open up every year, while our universities only graduate about 30,000 people with CS degrees. So why not have industry-standard apprenticeship programs. What about bright people who change careers mid-life(I fall into this category). I plan on eventually getting my degree, but were talking 4-5 years of taking 1 or 2 classes a semester. I have to work, and engineering schools generally are not geared to handle working adults. Big problem, but the unis are not addressing it.
You may be making life easier for yourself by using the degree to separate the wheat from the chaff. But don't delude yourself - you will miss out on hiring some good people by your own limiting criteria.
A tip.. (Score:3)
Here in Canada, it is your right to have things told to you in French.. This is usefull if you don't understand french. Repeat until they give up.
The right tool for the job (Score:3)
The real issue here is bells and whistles that are not central to the programs function. It's nice that Word can mailmerge an address list from an Outlook or Excel file but since I'm not in the mass mailing business I really don't need the feature. It's there and there's nothing I can do to get rid of it. It should be a plug-in for those who need it. (Professors where I go demand all reports emailed as a Word attachment so not using Word is not an option yet.)
Any one can make shelter. It's a primal instinct that man has. Some thick branches, leaves and mud and you have a house. All you really need an Architect for is to make bigger fancier more expensive houses with features that don't always work properly. Like fire alarms that go off when you use the oven. Like hidden water pipes that sweat condensation which drips into a hidden electric box shorting out the current and burning down the house.
Now a good Architect knows how to avoid these kind of problems but sometimes a build