Hitting 1000 miles a year!

I have been biking back and forth to work regularly, as well as running every other day during the week. I have managed to make this a schedule over the last few months. Here is a casual estimate of my walking and biking distances (in miles) a year based on this current practice: 

• Biking back and forth to work
• 5 days a week, approximately 2 miles each way, for a total of 4 miles per day and 20 miles per week.
• Running three days a week
• Approximately 2 miles every session, for a total of 6 miles.

The above adds up to 26 miles in a week, which is 104 miles a month, leading to 1248 miles a year. Assuming I stick with this routine for the whole year, doesn't seem too bad for a cs+math geek, eh!

Pair Design

A lot of times, when writing software, a pair programming approach is used. It's an agile software development technique in which two programmers work together at one workstation. At any time, one is the "driver" and the other "navigator", and the roles are switched at intervals. Basically the "driver" is writing the code, and the "navigator" is simultaneously reviewing the code in progress.

I got introduced to this approach during my undergraduate, and we had to use this approach whenever we were working on an assignment in groups of two. Pivotal labs seems to be using pair programming approach quite effectively. I am not sure which other companies use this approach, but it seems the pair programming idea can be extended to the design process as well.

Generally an engineer (let's call this engineer the primary engineer) gets a task, maybe fixing a bug, improving a feature, or building a new API, all of which involves thinking and designing a solution. The primary engineer designs the solution, and the paired engineer is there to discuss the solution, address any limitations, good parts, and improvements before coding commences. The paired engineer will be a sounding board for the primary engineer to think aloud about the proposed solution. Of course, the roles will be reciprocating.

I am not saying don't evaluate designs as a team, this is very valuable, and is usually reserved for something significant. But for day to day design of solutions, having an assigned sounding board can help the primary engineer to think aloud about the problem. Each paired design partners will rotate, maybe every sprint, for example. This way, each team member will also get a chance to work with others, and an informal review process for designs will naturally set in.

Just a thought.

Switching to using MathJax for LaTex support

I reset my LaTex support in blogspot to use MathJax. Looks like it is rendering, $$A = B^T$$

Setting up LaTex support using MathJax is straightforward. Just put the following script before the </head> element in your blogger template.

<script type="text/javascript" src="http://cdn.mathjax.org/mathjax/latest/MathJax.js">
MathJax.Hub.Config({
extensions: ["tex2jax.js","TeX/AMSmath.js","TeX/AMSsymbols.js"],
jax: ["input/TeX", "output/HTML-CSS"],
tex2jax: {
inlineMath: [ ['$','$'], ["\\(","\\)"] ],
displayMath: [ ['$$','$$'], ["\\[","\\]"] ],
},
"HTML-CSS": { availableFonts: ["TeX"] }
});
</script>

14 Design Lessons Learned from Berkeley DB

The original article can be found here, but I wanted to put together a summary list of the design lessons in the article for later reference for myself.

1. Software should be designed and built as a cooperating set of modules. Each module should have a well-defined API boundary, which can (and should) change as needed, but a boundary is always present.

2. Software design is a way to force oneself to think through the entire problem, and it is really worth thinking through before writing code.

3. Software architecture will degrade over time, there is no way around it.

4. Naming (variables, methods, functions, etc.) and coding style should be consistent, since good naming and formatting provides a lot of information. Failing to follow expected coding conventions should be considered a significant offense.

5. Make upgrade decisions carefully. Consider carefully minor updates to major releases.

6. In designing a library, respect namespace. Do not make engineers put in an effort to memorize reserved words, constants, etc. just to get your library working without naming collisions.

7. Make functionality shared if they appear more than once. Write a test suite for general purpose routines. If the code is difficult to write, write and maintain it separately so that other code cannot corrupt it.

8. Use encapsulation and layering, even if it seems unnecessary. Life will be easier down the road.

9. Think stability over increased concurrency.

10. If one is thinking of writing special purpose code to handle something, step back and see if things can be simpler.

11. If one doesn't have the time to make a change right now, then one won't find the chance later.

12. "...Every piece of code should do a small number of things and there should be a high-level design encouraging programmers to build functionality out of smaller chunks of functionality, and so on..." (from Berkeley DB article)

13. Every bug is important.

14. "...Our goal as architects and programmers is to use the tools at our disposal: design, problem decomposition, review, testing, naming and style conventions, and other good habits, to constrain programming problems to problems we can solve...." (from Berkeley DB article)