Posts Tagged ‘California’

Agile Model Driven Development (AMDD)

March 17, 2009 1 comment

One of the sessions I attended at SD West was ‘Agile Model Driven Development (AMDD) by Scott Ambler. Scott started the session by having us form groups of 4-5 people, and then gave us 3 assignments to work on – one each in the Traditional, Mini-Waterfall and Agile methodologies. At the end of the 3 assignments we compared the team ‘scores’, and most teams did best in the Agile assignment. We then had a mini retrospective of what went well and not so well in all 3 approaches. One of the important revelations was that each team interpreted the same assignment a little differently.

Agile Modeling (AM)

  • AM is a chaordic, practices-based process for modeling and documentation
  • AM is a collection of practices based on several values and proven software engineering principles
  • AM is a light-weight approach for enhancing modeling and documentation efforts for other software processes
  • Types of Agile Models: The type of modeling is not important. We can use any tool that works for us. The model can be represented in UI sketch or sticky notes on a whiteboard, as Acceptance Tests or a Domain Model or a UML Sequence Diagram.

    Agile models:
    • Fulfill their purpose
    • Are understandable
    • Are sufficiently accurate
    • Are sufficiently consistent
    • Are sufficiently detailed
    • Provide positive value
    • Are as simple as possible

    Agile models are just barely enough!

    Scott presented some comparisons between the Traditional, Waterfall, Iterative and Agile approaches. The data, slide decks, and original questions can be downloaded from One interesting slide provides data that shows Agile teams do quite a bit of planning, which dispels the misconception that Agile teams don’t plan! Most Agile teams plan using sketches on a whiteboard or similar; some teams capture this information (usually digitally).

    The session also included some information on Agile Documentation:
    How CRUFTy Are Your Documents?
    Calculating the effectiveness of a document: Effectiveness = C * R * U * F * T
    C = % of the document that is Correct
    R = Chance that the document will be Read
    U = Chance that the material will Understood
    F = Chance that the material will be Followed
    T = Chance that the document will be Trusted

    What are Agile Documents?

    • Focus on stable, not speculative concepts
    • Are executable first, static only if you have to
    • Maximize stakeholder ROI
    • Are concise
    • Fulfill a purpose
    • Describe information that is less likely to change
    • Describe “good things to know”
    • Have a specific customer and facilitate the work efforts of that customer
    • Are sufficiently accurate, consistent, and Detailed

    Some other useful resources on this topic are:

    By: Veena Mankidy


    Should I use PUT or POST for a CREATE operation in REST?

    March 16, 2009 1 comment

    POST is for CREATE, and PUT is for UPDATE and CREATE. Ok, they both allow CREATE, how should we choose to use PUT or POST for a CREATE? Let’s say we have an animal adoption service. We have /animals to give us a list of all the animals for adoption. Let’s say we allow the user to create a category to group the animals together, such as /animals/dogs/ to list all the dogs for adoptions. Meanwhile, /animals/dogs/{id_of_a_dog} will give us the details of a dog for adoption. Now, we want to create a new category “cats”, which will give us /animals/cats. We want to also be able to add a cat for adoption. Should it be PUT or POST?

    The Method Definitions of HTTP says that “The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.” And “The PUT method requests that the enclosed entity be stored under the supplied Request-URI.” The document also mentioned an important point “Methods can also have the property of ‘idempotence’ in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property.”

    In other words (plain English), we need to ask the following question:

    1. Does the user know the URI? Do we allow them to derive and decide the URI for the object to be created?
    2. What is the effect of the call to be executed twice? Is there no duplicated object created?

    If the answer to both questions are true, then we should use PUT to create the categories, which means that we will PUT the request to the desired URI (animals/cats).

    If the answer to both questions are false, then we should use POST to create (in this case the cat for adoption), which means that we will POST the request to the parent URI (animals/cats), in which case the response shall give us a new URL (e.g. http://somehost/animal/cats/{id_of_the_cat} ) to identify the cat that we have just created. Executing the POST again with the same request will end up creating an entry for the second cat to be adopted.

    Of course, rules can be bent under certain circumstances, but we should remember “the principle of Least Astonishment” as mentioned by Scott Meyers in his  “Better Software – no matter what” talk given at SDWest, which is to strive to maximize the likelihood that user expectations about an interface are correct.

    By: Nyik San Ting

    Software Quality

    March 13, 2009 2 comments

    A number of the sessions I’ve attended here at SD West 2009 cover the same theme: software quality. There are a number of practices that can ensure quality; most of them involve the same thing – feedback.

    1. Requirements analysts can build prototypes to get rapid feedback from usability tests before building any code – time frame: hours or days
    2. Developers can write a unit test before each bit of production code to get quick feedback – time frame: minutes
    3. Business analysts can pair with QA roles to develop acceptance criteria / acceptance tests for each user story – time frame: hours or days
    4. Developers can run continuous intergration test suites to get feedback on whether they broke existing functionality – time frame: seconds or minutes
    5. Executives and product owners can communicate their vision for the product or feature, so the team can work toward common goals. Team members then can constantly validate what they are working on, and make design choices based on shared understanding of priorities – time frame: continuous
    6. QA teams can do exploratory testing on working code to find subtler bugs, usability problems, spelling and grammar mistakes – time frame: hours or days
    7. Developers can peer review each others code to find code smells and spot potential bugs early – time frame: hours
    8. Developers in some languages can use strong typing systems to their advantage. Strongly typing parameters and return values to validate input and output – time frame: instant
    9. Developers can use static analysis tools that help find places your code is likely to do something other than what you intended. Some of these tools are shipped with your compiler or IDE, but you can always get more detailed ones, and you can write your own to enforce local coing standards. These tools can be part of your continuous integration – time frame: seconds or minutes
    10. Agile teams can estimate task sizes to identify risks as early as possible – time frame: 1 hour

    One thing that was empasized over and over, was that developer and tester are two very different roles. Developers want to write code that works; testers want to break it. Developers will always need that foil, trying to break their code using just as creative techniques as developers are using to write the code in the first place.

    TDD is a method of development and code design, not a method of testing. People often get this mixed up because of the name. Even if TDD reduces your bug count by 95%, your QA team will have plenty of work to fill their time, doing what should have been their role in the first place – exploratory testing: testing the unknown-unknowns (everyone who said this, first felt the need to apologize for the Rumsfeldian phrase – you know they must really mean what they are saying, because nobody’s going around quoting Donald Rumsfeld just for the fun of it).

    By: Todd Sturgeon

    Rich Life with choice

    March 12, 2009 Comments off


    Whenever I go to restaurant, I always spent a lot of time to choose my menu. Ordering from the menu is still a very complex process for me. Sometimes, I feel more comfortable with ordering fast food.
    Just order combo 1!
    It is so convenient and hassle free. What a simple choice..!!! Combo menu solves all my confusion about what to choose. However, what if every restaurant has only combo set menu? It’s not the world I want to live in… I still want to order with variety of choice.

    SD West 2009 gives me a lot of choice on the menu. It is not a burger shop which only has combo set menu. It has too many variety of choice. Everyday I had a hard time in deciding which session to go to.
    I tried to enjoy the diversity of flavors as much as I can.
    Here is my menu list for SD West 2009.
    BDD (Behavior Driven Development) and Acceptance Test
    FitNesse /SLIM
    EasyB /groovy

    Depenency Injection
    Guice Framework
    New Spring Framework 3.0

    DSL (Domain Specific Language)
    Java can serve DSL…


    Concurrent Programming
    Java with multi-thread

    Interface with Design
    Interface-Oriented Design (Interface means ability)
    Design Pattern from Theory to Practice (Interface means flexibility)
    I am still enjoying plenty of new streams of technology. If you want to taste one of those menu, I would love to share the recipe with you.

    Now I am full……um um yammmm


    By: Henry Ha

    Concurrent Programming

    March 12, 2009 1 comment

    CoresI noticed that Concurrent Programming, Functional Programming and Parallel Programming became one of phenomenon for developer from SD West 2009.
    There are many session which focus on concurrent Programming such as F#, Scala, Clojure, Ruby and Java with multi-thread.
    With coming multi-core cpu, concurrent programming seems inevitable choice for developer who are daily meeting scaling issue.

    1. Object-Oriented Programming: Java with multi-thread
    Java already supported multi-thread, but it’s not simple to handle synchronize mutable variable. Especially when we are doing TDD, creating unit test for code with unsafe thread is very hard. However java supports rich concurrent api: java.lang.concurrrent.
    But still writing concurrent programming with thread needs a lot of effort to solve synchronization issue.

    2. Functional Programming
    Writing concurrent programming with functional language is much easy to solve synchronization issue, because all the variables are immutable in functional programming. There is nothing to synchronize. It enables developers to feel free to write concurrent program.
    F#, Scala, Clojure, Erlang and Ruby are a few examples of functional languages meeting this requirement.

    For solving scaling issues or using multi-core processor, concurrent programming is not an option to us anymore. It becomes one of the essential parts of our development.

    By:  Henry Ha


    March 12, 2009 Comments off

    PersonasOn behalf of Todd (there were 2 UE related talk at the same time), I went to the “Personas, Profiles, Actors, & Roles: Modeling Users to target Successful Product Design” by Jeff Patton. Being a newbie in this area, I found the idea to be refreshing and powerful. Using the funny video clip on Spinal Tab’s stonehenge, he illustrated the importance of understanding the context of the product that we are building, rather than blindly following specification from the clients/users.

    A software product is shaped by business strategy, users, legacy code, regulatory constraints, product usage … Being agile, we can have a bloated backlog. A good way deal with that issue is to identify the different types of users that is relevant to the product design and prioritize them accordingly to the targeted audience that we care most. We can have many different way of categorizing the user, such as according to their computer skills, their goals (broker vs agent vs buyers vs press…),  first time user, returning user, user with different domain understanding level (agent just got into real estate business vs agent who has years of experience)….  We can come up with lots of different users with their own characteristics, but some users may not make a difference in how the product should function, hence we can group them together. After having distincts personas, we can prioritze them taking into account of the business goals, then we can priortize the different feature/design according to the characteristics. Personas make user data more tangible, ensure we didn’t miss the different aspects and gives clue about the proper UE design. The distinct personas show who are the targeted audience and become the design imperatives to keep us focus.

    By: Nyik San Ting

    Keynotes at SD West

    March 12, 2009 Comments off

    Robert C. Martin gave a keynote address on Monday at SD West  titled ‘Extreme Programming: After 10 years, why are we still talking about it?’ and the theme song for the talk was ‘I used to rule the world’ by Coldplay!!  Extreme Programming has been adapted to such an extent in the industry that it is not discussed much any more, and hence may appear to be ‘dead’. This is similar to object oriented design – nobody talks about it anymore because everyone uses those principles. He also mentioned the Manifesto for Software Craftsmanship if you would like to take a look.

    Manifesto for Software Craftsmanship

    Manifesto for Software Craftsmanship

    The Wednesday keynote was ‘Software Development Strategies, Philosophies, and Techniques: Traditional vs. Agile’ by Scott Ambler and Terry Quatrani. It was a very entertaining talk in the form of a parody with Scott acting out as the Windows guy (and Traditional approach) and Terry as the Mac (and Agile) person! They presented data based on a Dr. Dobbs survey from late 2008 that shows the difference between the Traditional, Ad-hoc, Agile and Iterative approaches, with the Agile and Iterative approaches doing so much better (as expected).

    Coding monkey vs the jack of all trades

    Coding monkey vs the jack of all trades

    Success rates of the different approaches

    Success rates of the different approaches

    By: Veena Mankidy