The problem is that a lot of GUI frameworks are pretty hostile to testing, but it can be done.
Rendering stuff, for example, can be tested by comparing output bitmaps. For example, I'm doing some photo stuff, and all of the methods that output images I just get working manually and then once their output looks right, I save that and make the check part of the test suite. Anything that outputs numbers (e.g., the calculation of the size of the new image for a scaling operation) is just tested the usual way.
Other GUI stuff you can test by generating fake events and setting up mock collaborator classes to make sure things do what they should when they should.
And you can also take a just-the-essentials approach. For my web work, I test the underlying components extensively. I also have a web robot that hits a test copy of the site and makes sure that it all works well enough. I don't test every bit of HTML; I just make sure that important strings appear in the right place, that clicking through gets to where I think it should, and that feeding the right data to the right forms gets abuot the right responses.
Still, it's more of a pain than it should be. I look forward to the day that somebody develops a GUI framework test-first; those components will be much easier to work with.
Any faults that you have in your conception of your test program will be carried over into your module, or worse your module might be correct but your test program flawed
In practice, this isn't really a problem. As long as you write your tests first (rather than hacking them together afterwards) then they're a pretty good expression of what the code should do. Then the code itself is an expression of how to accomplish that.
Of course, it's possible that one has the wrong idea and makes the same mistake twice, but you use other practices to guard against that.
Seems like an extra layer of complexity rather than a useful method.
Maybe. My score for the last year or so is less than one reported bug per man-month of coding. And it's lower than that for my code written while doing pair programming.
Hi! I've been doing XP on and off (depending on client preferences) for a couple of years.
I'm immensely happy with it. It's not a magic bullet, but gives me the tools to solve a lot of common problems.
Does the reliance on incremental development and refactoring rather than a intricate, up-front design really work, or result in a big wad of band-aids?
Yes, it works. It takes a bit to learn how to do it well, but it works.
Indeed, in some ways, it works better. When I did most of my designing up front, I had to guess about a lot of things. Now I'm a pretty good guesser, but I'm not perfect. And since I knew I was making designs that I had to live with for years, I tended to play it safe, putting in things that I would probably need someday. I hoped.
Now, I don't put anything in until I know I need it. This keeps the design cleaner, and saves me all of the time I would have spent on bad guesses and things obsoleted by changing requirements.
Is pair programming OK, or do you sometimes get stuck with the nitpicker from hell who has to have every detail his own way?
I like pair programming a lot, and more people are good at it than you would expect. But some people are indeed pains in the ass; just last week we had to sit one guy down and have The Talk with him. If he doesn't shape up, he can go be a nitpicking cowboy on somebody else's project.
Right now I'm also doing some solo work, and it really suffers from the lack of a pair.
Is close involvement with the customer good, or does it just give them daily opportunities for endless bright ideas that prevent convergence?
It can work really, really well. The trick is that you must let them steer the project, so that they can see that asking for all sorts of random stuff means that their precious project will be screwed.
For example, I and another fellow were recently called in to work on a project that was six weeks from delivery and running late. The product manager handed us a one-page spec, spent 30 minutes showing us the existing code and said, "So can you do that in time?"
Now the only honest answer was, "I dunno, but probably not with all that you've asked for." But we walked him through the XP practice known as the Planning Game, where we broke his requirements down into bite-size chunks, wrote them on index cards, and then he ordered them by importance. There was far more work than could be done in time.
So then we asked him to draw a line at the point which, if we didn't reach it, he would slip the date, and if we did, he would ship. It cause him great pain, but he did it. Then we agreed that we would start developing and see how things were progressing.
As time went on, he, like any client, had all sorts of great ideas, and so did we. Every one got written on a card, and we asked him to place them wherever he wanted in the stack. This forced him to make tradeoffs; the more stuff he put in before the release, the farther away the release would be.
When the six weeks were up, we shipped a product with less than half of what he originally asked for. But instead of being pissed, he was happy! He got the half that was most important to him, and he was the one who made every choice about scope, so it wasn't our fault, that was just how things were.
And best of all, because we'd stuck to the XP practices and done extensive testing, there have been no bugs reported against our code. With code that solid, we're glad to start extending it, instead of the usual pattern where a big deadline push means the code is crap.
So yes, I like XP a lot. I get to write good code, polish the design, and have good relationships with the business folk. It rocks!
So, write your tests first. But do your design before you code, not after you've put together a thousand lines of crap.
If you've written 1000 lines of code before you refactor, you're waiting way too long. I do little refactorings every few lines, and bigger ones whenever things don't look right.
Look at it this way: you can do your design before you code, while you're coding, or afterwards. The waterfall advocates about 80:20:0. But that assumes that you learn nothing, think of nothing when coding. That's stupid; instead, what people do is grumble and imagine what they'll do in the next version.
Now that I'm doing test-driven development, my ratio is about 20/30/50. I still do some design up front, and that's very valuable. But instead of having those raging arguments about what design might work best, we start building and find out, refactoring towards the best design as we go.
Waiting until you've cobbled something together that passes the test and then hoping that your boss will allow you to refactor is a loser.
If a boss is such a micromanager that he's telling you which lines of code to work on every 15 minutes, then it's time for a new job. The people I work for recognize that I'm a professional and trust me to tend to my business, especially given how willing I am to explain it to them.
When bosses ask about refactoring, I explain that we do it so we can go faster. If they think it's a net loss, then I am always glad to prove them wrong: if they want to measure productivity each month, we can see which way works better.
Think of it this way: not refactoring is like not exercising: you get slower and slower, everything gets creaky and unreliable, and you die sooner because your arteries are clogged. A little regular exercise keeps you healthy, limber, and active.
Optimization should never be done until after you've run real-world use cases on code with a profiler. Until then, one should write code that clearly communicates its intent.
"Premature optimization is the root of all evil."
says Knuth, and Martin Fowler says
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
Remember: Computers double in speed every 18 months, but programmers stay just the same. If we want our code to live a long and happy life, then clarity should almost always win over speed.
Which level do you run the tests at? Best to test all levels, of course. [...] But once you've run all that, it is very difficult to pinpoint the source of the problem.
It sounds like your unit tests are too coarsely grained, possibly because your APIs are too monolithic. Try breaking things down some.
Generally, I write a couple lines of test code and then a couple lines of production code to make it pass. Then I rarely have problems testing the things I want.
Feel free to drop me a line if you have questions; I've done a lot of testing of XML and HTML.
but after skimming through the first 5 chapeters of 'Planning XP'
If you're a programmer, that's the wrong book to start with. Read Extreme Programming Installed, by Jeffries, et al.
I'm starting to think that XP really is just one big hot air balloon.
In my experience, it's not. Since adopting it a couple years back, my designs are better, my bug counts are much lower, and I am much happier. Feel free to drop me a line if you have questions.
Since the.Net framework was released, VB is now every bit as powerful as the "real" languages.
Yes, now that they've made it Java, it is indeed just as good as Java. It's a shame that they didn't look at taking a major step beyond Java, though.
But still I'll skip it for now; anybody that takes seven versions just to get a language out of the "sucks majorly" zone isn't somebody I'm going to trust right away.
I would imagine there are a lot more jobs for VB than there are for the languages you listed as should be required (Eiffel, Lisp, Icon).
True, but unrelated to getting an education. Nobody buys CDs of people singing scales, but nonetheless, you gotta sing scales.
I do the same thing with my shorts...download away!
If you've figured out a way to download your shorts, there a lot of people in the porn industry that would like to talk to you, especially given EBay restrictions on these sorts of things.
After a lot of research, I also picked the Treo 300. Since I've been using a Palm since the first model, I was inclined to stay with the Palm platform, so I didn't look at the PocketPC items much. Previously I used a Palm V and a Nokia 6190, both of which I liked a lot.
It works well as a phone. For me in San Francisco, the coverage is good, and Sprint's network sucks a lot less than Cingular's did. It feels a little weird against your head, but you get used to that. It doesn't feel as tough as my Nokia, which worked well despite plenty of abuse. And it's great having all of my contacts right there, rather than the 30 or so that would fit into the Nokia's memory.
The always-on, flat-rate data connection is just ok when compared with a desktop, but fucking great compared with not having it at all. It's really nice to be able to use Mapquest on the road, to check my email from airports without paying $8 for the opportunity, and to be able to read the news when I'm loitering. And having Google in your pocket comes in handy more than you'd think.
As a PalmOS PDA, it seems fine. I too would like some expandability, but the built-in 16 MB of RAM is more than enough for everything I've wanted to put on there. One Linux caveat: the USB Sync cable for the Treo 300 doesn't work with current kernels; you must buy the serial cable, too. (It's only the 300 that has this problem; the other Treos don't.)
Battery life is an issue; you certainly should charge it every night. Given that, it's fine.
Overall, I'm very pleased with it. It's nice not to have to carry two devices around anymore. The only real drawback is that everybody who sees it wants a demo. I recommend it without hesitation!
Personally I think think they should get some sort of moderation system up ASAP... there are a lot of people out there who just like to break things for the fun of it.
Yes, people always say that about Wikis. But it turns out not to be necessary.
Note the announcement: Wikipedia has been up for two years. It has 100,000 articles. They have made it this far without traditional notions of moderation. Ward's Wiki, the original one, has been around for much longer, and it's just a bunch of pages.
So all ye who think that moderation, access control, and similar dominance hierarchies and territory markers are necessary, think again.
Wrong. [...]Have you not been paying attention?[...] drowning a baby because it cries is an obvious solution
Oops! Sorry! I mistook you for a reasonable person. Sorry to have wasted your time. If you want to actually want to discuss this stuff, you know where to find me.
Yes, but twitter argued that Microsoft got where it is through illegal or unethical behavior. I assert that this isn't true.
Assert away. But federal courts have repeatedly found otherwise. Given the amount of money Microsoft spent on lawyering, it's hard to say they didn't get a fair trial.
big and it seems strong from the outside, but there are barbarians at the gate just waiting to get in
And they will likely keep waiting. Most serious competition Microsoft has seen in their core businesses (OS and Office) have been seen off by use of monopoly power. The only notable exception, Linux, is free. That's not exactly encouraging the barbarians to get out the ladders and catapults for the big assault on Fortress Microsoft.
Ironically, Microsoft's biggest competitor is Microsoft. [...] But whatever the situation, the fact remains that we (as a culture) have never come up with a good way to keep companies from getting too big, or to make them small again once they've gotten too big.
Well, actually, we have. And you even suggested it again here. If Microsoft is too big for anybody else to compete with, then breaking them up is an obvious solution. If they, as they claim, aren't illegally using their monopoly powers, then this won't hurt much. And it might even help Gates's bank balance: the market value of conglomerates is often higher after breakup.
Other industries will follow as the necessary skills and infrastructure become more wide-spread.
Many will, but I don't think this one need go.
To keep development work here, we must exploit the one advantage we have over people 10,000 miles away: we're closer. Sure, that sounds too simple. But hear me out.
The traditional dominant development process, the Waterfall, assumes that you can put every important fact about a piece of software into a requirements document. That document is then turned over to the geeks, who could be kept in a sealed room, for construction. N months later, perfect software comes out.
We all know this is bunk. And not just from practical experience; if the requirements document really had all the needed information, then you could just write a requirements document compiler and dispense with the programmers completely. But it's the bunk that allows outsourced development companies to work. Not just because it allows them to pretend a development center on the other side of the planet is just as good. Even worse, because we believe this bunk, their development centers are just as good as keeping the engineers in the building (or city, or state) next door, as is common practice here. So what should we do instead? We should pick development methods that take advantage of the highest-bandwidth, lowest-latency communication available to us: physical presence. If we put the engineers in the same room as the domain experts and the product managers, then we can build software more quickly and more efficiently than before.
But we get more than that. If you put everybody together, then you get unmatched ability to respond to change, change in the market, in your customer needs, in your competitor's products. A bunch of people in a room can turn on a dime compared with the difficulty of changing specs, changing contracts, and updating people who are asleep when you are awake. Even better, you can create change, forcing your competitors to try to keep pace with you.
So for those interested in keeping at least a few develoment jobs in the US, check out the book Agile Software Development Ecosystems (prices). Or look at one of the many Agile methods directly:
And for the record, I think world trade is great. If somebody in India can really do my job for 1/10th as much; then I should find something new to do, something that provides matchable value to my clients.
Trust me, these folks are VERY concerned about their careers and their industry. They are also very concerned about quality.
Wipro may be. I have been hired to review three Indian outsourcing efforts; they produced garbage. My sample size is small, and I'm sure there are good Indian outsourcing companies. But there sure are bad ones.
Which is why we should be worried. It's why we should strive to produce better code and strive to do it quicker.
For those actually serious about this, consider trying the practice of Test-Driven Development. The basic notion is that you write a few lines of test code, and then write the production code that makes it pass. Then do that over and over again, running your whole test suite regularly.
This improves quality immensely. That's not just because you get a test suite with 100% coverage. It also forces you to design things more simply and carefully, resulting in much better design.
In my experience, it takes no longer than regular development, as you cut out a lot of debugging time. And you end up with a comprehensive test suite for free.
If you don't like a competitive market, that's just fine. You're a grown-up (presumably) who is entitled to his own opinions. But a competitive market is what we have, and companies like Microsoft and Wal-Mart bubble up to the top because they're really good at being competitive.
You're missing two important things here.
One is that once a company has a monopoly, the standards for their behavior change. Things that were legal when they had 10% of the market are not legal when they have 95% of it.
And the other? As you say, the reason that we have a market economy is that it works well. The reason it works well is that strenuous competition forces continuous improvement for the consumer and the society at large. But once a company becomes so large that they need not fear others, then they stop feeling the pressure of competition.
Therefore, complaining about VB because there are idiots in the world isn't fair.;)
Actually, I'm saying something a little different.
I'm saying that people are all idiots. The tools we build should reflect that.
One swell example is from years ago: a Chevette that a friend of mine drove. The car was a crappy, lightweight econobox. If you got into an accident at high speed, you'd be strawberry jam. That's fine; there's a place for low-budget cars in the world.
If you took this car at anything above 60 mph, it felt like the car could come apart at any moment. It felt dangerous. And, IMHO, that's exactly how the car should feel. It kept foolish teens like myself from going too fast.
Now compare that with many of the modern SUVs. These cars are designed to feel big and tough. But it turns out that they're just as dangerous to the drivers as your average mid-size (and even many of the small cars). And worse, they're twice as dangerous to the people you hit. But since the don't feel that way, people don't drive them as carefully as they should.
So VB is (or at least was last I used it) like a golf cart inflated to SUV size. It is really only safe for tooling around your subdivision, but it sure looks like it should be able to handle the autobahns.
It sounds like y'all are doing better than about 80% of the industry. Congrats!
But you should consider extending your test coverage further. Or, more accurately, testing smaller units.
I look at it this way: when I'm forced to use a debugger, that means that I don't really know what the code is doing. I have hypotheses, of course. So instead of setting breakpoints and examining values, I just start adding tests to check the hypotheses.
That way I get the benefit of my careful thinking not just when I'm in the debugger, but every time anybody runs the test suite.
I'm not entirely convinced by the "test first" philosophy. That's always struck me as more of a political point than a practical one.
You should give it a try, at least for a couple of weeks. It completely changes the experience of developing. But make sure to do it in very small increments: write a few lines of test, and then a few lines of production code to make it pass. Then repeat.
The feeling of confidence it gives you in your code is incredible. It is also more fun; your day becomes a hundred small victories. And because you're always working from the tests, interruptions just aren't a big deal. And most people find that it substantially improves their OO design, too.
Personally, I find it very practical. For something that's a page or two, I can just crank out the code and not worry about the tests. But for any serious project, I find the tests save me more time than they cost.
Because it makes no fucking commercial sense to cater to you, period. Which is the point I was trying to make.
Excepting, of course, that Linux users are
exactly the sort of people likely to get so excited over some networking functionality that they're likely to pay $400 for an otherwise merely adequate boom box.
much more likely to have the permanent network connections and always-on computers that make a networked stereo more useful.
the kind of local, informal expert that friends and family often turn to when trying to decide about a high-tech purchase.
the same sort of person that friends and family turn to for tech support
the kinds of people who will make all sorts of cool extra software for your consumer goods (e.g., see RockBox, open-source firmware for Archos MP3 players, or the bunch of stuff available for Turtle Beach's Audiotron.
So maybe instead of being a carefully calculated move on the part of Phillips, perhaps the product manager just had no fucking idea about the commercial value of an empowered user base.
But they will. Consumer electronics companies compete on razor-thin margins. Any advantage they can get, they'll take, just as soon as they recognize it as one. Using open protocols are a free way to do that, and throwing in a little Unix glue is pretty cheap, too.
Then you haven't written enough tests. Or you're trying to integrate too much at once.
Must be nice to work in a world where you have time to write comprehensive supra-unit tests and can rely on all your co-workers to have fully tested their code. I'd like to visit that world sometime, because in my world schedules are allocated such that it's rare you have time to do more than just unit testing and they call integrated testing "beta".
If you want to go as fast as possible, then you don't have time not to not keep things clean by writing good tests, integrating continuously, keeping in close touch with your coworkers, and refactoring whenever you see a way to improve the design.
In the very short term, say a week or two, you can improve your productivity by writing utter crap. But that's just storing up trouble; in effect, you borrow productivity from the future. But it's like borrowing from a loan shark: the interest rate is terrible, and the project ends up with broken kneecaps if you don't pay up pronto. If you're writing code that's only minorly crappy, then you build up cruft at a slower rate, but the problem's still there, and it will eventually lead to critical mass.
So yes, it is to nice to work in a world like that. And it yields better software faster, so it's great for the suits, too. My advice: either change your organization or change your organization.
In theory methodologies like this are good. In practice (at least in a startup environment) developers simply don't have time to follow such practice.
In a startup environment, everything you do will have far-reaching effects in the future. In a startup environment, it's much harder to predict where your company will go, as both investors and your customers will pull you in new directions. In a startup environment, people will be promoted so quickly that you can't assume that in three months they'll be around to support (or even explain) the code they're written. In a startup environment, missing a deadline or delivering buggy software an be fatal.
More directly: in a startup environment, you don't have time to do it in a half-assed way. Ergo, you should plan to do it right from the beginning.
And yes, I've just done this in yet another balls-to-the-wall, full-on-stealth-mode startup. The only thing the CEO regrets is that we didn't make him do it better.
Wow, you really hate VB. [...] I'd rather be working in C++ or even C, so take the following in context, ok? [...]VB *CAN* be used for relatively larger projects [...]
Oh, I agree. Any language that is Turing-complete (and some that aren't) can be productively used by a programmer who is sufficiently smart, careful, disciplined, and intensely aware of both the big picture and those who follow in his footsteps.
So if we were all omniscient, self-programming robots, I'd say that assembler was for sissies, that real programmers only had two keys on their keyboards: zero and one. And fuck the backspace.
Alas, programming is done by real humans, ambulatory sacks of meat, albeit with occasional fits of brilliance. Good toolsmiths know this, and make appropriate tools. People who make bad tools (like VB) are either fools or inhumanly cruel. I can never decide which explanation I prefer.
What if the fellow programmer walks in and catches you talking to a rubber duck?:)
When you tell him how many problems little Ducky has solved, your main problem is that he will try to steal your duck.
But if you're really worried about appearances, write Ducky an email about the problem. If by the end of the email you still are mystified, you can always send the email to a colleague.
poster I was replying to advocated that if code was written on paper (rock + chisel, ed, whatever) bugs aren't going to be created thus making debugging unnecessary.
If that were what he said, you'd have a point. But really, he never said, "never use a debugger,' just that programmers who learn to do without them are better programmers.
In my experience, he's right.
Test-driven development = debugging your own code if you see that you broke something, and to do that you do need debugging tools...
For you, perhaps. I ocassionally find a debugger convenient, but only slightly more convenient than inserting the occasional printf. Many experts in test-driven development say the same thing.
My point, though, is that spending much time in a debugger is a sign that there's something wrong elsewhere in your process. If you need to use a debugger, that means there's a problem and you don't know where it is. That, in turn, means that your test suite has got some pretty big holes in it.
Rather than wandering through in the debugger, you should add tests until you find one that is broken. Then not only do you find the bug, but you also make it so that the bug can never return.
Slashdot Mirror
The problem is that a lot of GUI frameworks are pretty hostile to testing, but it can be done.
Rendering stuff, for example, can be tested by comparing output bitmaps. For example, I'm doing some photo stuff, and all of the methods that output images I just get working manually and then once their output looks right, I save that and make the check part of the test suite. Anything that outputs numbers (e.g., the calculation of the size of the new image for a scaling operation) is just tested the usual way.
Other GUI stuff you can test by generating fake events and setting up mock collaborator classes to make sure things do what they should when they should.
And you can also take a just-the-essentials approach. For my web work, I test the underlying components extensively. I also have a web robot that hits a test copy of the site and makes sure that it all works well enough. I don't test every bit of HTML; I just make sure that important strings appear in the right place, that clicking through gets to where I think it should, and that feeding the right data to the right forms gets abuot the right responses.
Still, it's more of a pain than it should be. I look forward to the day that somebody develops a GUI framework test-first; those components will be much easier to work with.
Any faults that you have in your conception of your test program will be carried over into your module, or worse your module might be correct but your test program flawed
In practice, this isn't really a problem. As long as you write your tests first (rather than hacking them together afterwards) then they're a pretty good expression of what the code should do. Then the code itself is an expression of how to accomplish that.
Of course, it's possible that one has the wrong idea and makes the same mistake twice, but you use other practices to guard against that.
Seems like an extra layer of complexity rather than a useful method.
Maybe. My score for the last year or so is less than one reported bug per man-month of coding. And it's lower than that for my code written while doing pair programming.
I spend almost zero time hunting bugs.
Hi! I've been doing XP on and off (depending on client preferences) for a couple of years.
I'm immensely happy with it. It's not a magic bullet, but gives me the tools to solve a lot of common problems.
Does the reliance on incremental development and refactoring rather than a intricate, up-front design really work, or result in a big wad of band-aids?
Yes, it works. It takes a bit to learn how to do it well, but it works.
Indeed, in some ways, it works better. When I did most of my designing up front, I had to guess about a lot of things. Now I'm a pretty good guesser, but I'm not perfect. And since I knew I was making designs that I had to live with for years, I tended to play it safe, putting in things that I would probably need someday. I hoped.
Now, I don't put anything in until I know I need it. This keeps the design cleaner, and saves me all of the time I would have spent on bad guesses and things obsoleted by changing requirements.
Is pair programming OK, or do you sometimes get stuck with the nitpicker from hell who has to have every detail his own way?
I like pair programming a lot, and more people are good at it than you would expect. But some people are indeed pains in the ass; just last week we had to sit one guy down and have The Talk with him. If he doesn't shape up, he can go be a nitpicking cowboy on somebody else's project.
Right now I'm also doing some solo work, and it really suffers from the lack of a pair.
Is close involvement with the customer good, or does it just give them daily opportunities for endless bright ideas that prevent convergence?
It can work really, really well. The trick is that you must let them steer the project, so that they can see that asking for all sorts of random stuff means that their precious project will be screwed.
For example, I and another fellow were recently called in to work on a project that was six weeks from delivery and running late. The product manager handed us a one-page spec, spent 30 minutes showing us the existing code and said, "So can you do that in time?"
Now the only honest answer was, "I dunno, but probably not with all that you've asked for." But we walked him through the XP practice known as the Planning Game, where we broke his requirements down into bite-size chunks, wrote them on index cards, and then he ordered them by importance. There was far more work than could be done in time.
So then we asked him to draw a line at the point which, if we didn't reach it, he would slip the date, and if we did, he would ship. It cause him great pain, but he did it. Then we agreed that we would start developing and see how things were progressing.
As time went on, he, like any client, had all sorts of great ideas, and so did we. Every one got written on a card, and we asked him to place them wherever he wanted in the stack. This forced him to make tradeoffs; the more stuff he put in before the release, the farther away the release would be.
When the six weeks were up, we shipped a product with less than half of what he originally asked for. But instead of being pissed, he was happy! He got the half that was most important to him, and he was the one who made every choice about scope, so it wasn't our fault, that was just how things were.
And best of all, because we'd stuck to the XP practices and done extensive testing, there have been no bugs reported against our code. With code that solid, we're glad to start extending it, instead of the usual pattern where a big deadline push means the code is crap.
So yes, I like XP a lot. I get to write good code, polish the design, and have good relationships with the business folk. It rocks!
So, write your tests first. But do your design before you code, not after you've put together a thousand lines of crap.
If you've written 1000 lines of code before you refactor, you're waiting way too long. I do little refactorings every few lines, and bigger ones whenever things don't look right.
Look at it this way: you can do your design before you code, while you're coding, or afterwards. The waterfall advocates about 80:20:0. But that assumes that you learn nothing, think of nothing when coding. That's stupid; instead, what people do is grumble and imagine what they'll do in the next version.
Now that I'm doing test-driven development, my ratio is about 20/30/50. I still do some design up front, and that's very valuable. But instead of having those raging arguments about what design might work best, we start building and find out, refactoring towards the best design as we go.
Waiting until you've cobbled something together that passes the test and then hoping that your boss will allow you to refactor is a loser.
If a boss is such a micromanager that he's telling you which lines of code to work on every 15 minutes, then it's time for a new job. The people I work for recognize that I'm a professional and trust me to tend to my business, especially given how willing I am to explain it to them.
When bosses ask about refactoring, I explain that we do it so we can go faster. If they think it's a net loss, then I am always glad to prove them wrong: if they want to measure productivity each month, we can see which way works better.
Think of it this way: not refactoring is like not exercising: you get slower and slower, everything gets creaky and unreliable, and you die sooner because your arteries are clogged. A little regular exercise keeps you healthy, limber, and active.
Which level do you run the tests at? Best to test all levels, of course. [...] But once you've run all that, it is very difficult to pinpoint the source of the problem.
It sounds like your unit tests are too coarsely grained, possibly because your APIs are too monolithic. Try breaking things down some.
Generally, I write a couple lines of test code and then a couple lines of production code to make it pass. Then I rarely have problems testing the things I want.
Feel free to drop me a line if you have questions; I've done a lot of testing of XML and HTML.
but after skimming through the first 5 chapeters of 'Planning XP'
If you're a programmer, that's the wrong book to start with. Read Extreme Programming Installed, by Jeffries, et al.
I'm starting to think that XP really is just one big hot air balloon.
In my experience, it's not. Since adopting it a couple years back, my designs are better, my bug counts are much lower, and I am much happier. Feel free to drop me a line if you have questions.
Refactoring is improving the design of existing code. So yeah, they're just going for buzzword value here.
Since the .Net framework was released, VB is now every bit as powerful as the "real" languages.
Yes, now that they've made it Java, it is indeed just as good as Java. It's a shame that they didn't look at taking a major step beyond Java, though.
But still I'll skip it for now; anybody that takes seven versions just to get a language out of the "sucks majorly" zone isn't somebody I'm going to trust right away.
I would imagine there are a lot more jobs for VB than there are for the languages you listed as should be required (Eiffel, Lisp, Icon).
True, but unrelated to getting an education. Nobody buys CDs of people singing scales, but nonetheless, you gotta sing scales.
I do the same thing with my shorts...download away!
If you've figured out a way to download your shorts, there a lot of people in the porn industry that would like to talk to you, especially given EBay restrictions on these sorts of things.
After a lot of research, I also picked the Treo 300. Since I've been using a Palm since the first model, I was inclined to stay with the Palm platform, so I didn't look at the PocketPC items much. Previously I used a Palm V and a Nokia 6190, both of which I liked a lot.
It works well as a phone. For me in San Francisco, the coverage is good, and Sprint's network sucks a lot less than Cingular's did. It feels a little weird against your head, but you get used to that. It doesn't feel as tough as my Nokia, which worked well despite plenty of abuse. And it's great having all of my contacts right there, rather than the 30 or so that would fit into the Nokia's memory.
The always-on, flat-rate data connection is just ok when compared with a desktop, but fucking great compared with not having it at all. It's really nice to be able to use Mapquest on the road, to check my email from airports without paying $8 for the opportunity, and to be able to read the news when I'm loitering. And having Google in your pocket comes in handy more than you'd think.
As a PalmOS PDA, it seems fine. I too would like some expandability, but the built-in 16 MB of RAM is more than enough for everything I've wanted to put on there. One Linux caveat: the USB Sync cable for the Treo 300 doesn't work with current kernels; you must buy the serial cable, too. (It's only the 300 that has this problem; the other Treos don't.)
Battery life is an issue; you certainly should charge it every night. Given that, it's fine.
Overall, I'm very pleased with it. It's nice not to have to carry two devices around anymore. The only real drawback is that everybody who sees it wants a demo. I recommend it without hesitation!
Personally I think think they should get some sort of moderation system up ASAP ... there are a lot of people out there who just like to break things for the fun of it.
Yes, people always say that about Wikis. But it turns out not to be necessary.
Note the announcement: Wikipedia has been up for two years. It has 100,000 articles. They have made it this far without traditional notions of moderation. Ward's Wiki, the original one, has been around for much longer, and it's just a bunch of pages.
So all ye who think that moderation, access control, and similar dominance hierarchies and territory markers are necessary, think again.
Wrong. [...]Have you not been paying attention?[...] drowning a baby because it cries is an obvious solution
Oops! Sorry! I mistook you for a reasonable person. Sorry to have wasted your time. If you want to actually want to discuss this stuff, you know where to find me.
Yes, but twitter argued that Microsoft got where it is through illegal or unethical behavior. I assert that this isn't true.
Assert away. But federal courts have repeatedly found otherwise. Given the amount of money Microsoft spent on lawyering, it's hard to say they didn't get a fair trial.
big and it seems strong from the outside, but there are barbarians at the gate just waiting to get in
And they will likely keep waiting. Most serious competition Microsoft has seen in their core businesses (OS and Office) have been seen off by use of monopoly power. The only notable exception, Linux, is free. That's not exactly encouraging the barbarians to get out the ladders and catapults for the big assault on Fortress Microsoft.
Ironically, Microsoft's biggest competitor is Microsoft. [...] But whatever the situation, the fact remains that we (as a culture) have never come up with a good way to keep companies from getting too big, or to make them small again once they've gotten too big.
Well, actually, we have. And you even suggested it again here. If Microsoft is too big for anybody else to compete with, then breaking them up is an obvious solution. If they, as they claim, aren't illegally using their monopoly powers, then this won't hurt much. And it might even help Gates's bank balance: the market value of conglomerates is often higher after breakup.
Many will, but I don't think this one need go.
To keep development work here, we must exploit the one advantage we have over people 10,000 miles away: we're closer. Sure, that sounds too simple. But hear me out.
The traditional dominant development process, the Waterfall, assumes that you can put every important fact about a piece of software into a requirements document. That document is then turned over to the geeks, who could be kept in a sealed room, for construction. N months later, perfect software comes out.
We all know this is bunk. And not just from practical experience; if the requirements document really had all the needed information, then you could just write a requirements document compiler and dispense with the programmers completely. But it's the bunk that allows outsourced development companies to work. Not just because it allows them to pretend a development center on the other side of the planet is just as good. Even worse, because we believe this bunk, their development centers are just as good as keeping the engineers in the building (or city, or state) next door, as is common practice here.
So what should we do instead? We should pick development methods that take advantage of the highest-bandwidth, lowest-latency communication available to us: physical presence. If we put the engineers in the same room as the domain experts and the product managers, then we can build software more quickly and more efficiently than before.
But we get more than that. If you put everybody together, then you get unmatched ability to respond to change, change in the market, in your customer needs, in your competitor's products. A bunch of people in a room can turn on a dime compared with the difficulty of changing specs, changing contracts, and updating people who are asleep when you are awake. Even better, you can create change, forcing your competitors to try to keep pace with you.
So for those interested in keeping at least a few develoment jobs in the US, check out the book Agile Software Development Ecosystems (prices). Or look at one of the many Agile methods directly:
And for the record, I think world trade is great. If somebody in India can really do my job for 1/10th as much; then I should find something new to do, something that provides matchable value to my clients.
Trust me, these folks are VERY concerned about their careers and their industry. They are also very concerned about quality.
Wipro may be. I have been hired to review three Indian outsourcing efforts; they produced garbage. My sample size is small, and I'm sure there are good Indian outsourcing companies. But there sure are bad ones.
Which is why we should be worried. It's why we should strive to produce better code and strive to do it quicker.
For those actually serious about this, consider trying the practice of Test-Driven Development. The basic notion is that you write a few lines of test code, and then write the production code that makes it pass. Then do that over and over again, running your whole test suite regularly.
This improves quality immensely. That's not just because you get a test suite with 100% coverage. It also forces you to design things more simply and carefully, resulting in much better design.
In my experience, it takes no longer than regular development, as you cut out a lot of debugging time. And you end up with a comprehensive test suite for free.
If you don't like a competitive market, that's just fine. You're a grown-up (presumably) who is entitled to his own opinions. But a competitive market is what we have, and companies like Microsoft and Wal-Mart bubble up to the top because they're really good at being competitive.
You're missing two important things here.
One is that once a company has a monopoly, the standards for their behavior change. Things that were legal when they had 10% of the market are not legal when they have 95% of it.
And the other? As you say, the reason that we have a market economy is that it works well. The reason it works well is that strenuous competition forces continuous improvement for the consumer and the society at large. But once a company becomes so large that they need not fear others, then they stop feeling the pressure of competition.
Therefore, complaining about VB because there are idiots in the world isn't fair. ;)
Actually, I'm saying something a little different.
I'm saying that people are all idiots. The tools we build should reflect that.
One swell example is from years ago: a Chevette that a friend of mine drove. The car was a crappy, lightweight econobox. If you got into an accident at high speed, you'd be strawberry jam. That's fine; there's a place for low-budget cars in the world.
If you took this car at anything above 60 mph, it felt like the car could come apart at any moment. It felt dangerous. And, IMHO, that's exactly how the car should feel. It kept foolish teens like myself from going too fast.
Now compare that with many of the modern SUVs. These cars are designed to feel big and tough. But it turns out that they're just as dangerous to the drivers as your average mid-size (and even many of the small cars). And worse, they're twice as dangerous to the people you hit. But since the don't feel that way, people don't drive them as carefully as they should.
So VB is (or at least was last I used it) like a golf cart inflated to SUV size. It is really only safe for tooling around your subdivision, but it sure looks like it should be able to handle the autobahns.
It sounds like y'all are doing better than about 80% of the industry. Congrats!
But you should consider extending your test coverage further. Or, more accurately, testing smaller units.
I look at it this way: when I'm forced to use a debugger, that means that I don't really know what the code is doing. I have hypotheses, of course. So instead of setting breakpoints and examining values, I just start adding tests to check the hypotheses.
That way I get the benefit of my careful thinking not just when I'm in the debugger, but every time anybody runs the test suite.
I'm not entirely convinced by the "test first" philosophy. That's always struck me as more of a political point than a practical one.
You should give it a try, at least for a couple of weeks. It completely changes the experience of developing. But make sure to do it in very small increments: write a few lines of test, and then a few lines of production code to make it pass. Then repeat.
The feeling of confidence it gives you in your code is incredible. It is also more fun; your day becomes a hundred small victories. And because you're always working from the tests, interruptions just aren't a big deal. And most people find that it substantially improves their OO design, too.
Personally, I find it very practical. For something that's a page or two, I can just crank out the code and not worry about the tests. But for any serious project, I find the tests save me more time than they cost.
Excepting, of course, that Linux users are
- exactly the sort of people likely to get so excited over some networking functionality that they're likely to pay $400 for an otherwise merely adequate boom box.
- much more likely to have the permanent network connections and always-on computers that make a networked stereo more useful.
- the kind of local, informal expert that friends and family often turn to when trying to decide about a high-tech purchase.
- the same sort of person that friends and family turn to for tech support
- the kinds of people who will make all sorts of cool extra software for your consumer goods (e.g., see RockBox, open-source firmware for Archos MP3 players, or the bunch of stuff available for Turtle Beach's Audiotron.
So maybe instead of being a carefully calculated move on the part of Phillips, perhaps the product manager just had no fucking idea about the commercial value of an empowered user base.But they will. Consumer electronics companies compete on razor-thin margins. Any advantage they can get, they'll take, just as soon as they recognize it as one. Using open protocols are a free way to do that, and throwing in a little Unix glue is pretty cheap, too.
If you want to go as fast as possible, then you don't have time not to not keep things clean by writing good tests, integrating continuously, keeping in close touch with your coworkers, and refactoring whenever you see a way to improve the design.
In the very short term, say a week or two, you can improve your productivity by writing utter crap. But that's just storing up trouble; in effect, you borrow productivity from the future. But it's like borrowing from a loan shark: the interest rate is terrible, and the project ends up with broken kneecaps if you don't pay up pronto. If you're writing code that's only minorly crappy, then you build up cruft at a slower rate, but the problem's still there, and it will eventually lead to critical mass.
So yes, it is to nice to work in a world like that. And it yields better software faster, so it's great for the suits, too. My advice: either change your organization or change your organization.
In theory methodologies like this are good. In practice (at least in a startup environment) developers simply don't have time to follow such practice.
In a startup environment, everything you do will have far-reaching effects in the future. In a startup environment, it's much harder to predict where your company will go, as both investors and your customers will pull you in new directions. In a startup environment, people will be promoted so quickly that you can't assume that in three months they'll be around to support (or even explain) the code they're written. In a startup environment, missing a deadline or delivering buggy software an be fatal.
More directly: in a startup environment, you don't have time to do it in a half-assed way. Ergo, you should plan to do it right from the beginning.
And yes, I've just done this in yet another balls-to-the-wall, full-on-stealth-mode startup. The only thing the CEO regrets is that we didn't make him do it better.
Wow, you really hate VB. [...] I'd rather be working in C++ or even C, so take the following in context, ok? [...]VB *CAN* be used for relatively larger projects [...]
Oh, I agree. Any language that is Turing-complete (and some that aren't) can be productively used by a programmer who is sufficiently smart, careful, disciplined, and intensely aware of both the big picture and those who follow in his footsteps.
So if we were all omniscient, self-programming robots, I'd say that assembler was for sissies, that real programmers only had two keys on their keyboards: zero and one. And fuck the backspace.
Alas, programming is done by real humans, ambulatory sacks of meat, albeit with occasional fits of brilliance. Good toolsmiths know this, and make appropriate tools. People who make bad tools (like VB) are either fools or inhumanly cruel. I can never decide which explanation I prefer.
What if the fellow programmer walks in and catches you talking to a rubber duck? :)
When you tell him how many problems little Ducky has solved, your main problem is that he will try to steal your duck.
But if you're really worried about appearances, write Ducky an email about the problem. If by the end of the email you still are mystified, you can always send the email to a colleague.
poster I was replying to advocated that if code was written on paper (rock + chisel, ed, whatever) bugs aren't going to be created thus making debugging unnecessary.
If that were what he said, you'd have a point. But really, he never said, "never use a debugger,' just that programmers who learn to do without them are better programmers.
In my experience, he's right.
Test-driven development = debugging your own code if you see that you broke something, and to do that you do need debugging tools...
For you, perhaps. I ocassionally find a debugger convenient, but only slightly more convenient than inserting the occasional printf. Many experts in test-driven development say the same thing.
My point, though, is that spending much time in a debugger is a sign that there's something wrong elsewhere in your process. If you need to use a debugger, that means there's a problem and you don't know where it is. That, in turn, means that your test suite has got some pretty big holes in it.
Rather than wandering through in the debugger, you should add tests until you find one that is broken. Then not only do you find the bug, but you also make it so that the bug can never return.