AprilandJake.com

Vote for my app!

(Part of the 10k Apart contest)

Update

By 6pm MST on the 25th, voting ended up totaling 110 votes, scoring a solid 3.8 out of 5 star average, thanks to you. And apparently you can continue voting, so go a click mucho stars. You guys are all awesome!

Update2

We broke the 4 star barrier on the final day of voting.

As you may well know, the new Mormon.org has been released for a couple weeks now. Here are a few interesting links for reaction from various sources:

News
ABC
KSL
SL Tribune
Deseret News
Standard.net
LDS Newsroom
Examiner
KCSG

Blogs
MormonMatters.org
Rickety.us
Beliefnet.com
Latterdaycommentary.com
Jozhaus
SymphonyofDissent
Thejakers

(via @gilbertlee)

The last link is a pastor with some stewardship over church communication who has some interesting comments about what we "can learn from the Mormons." He believes little doctrinally, much marketing'ly. I believe that the living waters of revelation from God are found in The Church of Jesus Christ of Latter-day Saints, given to his prophets and personally to all seekers of truth. I did, however, find his article very interesting from his point of view.

Dev and QA teams for the new mormon.org. Good times, especially those had during the light of day!

Today was launch day. (and test day and debug day and day of much eye strain -- not recommended)

Software engineers are sometimes very, very prone to making things more complex than they need to be. In the engineer's mind, "complex" can be replaced with the word "cool" (or some other amazing adjective). Such a mind has gotten lost, has lost sight of the fact that there exists a most-efficient path from the problem to the solution. Such a predicament is not uncommon -- probably because of something physically wrong in the engineer's mind; And because a certain amount of tinkering is usually required to begin work toward a solution. But, when one becomes enveloped in the problem and forgets about the priority of actually solving the problem, large, unrecognizable apparatus are concocted.

I recently read Release It! by Michael Nygard. I became interested in this book when the NFJS 2008 panel cited it as their #1 suggested read. In my view, the essence of Nygard's expose boils down to two points:

1. One can build software that passes QA with flying colors and still fails miserably in real environments.
2. Problem in production are unavoidable. Good software will be able to navigate them as gracefully as possible.

That said, the book was mostly conceptual, offering real-world examples of how antipatterns in software development made problems that were encountered even worse. Then, he counters with patterns in stability, capacity, general design, and operations. The principles discussed are those that most developers have at least some exposure to, but those that we don't necessarily consider every day. These consist mostly of non-functional requirements that do not often enjoy QA scrutiny. The set of antipatterns and patterns is one that I think all developers, QA, and project managers would do well to consider within the scope of their current and future projects.

Overall, it was a thoughtful book. I particularly enjoyed the sections on capactiy and stability that seemed more immediately applicable to my everday life in code. I found the operations section to be the driest, but giving me opportunity to consider the plight of sys admins. I would agree with the NFJS panel and highly recommend the read.

I have included a short slide deck on the stability section with some highlights on what one might consider and what is explained in much clearer detail in the book.

In software development, be dry, and define data once. But, what if that data needs to be used in many places? This is the case with parts of a web page, for instance, that are common to many different pages. Django has a great mechanism for this: it is context processors.

Recently, I've been appalled at a stated software development management strategy: slow down your development. To aid slowness, perhaps we could:

1. Pair keyboarding
2. Use Windows
3. In addition to kickoff and handoff, add halftime shows to stories
4. Left-hand only days
5. No hotkeys days
6. Triple programming
7. Switch roles: dev and dba, designer and qa
8. No IDE days, or better yet, use Eclipse
9. Do spikes on interesting, yet inapplicable things
10. Stay home and mow our lawns
11. Alternate foosball between every step of the dev process
12. Downgrade hardware
13. Lower screen resolution
14. Call more meetings
15. Naps (made better with cups of cheerios and water)
16. Spray Endust upside down around your desk
17. Afternoon LAN parties

With all this fun, one might ask why we didn’t think of going slower sooner.