3 Great Results for Today

When I came across this blog entry of J.D. Meier, I know I just find a lamp to lighten up the to-do list fog.
In case you don’t want drill down to the links I gave, the following is the original text. Good for many people. I just started to think about the three great results of mine for today.

What are 3 great results for today?  That’s the question I ask to bootstrap my day.  As simple as it sounds, I find it’s the most effective way to cut through the fog each day.  There’s a lot of things I can do and there’s lots of activities I’ll be doing, but what are 3 great outcomes for today.  That’s it.

This is an example of my 3 great results for this past Monday:

  1. Ship Beta 1 of App Arch
  2. Beta 1 Post for App Arch
  3. Draft of Designing Your Architecture

Great is relative.

Why 3 things?  It forces me to prioritize among a sea of potential results.  Also, I can remember 3 things without writing them down, so throughout my day, I know what I’m working towards.   I can say it in the hall.

If you manage endless to do lists and work on a bunch of stuff but don’t actually get anything done, try focusing on 3 great results each day.  It works.

3 Great Results for Today

About defensive programming, well again, it depends

There are always things you can’t say they are absolute. Most time, for most subject, how to deal with a concrete situation, it depends on the context. Is there any principle for any context? Oh yeah, there is one, that is, “it depends”. Well, there is actually another one, “don’t be rigid”.


About defensive programming, well again, it depends

The “Software Architecture Document” Size

* This post strengthen my thought on software project document that is write necessary documents only and make sure the documents work.
The "Software Architecture Document" Size

Written by Arnon Rotem-Gal-Oz   


Simon @ CodingTheArchitcture recently asked "How big is your software architecture document? (and who reads this stuff anyway?)"    He notes that in a user’s group meeting most of the attendees had Software Architect Documents (SADs) that were more than 50 pages long.

It would probably not be too surprising if I said that, in my opinion, the answer is " it depends." Reflecting on some of my past projects, I had SADs that varied in length from a 200+ "write-only"  document*  to a less than 10 page lean document. And the sizes matched the intended usage of the documents. For instance, in the two extremes just mentioned, the first case was a huge mission-critical project with a specific requirement from the customer to have an "official" SAD  and  it was written to satisfy some project milestone (PDR) . The second extreme, on the other hand, was an agile project where the architecture document was a working document, written some 10 iterations into the development to highlight some of the emergent guidelines.

What is common to all the SADs I’ve written (or have been responsible for) is that they all tried to grasp the essence of the design, all used multiple viewpoints to describe the solution, all were focused on quality attributes,  and all explained the rationale behind the decisions.

  • If you drone endlessly with details, you don’t see the forest from the trees.
  • If you don’t use multiple views, you are likely to miss important aspects of the solution
  • If you aren’t focused on quality attributes, then you are most likely documenting design and not architecture
  • And if you don’t explain the rationale,  then the document doesn’t have a lot of added value beyond the code itself

In any event, the important thing here is that when it comes to Software Architecture Documents  "size doesn’t matter" :). What matters is that the SAD satisfies  the reason it was written for.

*While this particular SAD was rather long,  it also had a section that helped potential readers find relevant chapters so that it can actually be usable, and not just for "door stopping".

The “Software Architecture Document” Size