and making spaceships run away from you instead of seeking you out in Nebulus: Ozone Riders.



I even asked Glitch, Wes, and Jonathan (teammates on the project) to remind me of some simple vector math and draw it out on the wet erase board for Nebulus. And I still made them go the wrong direction (which ended up being pretty cool, actually).

In other words, I haven't had much experience with AI as it's typically implemented in games, and what little experience I have had is limited to things I wouldn't (personally) classify as AI to begin with.

Still, I have had some experience in what I might call "classical" AI (perhaps "academic" is a better term). Stuart Russell and Peter Norvig wrote the Microsoft of books on Artificial Intelligence (90% market share for AI textbooks), and I've read through a fair bit of it. I've implemented a couple of algorithms, but mostly I've just been introduced to concepts and skimmed the algorithms. In addition, I've been through Ethem Alpaydin's book, Introduction to Machine Learning, which would have comparatively fewer ideas applicable to games.

I guess what I'm trying to say is: although I have some knowledge of AI, consider the fact that Dave's experience dwarfs my own when I disagree with him here: It is precisely the fact that we don't have enough processing power that gets in the way of more realistic AI in our games. Or, put more accurately, the problems we're trying to solve are intractable, and we've yet to find ways to fake all of them.

I'm not convinced you can separate the failures of AI from the intractability of the problems, or the inability to design and implement a machine to run nondeterministic algorithms for those problems in NP.

Compared to deciding how to act in life, deciding how to act in Chess is infinitely more simple: there are a finite set of states, and if you had the time, you could plot each of the states and decide which move gets you the "closest" (for some definition of close) to where you'd like to be N moves from the decision point. Ideally N would get you to the end, but even for Chess, our ability is limited to look ahead only a small number of moves. Luckily for Deep Blue (and others), it turns out that's enough to beat the best humans in the world.

Even though Chess is a complex problem whose number of game states prevent us from modeling the entire thing and deciding it, we can cheat and model fewer states - when we can make an informed decision that a particular path of the decision tree will not be followed, we can forgo computation of those nodes. Still yet, the problem will be huge.

There are other ways of "faking" answers to the AI problems that face us in development. Approximation algorithms can get us close to the optimal solutions - but not necessarily all the way there. In these cases, we might notice the computer doing stupid things. We can tweak it - and we can make special case after special case when we notice undesired behavior. But we are limited in the balance between human-like and rational. Humans are not rational, but our programs (often) are made to be.

Presumably, they give the policeman in GTA 4 a series of inputs and a decision mechanism, and he's thinking purely rationally: so sometimes the most rational thing for him to do based on the decision model we gave him is to run around the front of the car when he's being shot at. Sometimes he jumps off buildings. (Video via Sharing the Sandbox: Can We Improve on GTA's Playmates?)



It may not be smart, but it is rational given the model we programmed.

You can make the decision model more complex, or you can program special cases. At some point, development time runs dry or computational complexity gets too high. Either way, game AI sucks because the problems we're trying to solve have huge lower bounds for time and space complexity, and that requires us to hack around it given the time and equipment we have available. The problems usually win that battle.

Game AI has come a long way since Pacman's cologne (or maybe he just stunk), and it will get better, especially as we move more gaming super-powerful servers. Still, it's far from ideal at the moment.

What do you have to say? (Especially the gamer geeks: programmers or players)

But when I'm done, I get to look back on it with a sense of accomplishment. It's an accomplishment that goes above and beyond the typical new feature or bug fix. That's what I'm doing now.

I was just working on an ordering system where the calculations in one file came out to be a couple of thousand lines of code. It was taking forever - like hacking through jungle with nothing but a dull machete. Most of the small changes I was making resulted in new bugs being introduced to the system. As the number of bugs increased, it started to feel like a jungle. After a while I gave up.

I gave up on my quick-n-dirty add-another-hack-to-a-bunch-of-hacks approach and decided it was time to do something positive for myself, the code, and future programmers who have to touch it.

Extract method (or in this case, extract-template) came to the rescue. Just by extracting related bits of functionality I was able to get the file into manageable, largely cohesive chunks. I didn't go to the extreme: I stopped when it was good enough, touching only those parts I was prepared to fix if I broke them, which meant limiting it to what I was doing there in the first place.

The code isn't incredible, but it's in better shape than it was before I went in. Now, the main calculation file is about 1200 lines, and the other 800 are broken out into different, cohesive files. Forget about reuse, this was just for literacy.

What did you do to improve your codebase today?

By most standards, that's young.

And I know a thing or two about being set in your ways. We can all see the laugh I have at myself with the title here being "My Secret Life as a Spaghetti Coder" and some of the stories I've told as well.

In fact, let me add to the wealth of stodginess, idiocy, and all around opposite-of-good-developerness here:

I once said I preferred Windows to Linux. While that's not a completely shocking statement, the reason behind it was: I said I preferred Windows because 14 year olds work on Linux. Not because of any experience I'd had with it, but because of my fear of learning it.

Like with operating systems, your ignorance does not make a programming language suck. Although I've been tempted to say .NET sucks because of my early troubles with it, I've refrained, admitted my ignorance, and asked for help removing it.

Because of my prior experience being unwilling to learn, I was quite interested when I read this:

When you are young, you don't have that sense of self to protect. You're driven by a need to find out who you are, to turn the pages of your biography and see how the story turns out. If people around you are doing something you don't understand, you assume the problem is your inexperience and you go to work trying to understand it.

But when you are old, when you know who you are, everything is different. When people around you are doing something you don't understand, you have no trouble at all explaining why they are assholes mistaken.

. . .

If you want a new idea, you have to silence your inner critic. Your sense of right and wrong, of smart and stupid works by comparing new ideas to what you already know. Your sense of what would be a good fit for you works by comparing new things to who you already are. To learn and grow, you must let go of you, you must be young again, you must accept that you don't understand and seek to understand rather than explaining why it doesn't make any sense.

In a couple of paragraphs, Reg sums up almost precisely some of what I've been thinking and writing about for the last several months. He's so close, but misses a fundamental point: the old and young parts are incidental.

My hypothesis is that the level of learning and idea absorption you can attain has little to do with age. Instead, it is influenced more by your perceived level of experience. Normally, age is highly correlated to experience - but it doesn't have to be. In my case, when I was younger I thought I knew everything. Now that I've aged, I came to the realization I know very little.

My conclusion is not that different from Reg's, and this is not some scientific experimental contest, so let me explain why I feel the difference is worth noting: If we blame our reluctance to try new things on age, we are dooming ourselves to think of it as some unchangeable, deterministic process. By thinking of it in terms of perception of experience, we admit to being able to control it with more ease. (My belief is that we have control over what and how we perceive things.)

In other words, we lose our ability to blame anyone but ourselves. That's a powerful motivator sometimes.

Thoughts? Disagreements? Please be kind enough to let me know.

At this stage, if you've heard of Rails and you haven't converted, it's entirely possible that you never will. It's also entirely possible that anybody who still isn't even taking Rails seriously by this point might just be some kind of idiot.
...
Every programmer should also read Chad Fowler's "My Job Went To India" book, where he explains that as larger and larger numbers of programmers adopt a particular skill, that skill becomes more and more a commodity. Rails development becoming a commodity is really not in the economic interest of any Rails developer. This is especially the case because programming skill is very difficult to measure, which - according to the same economics which govern lemons and used-car markets - means that the average price of programmers in any given market is more a reflection of the worst programmers in that market than the best. An influx of programmers drives your rates down, and an influx of incompetent programmers drives your rates way the fuck down.

Instead, I want to talk about my first attempt at solving the puzzle, which was an utter failure. A glorious, spectacular failure. Perhaps the single most impressive failure of my career. Failures are often much more interesting than successes, but for some unfathomable reason, people are often reluctant to discuss them.

And this is just the beginning of the ceremony:

Me: read file blah.txt and display it on system output
Java: How should I name the class?
Me: Test
Java: How should I handle errors?
Me: I don't care right now, I just need to display that data to system output
Java: But I need to know this, what if something unexpected happens?!
Me: I just want to make a prototype damn it!
Java: Sorry, can't do it.
Me: Ok, do nothing on error.
Java: And which implementation of Stream class should I use for reading?

Everyone knows that diversification is the key to managing financial risk, but few people seem to apply this principal to their professional careers. Most developer shops are relatively limited when it comes to the number of technologies and problem domains they deal with. If you want to diversify your resume without job hopping every year, then it makes sense to actively seek out technology experiences that are different from the ones you use in your day job.

Neal Ford and others have been talking about the distinction between dynamic and static typing as being incorrect. The real question is between essence and ceremony. Java is a ceremonious language because it needs you to do several dances to the rain gods to declare even the simplest form of method. In an essential language you will say what you need to say, but nothing else. This is one of the reasons dynamic languages and type inferenced static languages sometimes look quite alike - it's the absence of ceremony that people react to.

I want to take exception to the notion that Python is adequate for a real programming project. The fact that 30K lines of code took 110K lines of tests is a real indictment of the language. My guess is that a significant portion of those tests are addressing potential errors that the compiler would have found in C# or Java. Moreover, all of those unnecessary tests take a lot of time to write, time that could have been spent working on the application.

In fact, many people were shocked at the amount of tests compared to code, and that's what the discussion (at least the part I was interested in) centered around. Four times as much test code as application logic is too much. It would shackle you, instilling fear in your heart and soul. No changes would ever be made with that kind of viscosity. Furthermore, tests can provide a false sense of security, a blankie, if you will.



You've got to be kidding. Having a test that will tell you when you broke existing functionality is pressure to avoid changes? To me, that's liberating!

Contrast that with not having a test to tell you when something broke. Does it even make sense to say having tests pressures you to avoid changes? Only if you fear having a program that works over having one that you think works.

Let me try a different approach. Take the following simple program:


There are four execution paths: One where both someCondition and anotherCondition are true, one where they are both false, and one each where one is true and the other isn't.

In other words, we have six lines of code and at least four tests we should write to cover all the cases. If each test is just a single line, we still need to write the method names and end lines, so that would give us three lines per test - for a total of twelve lines of test code.

The test code size is already double the number of lines in our application code for this simple, six line program with four execution paths. How many execution paths are in a 30 thousand line program?

Seeing as the number of execution paths in code is more likely to grow exponentially than linearly with each new line that gets written, 110 thousand lines of test code isn't actually all that much.

Further, the solution to the blankie problem is not "have fewer tests," it is to recognize that passing the tests is a necessary - not sufficient - condition of working software.

Following the blankie argument to its logical conclusion - that fewer tests mean you write better code because you are more careful - we should have no tests.

In fact part of the reason we want the tests is that we can make changes to the code with less fear of unknowingly breaking existing functionality or introducing defects in the software.

In the end, if someone is using the tests as a tool to do wrong, there is something wrong with the person, not the test. They will find another way to do wrong, even if we remove the tests from their arsenal.

Exceptions should be thrown when something exceptional happens. Maybe encountering a null value was at some time, exceptional. But in today's world of databases, form fields, and integrated disparate systems, you don't know where your data is at or where it's coming from - and encountering null is the rule, not the exception.

Expecting me to write paranoid code and add a check for null to avoid every branch of code where it might occur is ludicrous. There's no reason some sensible default behavior can't be chosen for null, and if I really need something exceptional to happen, I can check for it.

Really, aren't you sick of writing code like this:


when you could be writing code like this:


I think this is especially horrid for conditional checks. When I write if(someCase) it's really just shorthand for if(someCase eq true). So why, when someCase is null or not a boolean should it cause an error? It's not true, so move on - don't throw an error.

Someone tell me I'm wrong. It feels like I should be wrong. But it feels worse to have the default path always be the one of most resistance.

What do you think?

Naturally, I wanted to look for computer-related charities, and more specifically, those with a focus on programming. I first browsed a couple of charity-ranking websites and didn't find anything that I was searching for.

Everyone knows about One Laptop Per Child, whose mission is to educate children in developing nations, who otherwise wouldn't have as much of an education, by providing them with a low-cost, low-energy required laptop.

OLPC is not, at heart, a technology program, nor is the XO a product in any conventional sense of the word. OLPC is a non-profit organization providing a means to an end - an end that sees children in even the most remote regions of the globe being given the opportunity to tap into their own potential, to be exposed to a whole world of ideas, and to contribute to a more productive and saner world community.

On a bit of a smaller scale, I found Computers With Causes, which like so many charities who will let you donate your car, take your donated computer and turn it into good for charitable purposes. Mac Heist puts on a two week bonanza of a sale and donates proceeds to the charity you choose. That's a start, but we could do better.

There is another group, charityfocus, which lets you volunteer your time to help build websites for different charities. That certainly sounds interesting, and more to my point - but it's not quite there.

These are all noble goals, but I'm more interested in a cause that's closer to home, one where technology is not ancillary, but where it is part of the goal. So, I thought I'd do a domain search and start one myself. One of the domains I entered was code4cause.org, but it turns out they're already doing some good work. They don't teach children to program, but they do take on your IT projects and donate proceeds to charities.

I was surprised I wasn't able to find more than what I did. Are programmers that selfish?

Of course not. We donate a lot of our time to open source, for one thing, and I'm sure there are plenty of us who have our favorite causes that aren't computer-related at all.

I like Code4Cause's mission - that would let programmers donate their time to projects and convert that into money to send to charity. But, Code4Cause is based in Europe and Asia, and I'm more interested in something closer to home (which for me, is the United States). What are U.S. software developers doing?

I don't know, but I wouldn't mind seeing something like Code4Cause in the US. Or, at least it would be nice if we could donate the money our time produces to whatever organization we chose. Ideally, I'd like to see something where programming is more of the point, but I'm not sure how it would work. Even if coding remained auxillary, something like Code4Cause would be still be great.

Anyway, where are the coding organizations? Do you know of any I haven't listed? Share them below. Interested in trying to start one yourself? Let me know privately, and if there's enough interest, maybe we can figure out how to start an organization, and what we'd like it to do.

Sorry I don't have any more answers - I'm just fleshing these thoughts out, and throwing them out there to see if it helps.

Why should I pay for the time you spend doing your own projects? You are free to have 20% of the time to yourself if you can take 20% pay cut (from Adedeji O.)

Did I understand you correct? You want to work on something that has no relation to your employer and still get paid by him?
...
I don't know the exact rates in the US, but, these 20% will easily sum up to more than 10,000 USD per developer per year. Would YOU really pay that for nothing? (from Christoph S.)

To be fair, Christoph did say that he's "not talking about time for personal and technical development and not about work related projects that MAY include benefit for your employer. I'm talking about working on 'my projects' and 'open source projects.'"

Here's what I had said that provoked the reactions:

I like the idea of Google's 20% time. I have other projects I'd like to work on, and I'd like the chance to do that on the job. One thing I'd like to see though, is that the 20% time is enforced: every Friday you're supposed to work on a project other than your current project. It'd be nice to know I'm not looked down upon by management as selfish because I chose to work on my project instead of theirs.

I wouldn't mind seeing something in writing about having a share of the profits it generates. I don't want to be working on this at home and have to worry about who owns the IP. And part of that should allow me to work on open source projects where the company won't retain any rights on the code I produce.

Calling it "my project," talking about who owns the intellectual property, and working on open source appear to be where I crossed the line. At Google, we see things like News and GMail coming from the personal time. What I stated could mean that a programmer for a bank's website that's done in ColdFusion could end up working on a GUI for Linux in C. It's rather hard to make the connection there.

First, I didn't mean to imply that the company would not own anything of any part of what I worked on. If I am willing to take a 20% cut in pay, then certainly I wouldn't expect them to own anything. What I was looking for is some equitable way to share what I create with my time. For example, I might take one day a week at work to build my new widget, but if I'm taking 2 days on the weekend to work on it, I ought to get more than a "thank you" if the project goes on to make hundreds of millions of dollars.

And, I was just saying there needs to be some way to allow me to work on open source software during that time. I don't know how the details would work, but there surely is an equitable way to deal with it. I certainly could have explained it better.

In any case, I don't expect that 20% of my time spent away from my main project translates to the project taking 20% longer, or 20% less profit or revenue or productivity for my company. The degradation may be linear if we are data entry clerks - if all we are doing is typing instructions given to us from on high (if the work is physical). But that's not typically what programming is about.

I'm not running a company though, and I've not done a study about such companies. If I were to do such a study, that would be my hypothesis, and what follows is what I would expect to see.

The great divide between average a good programmers is well-known. Let us suppose that an average programmer is being paid sixty thousand dollars a year. Let us also suppose that you have a team of good programmers at the lower end of the "good" scale - those who are 10 times more productive than their average counterparts.

Are you paying them six hundred thousand dollars per year? I'd be surprised if anyone said yes to that question. You may pay them more than average programmers, but not an order of magnitude more. Even if they are only twice as productive as the average ones, you aren't likely to be paying them enough to worry about 20 percent of their time compared to what you would be paying less-competent people and getting out of them.

But what does that have to do with anything? Suppose I don't have good programmers - what then? If all of your programmers are average or worse, 20% time is not justified in their salaries the same way it is for a good programmer. So what benefits would we expect to see for companies who provide some amount of unrestricted free time?

First, I think the cases where a developer does something unrelated with his free time will be rare. But even if what I'm choosing to work on in my time is the polar opposite of the company's direction, does the company still benefit from it?

I think so. Here are some ideas:

• The company can list projects it sponsors by paying developers to work on them. We've seen examples of companies hiring developers to work on open source projects. This has been especially prevalent in the Ruby community lately, where Sun hired the JRuby guys to work on JRuby, Microsoft hired John Lam to work on IronRuby, and Engine Yard hired Rubinius developers. Relevance uses a lot of open source software in their solutions, so to give back, they have Open Source Fridays.
  
  I would expect that allowing your developers that free time to work on anything would bring better developers your way. If I'm looking for a job and one company offers me unrestricted free time plus the same salary as you offer, who do you think will be my first choice?
  
  
• If your work is generally not all that interesting, letting your programmers have a weekly break to work on things that are more interesting will help retain them and keep their minds fresh for the real work. As I've noted before, I almost quit the industry altogether when I got stuck in the boring-development cycle.
  
  
• Working on open source software can make your existing developers better by interacting with other good developers and learning new things.
  
  
• Your developers are learning things and keeping up with the newest technology, allowing you to react to changes in the market place quicker than your competitors. (You might not make iPhone applications at the moment, but if I spent a couple of Fridays digging into the iPhone SDK, you might already have an application ready to go.)
  
  
• You might spin off new companies or departments based on products your employees are writing in their free time.

When I first read the reactions, I thought I did go overboard. But after some more consideration, I'm not so sure. Of course, we need a way to quantify and test these hypotheses to be sure what type of a positive or negative impact such a thing has on companies. But, I think it's very safe to say that going to a four day work week does not automatically mean we've lost 20% in one way or another. In the best of cases, it could mean gains in productivity if it allows you to attract better developers.

What do you think? I assume we can agree that a four day work week for thought workers would not necessarily translate into getting only 80% of the value they would normally output. I'm more interested in hearing what gains or drawbacks you can see in having employees take personal programming Fridays, or something like it.

For those who disagree with the idea entirely, what if we restrict it to open source projects the company utilizes in day-to-day work? What if we restrict it to projects the company can use as infrastructure or turn into products (as I understand Google's to work)? Would you feel better about it then?

The "Eight-Hour Burn" is another of the chapters in Chad's book that really stuck with me after I first read it. The premise is that instead of working overtime, you should limit each day's work to an 8 hour period of intense activity. In doing so, you'll get more done than you otherwise would. Our brains don't function at as high a level as possible when we're tired. And when we're working on our fifth 60-hour week, we're probably tired.

We may love to brag about how productive we are with our all-nighters [paraphrasing Chad], but the reality is we can't be effective working too many hours over a long period of time.



And it's more than just our brains being tired that should prevent us from working too long. It's the fact that when we know we've got so much extra time to do something, we end up goofing off anyway:

Think about day 4 of the last 70-hour week you worked. No doubt, you were putting in a valiant effort. But, by day 4, you start to get lax with your time. It's 10:30 AM, and I know I'm going to be here for hours after everyone else goes home. I think I'll check out the latest technology news for a while. When you have too much time to work, your work time reduces significantly in value. If you have 70 hours available, each hour is less precious to you than when you have 40 hours available.

That's why I'm in trouble when I work in Windows all day. I do work 12-16 hours most days between job, school, and personal activity (like this blog). I get burnt out every few weeks and have to take a couple of days off, but when I'm in MacOS X, at least my working days are very productive: I've got each task time-boxed and any time I spend reading blogs or news or just getting lost on the web is always scheduled.

When I'm in Windows with nothing to remind me but myself, I drift off quite a bit more easily. After all, it's only 6:30 in the morning. I've still got eight hours to get everything done (I'm leaving early to go check the progress on the house I'm having built).

The good news is that I've got an item on my longer-term to-do list to remedy the situation. Hopefully after reading this chapter again, I'll be more motivated to get it done. The bad news is, since it means working in Windows all day to get it done, I'll probably be off doing my best to read all of Wikipedia instead.

Anyway, how much do you work? Do you have any tricks for staying fresh and motivated?

Likewise, diagnosing a problem with, and subsequently changing a starter or alternator isn't a task that only automobile doctors should perform. These are relatively high-failure parts that shouldn't require taking apart the exhaust system to replace. That's the tinkerer in me talking.


Image courtesy Daimler-Chrysler via How Stuff Works

I am a software developer, but sometimes I don't want to act like one when I work with software written by someone else. Don't make me build your product from source. I'm not asking you to build it for me, and then email it to me. I'm just asking if it's possible for you to set up an automated build on all of the platforms where you intend your software to work.

I enjoy the ability to tinker with open source software, not the requirement to do so.

The situation is even worse for proprietary programs. If you're lucky, there might be a way to mess with the settings that satisfies the tinkerer in you. But if you're not lucky, you could do things like upgrade your operating system and have it break something in 3rd party code. Then you'll be at the mercy of that vendor to make their software run properly with your upgrade. In the mean time, you're stuck manually starting the software, or writing your own scripts to do it.

In the first release of an accounting package, I might expect to edit a text file to set my tax rate. But I better not have to do that in the ninth version. Moreover, if your software makes certain assumptions about its running environment and those assumptions are parts that are likely to fail, you better make sure I can change them in your program without tearing it apart.

In the end, I understand that for early versions of products, you might not have worked out all the kinks or even found its purpose or audience. I expect that as an early adopter, and when I take that plunge, I enjoy it. But once you're several years old and multiple versions in, I don't think it's too much to have certain expectations. At that point, your software should just work and make it easy to make small adjustments.

Tim broke his watch, and ...

Imagine my joy as I realized that I could make it 11:30 again, and go enjoy another lunch. Meeting at 3:30? No problem, just turn the hour hand up to 6:00 and go home! I can sleep as long as I want as long as I turn it back to 8:00 when I get to the office. All my work estimates are now "five minutes", and I complete them every time.

...

But people still try to mandate velocity.

My ultimate beef though is not a practical one. It's an idealogical one. We should encourage those who succeed to lead as examples for others so that they can see that success is something that's worth pursuing. The more successful people and companies we have in this country (or any country,) the more successful the economy at large will be, and the higher the standard of living we'll have. And individually, it's rewarding to see your ideas through to production, and moreso on a mega-scale.

Bill Gates has earned the right not to comb his hair on TV, and I'll bet that even Brooke Shields would like the same right. The cowering masses of admirers aren't what the real winners seek. They're a side effect of doing something that nobody else has done, and doing it exceedingly and emphatically well. Everyone admires Bill Gates, whether or not they'll admit it. He's a man of action, a man of success, and for some, the picture of what they can not aspire to be. They think that because they can never become like him that they should instead try to seize some of that which he has created (as in with lobbyists or legislation.) To slice off a chunk for those who will never do the things he has done, and will not lift a finger to that end.

That's where they're wrong. You can aspire to be as great as you like. You can pursue your path to the end of your days. Nobody is going to give it to you, and they shouldn't. It's the 'hard' part that makes it so great. If you don't make it to be as successful as you had aimed by the time you die, you won't be walking around cursing the fact.

.NET and Java are both prime examples of object-oriented programming gone stupid. Their class libraries have become so utterly huge that it becomes damn near impossible for an individual developer to suitably grasp anything more than a small portion of them.

Although they supposedly give more flexibility, something as essential as reading from and writing to a file becomes a hassle with .NET or Java. It's easy to get lost in whether we need a FileInputStream, or whether we should wrap a FileInputReader in a TextInputBuffer, and so forth. Give me fopen() any day.

Thoughts and discussion are always encouraged.

I've previously expressed my doubt that TDD makes an effective approach to algorithm design. More recently, I alluded to a some optimism towards the same idea. Then, in a comment to the same post, Dat Chu asked about using unit tests in algorithm design, also referencing something that Ben Nadel had said about asserting in code-comments how the state of the algorithm should look at certain points.

That all led to this post, and me wanting to lay my thoughts out a little further.

In the general case, I agree with Dat that it would be better to have the executable tests/specs. But, what Ben has described sounds like a stronger version of what Steve McConnell called the pseudocode programming process in Code Complete 2, which can be useful in working your way through an algorithm.

Taking it to the next step, with executable asserts - the "Iterative Approach To Algorithm Design" post came out of a case similar to the one described at the top. Imagine you're coming up with something completely new to you (in fact, in our case, we think it is new to anyone), and you know what you want the results to be, but you're not quite sure how to transform the input to get them.

What good does it do me to have that test if I don't know how to make it pass? The unit test is useful for testing the entire unit (algorithm), but not as helpful for testing the bits in between.

Now, you could potentially break the algorithm into pieces - but if you're working through it for the first time, it's unlikely you'll see those breaking points up front. When you do see them, you can write a test if you like. However, if it's not really a complete unit, then you'll probably end up throwing the test away.

Because of that, and the inability to notice the units until after you've created them, I like the simple assert statements as opposed to the tests, at least in this case.

When we tried solving Sudoku using TDD during a couple of meetings of the UH Code Dojo, we introduced a lot of methods I felt were artificially there, just to be able to test them. We also created an object where one might not have existed had we known a way to solve Sudoku through code to begin with.

Now, we could easily clean up the interface when we're done, but I don't really feel a compulsion to practice TDD when working on algorithms like I've outlined above. I will write several tests for them to make sure they work, but (at least today) I prefer to work through them without the hassle of writing tests for the subatomic particles that make up the unit.

But Chad Fowler (in the book) turns it around, saying that not much is expected of maintenance programmers. You just need to fix the occasional bug or add a small feature here or there. It really boils down to this:

[In a greenfield project,] when we don't have the constraints of bad legacy code and lack of funding to deal with, our managers and customers rightfully expect more from us. And, in project work, there is an expected business improvement. If we don't deliver it, we have failed. Since our companies are counting on these business improvements, they will often put tight reigns on what gets created, how, and by when. Suddenly, our creative playground starts to feel more like a military operation - our every move dictated from above.

But in maintenance mode, all we're expected to do is keep the software running smoothly and for as little money as possible. Nobody expects anything from the maintenance crew. Typically, if all is going well, customers will stay pretty hands-off with the daily management of the maintainers and their work. Fix bugs, implement small feature requests, and keep it running. That's all you have to do.

Moreover, after enough code is written, that new project isn't much different than your maintenance work. It's just missing the benefits.

Consequently, you've got a lot more freedom in maintenance to do as you will. Get creative. Spruce up the UI a little bit. Since you get to interact with your "customer" more often, "more people will know who you are, and you'll have the chance to build a larger base of advocates in your business."

On top of that, being responsible for the entire application, it's likely that "even without much effort, you will come to understand what the application actually does." In doing so, you're well on your way to becoming a domain expert.

As I've mentioned before in several of the "Save Your Job" series' posts, as of this writing, I'm working with a small company. So, not only am I a maintenance programmer, I'm a greenfield project programmer too. I've been known to wear more than one hat (As I'm sure many of you can say).

Because of that and the push to drive maintenance costs down - I don't get as many opportunities to get creative in maintenance as Chad suggests. That's a bit of a downer for me.

But he ends it on a motivational high note in the "Act on it!" section: Pick the most important aspect of your maintenance work and find a way to measure it. Make it a point to improve your performance in that area, and measure again. Continuously improve. It's more motivating than having the mindset laid out in the introduction to this post, and you'll likely raise a few eyebrows.

It seems obvious to me now, and may be to you, but before recently, I had never thought about it: you can use an iterative approach in designing new algorithms. In the past, I had thought the opposite - since as a unit, the algorithm would rarely have the ability to be broken into chunks for testing purposes, how could we break it into chunks for iteration purposes?

But with the latest one we've been working on, we were able to take an iterative approach in it's design.

The process went something like this:

1. Decide what it is you need to accomplish - not necessarily how to accomplish it.
2. Based on that, find the parameters to the algorithm that will vary in each invocation.
3. Fix the parameters, and run through the algorithm. This will be it's simplest version.
4. Go ahead and write it if you want - but be aware it will likely change dramatically between now and when you are finished.
5. For each parameter p, vary it and go through the algorithm keeping the rest of the parameters fixed.
6. When you've got that working, now you can start varying combinations of parameters. Always observe what your algorithm is outputting versus expected output, and fix it when it's wrong.
7. Finally, allow all the parameters to vary as they would in working conditions.
8. Clean it up, keeping its essence.

A final bit of advice: don't force looping when the code won't go there. The code I was working on could have had any number of nested loops, and I spent a long time trying to find the relationships behind the parameters and their depth in the loop structure, in an attempt to find a way to fix the number of loops (so we don't have to change the code each time we need another loop in the nest). It was quickly becoming a hard-to-understand mess.

Instead, take a few minutes to step back and look at it from a distance. Do you really need to be looping? In my case, not as much as I thought. Use recursion when the code wants to be recursive. (If you still really want to avoid recursion, you'll probably need to simulate it with your own stack - but why do all the extra work?)

That iterative approach to algorithm design worked for me. It turned what at first seemed like a daunting, complicated algorithm into just several lines of elegant, understandable code.

Do you have an approach to designing algorithms whose solutions you don't know (and to be clear - can't find via search)?

I've heard lots of programmers half-joking about creating "job security" with unmaintainable code. And, I've seen actual programmers attempt to do it. In every case, these people have become targets. Sure, it was scary for the company to finally let go of them. Ultimately, though, fear is the worst that ever came of it. Attempting to be irreplaceable is a defensive maneuver that creates a hostile relationship with your employer...

By contrast, being "replaceable should create an unhostile working relationship," Chad says. He also notes that if you're not replaceable in your current position, you can't move up the ladder.

You might like to imagine yourself as a supercoder, keeping your company safe from disaster, and that if you were gone, they'd be helpless. To combat this delusion, Chad suggests imagining the average impact of one of your co-workers leaving.

I'll wait while you imagine it.

Got it? Good. That's probably about the same impact you'd have. If your entire company's truck number is a 1, and you're one of the ones, then clearly that's not the case for you. If you are in that position, you should be doing something to reverse it. It's unlikely you're "so peerless that [you] in fact should be irreplaceable" (quoting Chad Fowler).

The best part of this chapter, though, is the story Chad tells about a powerful CIO in a powerful company:

He and his team (of which I was a part) were winning every award and setting every IT standard in the company.
...
[Yet] he professed to waking up every day and intentionally and explicitly reminding himself that he could be knocked off his pedestal any day. Today could be it, he'd say.
...
[Chad explains,] humility is not just something we develop so we can claim to be more spiritual. It also allows you to see your own actions more clearly... [The] more successful you are, the more likely you are to make a fatal mistake. When you've got everything going for you, you're less likely to question your own judgment. When the way you've always done it has always worked, you're less likely to recognize a new way that might work better. You become arrogant, and with arrogance you develop blind spots.

Deep words.

In my case, our truck number is a one. But we have so few employees, it's hard to get it much higher than that. Still, we're making moves in the right direction to increase our truck number so that we all share more knowledge about more of each others' positions. Our hope is that while one of us might not be able to take over for another (if for no other reason than lack of available time), we might have enough shared knowledge to train someone else to do it, without it being more difficult than it needs to be.

All that spaghetti code I wrote is slowing being shoveled into the dumpster. And we're skipping the recycle bin.

Kate hit the deploy button and started packing her things, getting ready to leave. Just a quick verification on the live site and off she'd be.

"Oh jeez, what's wrong now?" Kate asked herself. "Why can't anything just work?" All the unit tests had passed. All the integration tests had passed. All the acceptance tests had passed. All the tests-by-hand had passed. What was the difference between the test site and the live one?

The error messages were largely useless. The last time Kate was getting useless error messages, there was an issue with differences in credentials to AD, SharePoint, the database server, or any combination of them. Kate proceeded under that assumption - it had a relatively high degree of being correct.

Twelve hours into three rewrites (trying different strategies to do the same thing) and several hundred WTFs later, it finally hit her:

"OMFG," yelled Kate.

She noticed that it worked in Firefox, but not in Internet Explorer. After another round of WTFs and some time spent wondering why the different browsers caused a server error, and then some time wondering why SharePoint should error out on its own browser, she realized: The issue wasn't with her code at all - it never had been.

The form was supposed to be a normal form - nothing to do with ASP.NET at all. But ASP didn't care - it wanted to see EnableEventValidation in the @Page directive to let you submit your own form - but only through Internet Explorer.

Kate's story is a tragedy: the essential complexity of the problem took her a couple of hours, while the accidental complexity ate up twelve. It cost her a couple of pints and some good fun on the field.

Luckily, you can avoid twelve hours of useless re-work if you just learn the lesson from Kate Libby's horrific tale: isolate errors before you fix them. Otherwise, you might spend a ridiculous amount of time "fixing" the parts that already work.

And launch as soon as you can, so you start learning from users what you should have been making.
...
So when you look at something like Reddit and think "I wish I could think of an idea like that," remember: ideas like that are all around you. But you ignore them because they look wrong.
...
Here it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.

I've learned that developers who spend most of their time thinking about their project, rather than grueling over mundane tasks and busy work, do better. Their projects are stronger, easier to develop, and organized beautifully. These developers spend much of their free time doing things like evangelizing the MVC paradigm, reading non-fiction, and dining out. Their counterparts - those who fear the rush of extra web traffic, faulty error handling, and accidently falling into while() loops that never end - live in fear of their creation, dreading the day when it will turn on the parent.

Raganwald quotes Sam, who said

If you can provide a regular expression such that it actually matches the string representation of only prime (or only non-prime) integers, that would be pretty sweet. A proof that such a thing could not be created would be equally impressive.

(Sam also linked to a blog post that linked to another that constructed a regular expression to decide if the number of 1s in a string of 1s is not prime, or /^1?$|^(11+?)\1+$/.)

A couple of comments from people at Raganwald mentioned using the pumping lemma for regular languages to prove that such a thing was not possible.

Indeed, even determining if 1* is not prime (the regular expression above) can be shown not to be a regular language. Using the pumping lemma for regular languages:

1. Let the language L = { 1ⁱ, i is a number greater than 0 and is not prime }
2. Assume L is a regular language. Then, by the pumping lemma, there exists a number p >= 1 such that every string w in L of length p or greater can be decomposed into substrings w=xyz, where |y| (length of y) > 0, |xy| <= p, and for all i >= 0, xyⁱz is also in L.
3. Choose a string, w from L whose length is greater than p.
4. Since there are infinitely many prime numbers, we can find one greater than any p.
5. Therefore, we can choose an i in w=xyⁱz such that repeating it some number of times will be a prime. We arrive at a contradiction, and note that because w cannot be pumped, L is not a regular language.

Another commenter mentioned that "Regular expressions these days can match any context-free language through the use of sub-expressions." Clearly, since our language L is not regular, but it is matched by a regex, we can see that today's regexes are more powerful than regular languages would allow them to be. But, is our regex even restricted enough to be a CFL?

A similar proof using the pumping lemma for CFLs would show that our language L is more powerful than even a CFL. (Don't let me slide here if that's not the case.)

Still, that doesn't tell us anything useful for the problem at hand - only that the regexen of (at least) Perl and Ruby are more powerful than CFLs. But how much more? If we want to prove that a regular expression (in the practical sense of the word) cannot take a string representation of a number, (e.g., "13" or "256") and determine if it is not prime (or prime), then we need to know how powerful regex are.

But I don't know where to start on that front. Any ideas?

Alternatively, if we want to prove that it can be done, we need only demonstrate so by coming up with the regex to do it. I'm not convinced it's possible, but I'm not convinced it's not possible either. Ideally, I'd like to find the formal definition of how powerful regex are, and prove at least that we don't know if the language is in that class or not. (The pumping lemmas, for example, are necessary but not sufficient to prove membership of L amongst the respective class of languages.)

Comments are appreciated. I'm sort of stuck at the moment, so I wanted to bounce these ideas out there to see if someone might bounce one back.

Most of the problems you'll solve in your programming career don't require a lot of thought to arrive at a correct solution. But algorithms, data structures, and approaches to problems aren't just limited to the realm of programming. Reg Braithwaite reminds us of another reason to have these things at your disposal - even the problem of determining who to hire can be reduced to Naïve Bayes Classification.

And when you have those problems where there is no human solution (how can I discover patterns in several strings which may have hundreds of characters?), or the computer solution takes too long to find the optimal one where good enough will do, or there just isn't necessarily a right answer -- those are the hard ones where you aren't likely to stumble upon an answer -- where do you turn?

It turns out, a lot of problems can be reduced to others we already know how to solve. In fact, the basis of proving complexity class for an algorithm utilizes that: reduction of one problem to another will prove that if you solve the first one, you can solve the second one, and it will be just as complex. A famous example is SAT.

I haven't yet compiled the list I spoke of above, but luckily for all of us, Wikipedia has a good starting point. It's missing a couple that stand out in my mind (or that have a different name I didn't look for, or multiple classifications and it didn't make it to the one I looked at), but that's just something I can put on my to-do list to improve. The Machine Learning category, for instance, seems fairly light.

So just browsing a list and short description of algorithms may enlighten you as to how you can reduce your problem to one that's already been solved. If you can do that, you've got a solution from someone who's probably much smarter than you are. It's as if you have Donald Knuth and the rest of computer science academia on your team, and you don't even have to pay them (except, perhaps by buying their book, or subscribing to a journal that will disseminate their knowledge).

Thoughts?

I think the solution is to start under-promising and over-delivering, as opposed to how most of us do it now: giving lowball estimates because we think that's what they want to hear. But why lie to them?

If you're using iterative and incremental development, then if you've over-promised one iteration, you are supposed to dial down your estimates for what you can accomplish in subsequent iterations, until you finally get good at estimating. And estimates should include what it takes to do it right.

That's the party-line answer to the question. In short: it's never OK to write sloppy code, and you should take precautions against ever putting yourself in a situation where those viscous forces pull you in that direction.

The party-line answer is the best answer, but it doesn't fully address the question, and I'm not always interested in party-line answers anyway. The viscosity (when it's easier to do the wrong thing that the right thing) is the force behind the bodge. I don't like it, but I recognize that there are going to be times you run into it and can't resist.

In those cases where you've already painted yourself into a corner, what then? That's the interesting question here. How do you know the best places to hack crapcode together and ignore those things that may take a little longer in the short run, but whose value shows up in the long run?

The easy answer is the obvious one: cut corners in the code that is least likely to need to change or be touched again. That's because (assuming your hack works) if we don't have to look at the code again, who really cares that it was a nasty hack? The question whose answer is not so easy or obvious is "what does such a place in the code look like?"

By the definition above, it would be the lower levels of your code. But if you do that, and inject a bug, then many other parts of your application would be affected. So maybe that's not the right place to do it. Instead, it would be better to do it in the higher levels, on which very little (if any) other code depends. That way, you limit the effects of it. More importantly, if there are no outgoing dependencies on it, it is easier to change than if other code were highly dependent on it. [1]

Maybe the crapcode can be isolated: if a class is already aweful, can you derive a new class from it and make any new additions with higher quality? If a class is of high quality and you need to hack something together, can you make a child class and put the hack there? [2]

Uncle Bob recently discussed when unit and acceptance testing may safely be done away with. He put those numbers around 10 and a few thousand lines of code, respectively.

In the end, there is no easy answer that I can find where I would definitively say, "that's the place for a bodging." But I suspect there are some patterns we can look for, and I tried to identify a couple of those above.

Do you have any candidates you'd like to share?

Notes:
[1] A passing thought for which I have no answers: The problem with even identifying those places is that by hacking together solutions, you are more likely to inject defects into the code, which makes it more likely you'll need to touch it again.

[2] I use inheritance here because the new classes should be able to be used without violating LSP. However, you may very well be able to make those changes by favoring composition. If you can, I'd advocate doing so.

Stephen Skowronek, The Politics Presidents Make (pg. 39)

What these [reconstructive] presidents did, and what their predecessors could not do, was to reformulate the nation's political agenda altogether, ... and to move the nation past the old problems, eyeing a different set of possibilities... (Skowronek, pg. 38)

When the new regime starts gaining momentum, in the old regime there will be wailing and gnashing of teeth. We can see some of this in the dogma repeated by Ruby's detractors alluded to (but not sourced) by Daniel Spiewak. We hear it in the fear in people's comments when they fail to criticize the ideas, relying instead on ad hominem attacks that have little to nothing to do with the issues at hand.

(Unlike Obie, I don't have any reason to call attention to anyone by name. If you honestly haven't seen this, let's try i don't like ruby, ruby sucks, and ruby is slow and see if we can weed through the sarcasm, apologists who parrot the line so as not to offend people, or just those exact words with no other substance. )

There will also fail to be unity. Java is considering closures, and some want multiline string literals. There's talk that Java is done and that there should be a return to the good ol' days.

Neal Gafter quotes himself and Joshua Bloch in Is Java Dying? (where he concludes that it isn't):

Neal Gafter: "If you don't want to change the meaning of anything ever, you have no choice but to not do anything. The trick is to minimize the effect of the changes while enabling as much as possible. I think there's still a lot of room for adding functionality without breaking existing stuff..."

Josh Bloch: "My view of what really happens is a little bit morbid. I think that languages and platforms age by getting larger and clunkier until they fall over of their own weight and die very very slowly, like over ... well, they're all still alive (though not many are programming Cobol anymore). I think it's a great thing, I really love it. I think it's marvelous. It's the cycle of birth, and growth, and death. I remember James saying to me [...] eight years ago 'It's really great when you get to hit the reset button every once and a while.'"

To me, the debate is starting to look a lot like the regime change Skowronek's work predicts when going from a vulnerable establishment regime where an outsider reconstructs a new one.

I'm not saying Ruby itself will supplant Java. But it certainly could be a piece of the polyglot programming puzzle that will do it. It's more of an overall paradigm shift than a language one, so although I say one part is represented by Java and another by Ruby, I hope you won't take me literally.

Franklin Roosevelt was the candidate with "clean hands" at a moment when failed policies, broken promises, and embarrassed clients were indicting a long-established political order. Agitating for a rout in 1932, he inveighed against the entire "Republican leadership." He denounced them as false prophets of prosperity, charged them with incompetence in dealing with economic calamity, and convicted them of intransigence in the face of social desperation. Declaring their regime morally bankrupt, he campaigned to cut the knot, to raise a new standard, to restore to American government the ancient truths that had first inspired it.

Hoover's inability to take the final step in innovation and repudiate the system he was transforming served his critic's well... Hoover would later lament the people's failure to appreciate the significance of his policies, and yet he was the first to deny it. The crosscurrents of change in the politics of leadership left him with an impressive string of policy successes, all of which added up to one colossal political failure... Hoover sought to defend a system that he had already dispensed with...

Which one sounds like which paradigm?

• When I'm working with a new framework or technology and I don't know how to test it: I'm trying to avoid this now by learning languages by unit testing. However, it's still tough. I started writing tests in C# .NET recently, but moving things to ASP.NET has made me stumble a bit. That's mostly because I didn't take the time to understand how it all worked before I started using it, and now I'm in the process of rewriting that code before it becomes too entrenched.
  
  
• UIs: I still don't understand how to test them effectively. I like Selenium for the web, but most tests I write with it are brittle. Because of that, I write them flippantly. It's a vicious cycle too: without learning what works, I won't get better at identifying strategies to remove the viscosity, so I won't write the tests.
  
  
• Finally, and most of all: legacy code bases, with no tests and poor design. It's so much easier to hack a fix than it is to refactor to something testable. I've yet to read Michael Feathers' Working Effectively With Legacy Code, so that may help when I finally do. (You can find a twelve page PDF article @ the Object Mentor Resources Website.) At the minimum, it should help motivate me to follow the elephant more often.

That last one is a killer for me. When I'm working on new projects, it's incredibly easy to write tests as I develop. So much so that I don't bother thinking about not doing it. Unfortunately, most of my work is not in new code bases.

I should also note that I often don't bother unit testing one-off throwaway scripts, but there are times when I do.

On top of that, my unit tests rarely stay unit-sized. I generally just let them turn into integration tests (stubbing objects as I need them when they are still unit-sized). The only time I bother with mocks are if the integration piece is taking too long to run tests. For example, I might let the tests hit a testing database for a while, but as the tests get unbearable to run, I'll write a different class to use that just returns some pre-done queries, or runs all the logic except for save().

What about rewards?
In Code Complete 2, Steve McConnell talks about why it's important to measure experiments when tuning your code:

Experience doesn't help much with optimization either. A person's experience might have come from an old machine, language, or compiler - when any of those things changes, all bets are off. You can never be sure about the effect of an optimization until you measure the effect. (McConnell, 603)

I bring that up because I think of TDD (and any other practice we might do while developing) as an optimization, and to be sure about it's effects, I'd have to measure it. I haven't measured myself with TDD and without, so you can take what follows as anecdotal evidence only. (Just because I say that, don't think you can try TDD for a couple of days and decide it's slowing you down so it doesn't bring any benefit - it takes a while to realize many of the benefits.)

So what rewards have I noticed? Like the problems I've had, there are a few:

• Better design: My design without TDD has been a train wreck (much of that due to my past ignorance of design principles), but has (still) improved as a result of TDD.
  
  After all, TDD is a design activity. When writing a test, or determining what test to write next, you are actively involved in thinking about how you want your code to behave, and how you want to be able to reuse it. As a byproduct of writing the tests, you get a very modular design - it becomes harder to do the wrong thing (bad design), and easier to keep methods short and cohesive.
  
  
• Less fear: Do you have any code that you just hate to touch because of the horror it sends down your spine? I do. I've had code that is so complex and wrapped up within itself that I've literally counseled not changing it for fear of it breaking and not being able to fix it. My bet is that you've probably seen similar code.
  
  The improved design TDD leads to helps that to some extent obviously. But there may be times when even though you've got a test for something, it's still ugly code that could break easily. The upside though, is you don't need to fear it breaking. In fact, if you think about it, the fear isn't so much that you'll break the code - you fear you won't know you've broken it. With good tests, you know when you've broken something and you can fix it before you deploy.
  
  
• Time savings: It does take some time to write tests, but not as much as you might think. As far as thinking about what you want your code to do, and how you want to reuse it, my belief is that you are doing those things anyway. If not, you probably should be, and your code likely looks much the same as some of that which I have to deal with (for a description, see the title of this weblog).
  
  It saves time as an executable specification - I don't have to trace through a big code base to find out what a method does or how it's supposed to do it. I just look up the unit tests and see it within a few clean lines.
  
  Most of your tests will be 5-7 lines long, and you might have five tests per method. Even if you just test the expected path through the code, ignoring exceptions and negative tests, you'll be a lot better off and you'll only be writing one or two tests per method.
  
  How long does that take? Maybe five minutes per test? (Which would put you at one minute per line!) Maybe you won't achieve that velocity as you're learning the style of development, but certainly you could be there (or better) after a month or two.
  
  And you're testing anyway, right? I mean, you don't write code and check it in to development without at least running it, do you? So, if you're programming from the bottom up, you've already written a test runner of some sort to verify the results. What would it cost to put that code into a test? Perhaps a minute or three, I would guess.
  
  And now when you need to change that code, how long does it take you to login to the application, find the page you need to run, fill out the form, and wait for a response to see if you were right? If you're storing the result in the session, do you need to log out and go through the same process, just to verify a simple calculation?
  
  How much time would it save if you had written automated tests? Let's say it takes you two minutes on average to verify a change each time you make one. If it took you half-an-hour of thinking and writing five tests, then within 15 changes you've hit even and the rest is gravy.
  
  How many times do you change the same piece of code? Once a year? Oh, but we didn't include all the changes that occur during initial development. What if you got it wrong the first time you made the fix? Certainly a piece of code changes 15 times even before you've got it working in many cases.

Overall, I believe it does save time, but again, I haven't measured it. It's just all those little things you do that take a few seconds at a time - you don't notice them. Instead, you think of them as little tasks to get you from one place to another. That's what TDD is like: but you don't see it that way if you haven't been using it for a while. You see it as an extra task - one thing added to do. Instead, it replaces a lot of tasks.

And wouldn't it be better if you could push a button and verify results?

That's been my experience with troubles and benefits. What's yours been like? If you haven't tried it, or are new, I'm happy to entertain questions below (or privately if you prefer) as well.