So how cool is this? I'm working on a project right now that involves the design of a handful of parsing algorithms. (I'd be more explicit about what exactly the project is, but because of the nature of the company, I'm obligated to keep things quiet.)
For the past few days I've been drafting and coding possible solutions to some of these tricky problems. Nothing ground-breaking, but challenging enough that I readily admitted to myself that I didn't already know the solution off the top of my head. This alone was a nice change of pace, as I had been designing the same applications over and over again for the past few years -- I was getting pretty good at them -- but finding a hard technical problem was like uncovering a gem hidden amid the gravel.
As I'm working away on one of the problems, I adopted my usual approach -- I design something I am fairly certain will work and give the "correct" results, but also note down that it isn't an optimal solution, and move on. Doing things this way allows me to fit the pieces together and concentrate on high-level design while at the same time moving toward a proof-of-concept and demonstration of the system. In fact, in a large number of cases those temporary solutions prove "good enough" in a real-world environment to keep in the production version.
Note that this approach is somewhere in-between a top-down and a bottom-up design. I don't have the entire system and every API formalized and documented before I am willing to write code. Nor do I attempt to perfect the underlying algorithms before fitting the pieces together. Rather, I do a bit of both, keeping track of how the whole thing fits together while digging in and implementing real methods.
One thing to keep in mind here is that every method, every class, and every bit of code, is written to be production quality. These aren't hacks, intended to be ditched. Rather, I'm writing unit tests and documenting as I go. I'm refactoring as I work. They may be sketches, but those sketches may very well turn out to be good enough to display to the public, and I do not want to be in a position where I have to say "well, sure it looks like it works, but really, I need to go back and rewrite this part and that part because it's ugly." That would be a waste of my, and the company's, time. So I do my best to design and write for production, even if I recognize that a particular piece could be improved (and even know exactly what needs to be done to improve it).
This type of trade-off -- i.e., using a middle-out methodology rather than a top-down or bottom-up methodology -- is not something I would blindly recommend for all people. For some, they might find that they don't have the experience necessary to intuit how all the pieces will need to fit together from the start. For others, they may not want to take the time to write production-ready code that might get thrown away. I'm lucky in that I've spent almost the past ten years doing this type of architecture so I have a bit more confidence with which to attack the problem. Someone starting out at this may want to tackle the parts they are most comfortable with, and not shy away from asking other people for help on the parts they are unsure of.
Which brings me to the point -- this morning I hit a bit of work that slowed me down. I began to suspect that the brute-force algorithm I was writing was not only sub-optimal, but potentially harder to implement than the real solution. However, the real solution wasn't quite in my grasp. And I saw that it would take a fair bit of reading and thinking to get a hold on the best way to solve the problem. And there would probably be a few mis-steps along the way. Yet I wanted to have a deliverable by the end of the week. (And setting frequent, demonstrable milestones is absolutely key is succesfully shipping a product on time.)
In some of my past gigs I haven't had too much access to people with the background necessary to help out with these types of computer science problems. Sometimes there simply haven't been people like that (i.e., C.S. PhDs) around me, and on the occasions that there have, sometimes the workload and culture hasn't afforded the luxury of taking even ten minutes to discuss a tricky problem that isn't in one's day-to-day obligations.
This time, however, I just got up from my desk, walked through the open door next to mine and asked the CEO of my company if he could help me with my algorithms homework. (An inside joke, as he literally wrote the textbook I used in my undergraduate algorithms course.) And, just as I hoped, we went to the white board and sketched out a proper solution. My instinct had been leading me in the right direction, but that could easily have not been the case. And he filled in the missing bits of how to make it work off the top of his head. And when I had questions about it he immediately adopted the role of a teacher, not a manager.
Asking for help on this type of problem is a luxury. But it's a luxury that I don't have any reservations about taking advantage of. I have probably spent far to much of my career trying to make a case for how strong a developer and architect I am, and far too little time learning from other people. I'm even tempted to suggest that I should have gone to work for a company like this long ago. Then again, I probably wouldn't have even been able to get a job like this before, as the years of making it up as I went along taught me some lessons that helped me land the gig.
But either way, as long as things stay the way they are, I can't imagine doing it any other way.