Notes From My Basement

I am not one to get into any political discussions, I reserve my opinions and understand it when others passionately get into it and make it their main content.  This however is not the latter, but a very interesting and unbiased way to present content in a visual way.

Below is a wordie of both candidates acceptance speeches at their respective national conventions.  McCain’s on top, Obama’s  the bottom one.

work by Thomas Hawk

Tags: politics

There is no other way to put this before I delve into the details: You (as a professional developer, product owner, product manager, software practitioner in any ability) owe it to yourself to read this book… that is, if you are anything like me and reading about all of these tidbits of software development history while getting a degree of insight into the process of an "organized" open source project, in any way call to you.

There is a little bit of everything here, presented in a narrative that is pleasant to read, and with the right amount of abstraction to keep you at the right interested at the right level without too much detail making the reading terse.  I almost [ALMOST] gave it to my wife to read, only until I was deeper into the book itself I reluctantly admitted it would have not have appeared as appealing to her as it was to me.

The [story] follows a team assembled and funded by Mitch Kapor, in its quest to create the open source product that would Chandler.  In the process, the OSAF is founded as the backbone supporting and governing the efforts.

Their trials and tribulations make up the narrative's main thread, but the vision, the lessons learned, the passion that one can feel jumping off the pages from those involved in the project and who wanted it so badly, was what made this a page turner for me.

Needless to say, the stories, the citations, the anecdotes surrounding all of those who end up intertwined in the process, as well as all of those that emerge from the story itself, and some of what otherwise would be considered useless footnotes in the history of software development, spoke to me, enticed my curiosity for wanting to know more about them and motivated more than a few searches and articles to be read parallel to and after finishing the story.

The book was published in January of 2007, and covers the project time (including vision and conception) spanning 2001 to late 2005, where the book sort of trails off and never quite has what one could call a "written form of closure". 

The author, Scott Rosenberg, sort of ends the book with a couple of chapters that are full of historical (albeit somewhat relevant) notes and an observer's retrospective analysis which are probably more subjective than actual factual conclusions.  I don't mean and certainly don't intend this to be criticism to the book itself or to the way he (and his editors) chose to conclude the book, but I would have liked a cap on the story more fitting to the initial heart beat of the book, one that would give the story it own identity, a beginning and an end.

The project itself is still alive, the product is available but beyond knowing that I would suggest that if you intend to read the book that you don't spoil the whole experience of reading the book by "catching up" on where the project is at currently.  I can share with you that the many players in the story and the project are interesting and up until the end they "all" came and went.  An interesting note worth mentioning is that a good number of the people involved in this project are the same "core" that brought us Firefox.

You can read it as a story, you can read it as a use case, you can read it as a diary of a software development project, you can read it as a text book that is 100% pragmatic, but nonetheless I recommend you read it.

You can find other reviews here, here, and here.  More opinions will for sure confuse the heck out of you, so go right ahead and read them all!

The book's main site is kept by the author at Dreaming in Code, available on Amazon or you can just let me know you want to borrow it!

Tags: books, methodology, software, management

Anyone not like free?  Those of you who raised your hands… GET THE HECK OUT OF MY BLOG.. :)  In all seriousness, this is your chance to enter a drawing for some cool swag! generously hosted by Max Pool at his blog {Codesqueeze}.

He was able to get vendors to pony up some nice (and pricey) software that would make an excellent addition to any developer’s toolbox.

Me myself I am hoping, going for Bamboo 2.0 CI Server.  No I will not resell it on eBay, I have actual plans for it.  Coincidentally I am in the middle of (call it, what you will) a project to setup a CI solution using CruiseControl.net & SVN at home.  The SlickEdit tools would be a nice to have, and believe me, there is nothing like a good editor to make you productive above and beyond the powers of Notepad.

On Deck: Guillermo, get you ass in gear and evaluate "the Bamboo"!

Tags: software, tools, free, ci

If you don't have anything nice to say, don't say anything at all... right?  Well that being one extreme, I'll take a more balanced approach and not write all of what I was so tempted to while I suffered sitting through this "event" (so loosely defined!).

Painful, bordering on disrespectful to the attendees time, sometimes crossing the line.  The presenter, while a nice gentleman, should have been, shall we say, better prepared; once again I am using the extreme definition there because I am convinced this person never even looked at the material before in his life.  He read from the printout of a "Lab Material", and read and read and read... read the slides, read the CODE!!!, the signature of the tool generated event handler's for controls... yes

"and here we see object sender (comma) KeyEventArgs e"

...and I am not making this up!

The totally best part of the day was the end of the presentation, not only because the pain finally went away but also because I won a copy of Office Professional 2007. 

I have to believe in miracles and in the kind and compassionate hand of God here, to know how (literally) I was so close to losing it he devised a way to bring my blood pressure down by rewarding me with the cool "swag".

Tags: events

This past Saturday evening, Tammy and I inadvertently (literally) got sucked into watching the 2004 "Build A Better Burger" food contest that the Sutter Home winery hosts every year, shown on the Food Network HD, I couldn't help my mouth watering at the parade of the very creative burger recipes. 

The outcome couldn't have been any more obvious: I set out to reproduce the winning recipe of 2004, the very next day.

Armed with the printed recipe, found on the site along other year's winning recipes, I shopped for the "delta" ingredients, and diligently assembled the heart attach on a toasted bun.

Pictured is the fruit of that labor.

My verdict:  I think the oregano and perhaps the seasoned salt may have combined to be too overpowering of a flavor. I should have thought better about the <amount of> Italian spices that the recipe called for, but that only became apparent once I had already "poured" all the ingredients together.  Next time I make this, I'll hold back on the those 2 ingredients and let the others find a better balance.

The blue cheese spread was phenomenal, and I will for sure repeat it on any sandwich calling for blue cheese.

The recipe is presented for 6 burgers, but I made 4 a little big bigger, and had enough for a second round the following day (yes, that is today and that was dinner!).

Tags: food, recipes, guillermo

Just today I read Sergio Pereira's post about the TIOBE index, which "gives an indication of the popularity of programming languages"

Its more like a shock really, to see how one's perception can often be so off base.  The gaps between #1 (Java), #2 (C) and C# at #8 is much broader than I would have ever guessed.  Although C# use (my current language of choice) is historically shown to be on the rise, the gap is still nonetheless surprising to observe and digest.

I am not that interested in analyzing this data, but I thought it would be worth to share the shock I felt when I saw the graph.

Tags: c#, .net, programming

As I had previously mentioned, yesterday I attended the ArcReady event titled: Architecting for Scalable and Usable Web Applications.  Here is my summary notes, and brief opinion in a format as condensed as I could possibly make it and still do it justice to include all the goodies.

The morning was split in 2 sessions, the fist of which was presented by Larry Clarkin and the second by Technology Evangelist John Weise.

Session 1 - Architecting for Scalable Web Applications: Overall outstanding for many reasons but more importantly because it did not carry a [heavy] Microsoft Agenda.  It was participative, well focused, well presented and what I would consider appropriately "architectural" in content.  With a few practical tips, approaches and case studies presented it had enough of a take-away to raise it above a purely academic level typical of most presentations.

Premise: Scalability <> Performance.  Strive for stable Cost Per Transaction.  Don't expect Economies of Scale to apply to scalable web applications.

Doing some follow up research I came across this very interesting and relevant white paper by Kanwardeep Singh Ahluwaliaon Scalability Design Patters (PDF Download).

The Patterns for Scalability presented were:

• Be aware of the environment both physical (infrastructure/backbone), as well as configuration related: Look at configuration settings to make sure Debug is turned off (yeah, it happens).  Use the deployment element retail="true" setting.
• Scale UP Hardware: Look at upgrading RAM, Disk I/O and even CPU. 
• Scale UP Software: The concept of scaling up applies to Software as well.  Consider upgrading to IIS7 on Windows Server 2008.  Look to eliminate single points of failure by implementing solutions like Active/Passive and Failover Support.  Look at configuration settings to make sure Debug is turned off (yeah, it happens).  Use the deployment element retail="true" setting.  Manage your sessions!  Consider turn them off for the application and on as needed per page.  Evaluate your needs for InProc vs. Database sessions.  Set them accordingly.
• Scale Out: Solutions include DNS round robin, Microsoft's Network Load Balancing, Microsoft's ISA and hardware load balancing solutions by vendors like Cisco.  As with anything else the right solution will depend on your needs, environment, budget etc.  Pay special attention when using load balancing solutions and SSL, remember to set affinity.
• Specialize: Use a node/server/group per role/responsibility: Web (UI), Application (Web Services, etc), Resources.  This last one was a good eye opener. Static in nature, resources make up most of the payload in a typical request.  A good case for implementing IIS7 configured with just the modules required for static content.  This would yield a significant performance gain.  You will also gain from "decoupling" the hosting implementation and can make adjustments where needed without affecting the rest of the solution.  Consider using 3rd party services to offload static content.
• Split the Application: Consider using subdomains if you can logically and functionally split your application.
• Split the DB: From a "logical" unit(?) point of view.  First approach under this pattern tells us to consider using a separate database for Reference & Transaction data.  A quick downside effect of this approach is that we violate many-a-rule of normalization and risk breaking our otherwise good relationship with our DBAs because of that! <grin>.  A second approach under this bullet points us to a solution that calls for Read & Write versions of the data.  One write, many (as needed) write versions.  Use appropriate synchronization/replication between them.
• Database Sharding: I knew of this approach referenced by the term Partitioning rather than Sharding, but the concept is to split your DATA across databases based on a given criteria inherently part of the data, like users with last names from A-D on one database, E-H in another one and so on... or split it by department or like apparent MySpace does it, one database by X amount of users which in their case appears to be 1,000,000.  To overcome the challenges inherently part of trying to manage data spread according to this approach, you can leverage technology like Distributed Partitioned Views available in SQL Server.
• GEO distribution: With more specialized uses and needs, typically used to increase availability by proximity and to provide some redundancy and failover.  Requires you to have or leverage Hardware and infrastructure knowledge skill and expertise.
• Offload the Work: Examples include services like Flickr picture hosting (applicable only to personal use), and Silverlight Streaming services.

Anti-Patterns:

• Spending all your time looking at your code (as your bottleneck)
• Caching everything <-- Do cache, but do so judiciously.  Caching chews up resources which hurts scalability.
• Services calling Services.

I truly enjoyed the presentation, the format, the tone and the content.  It wasn't better only because sadly it was cut short.  The last 20% of the content was pretty much delivered in 20 minutes which was a pity because the conversation was flowing and the attendees were engaged.

Session 2 - Architecting for Usable Web Applications:  John Weise breezed through some slides with too much of the content being "more of the same".  There were some interesting points brought up and the Demos where simple and short "show and tell" for a couple on "cute" applications.  Nothing breathtaking or groundbreaking there.  He talked about (showed) the UI Archetypes and went into some detail over the UX Continuum as part of which Larry stepped in to talk about and show the UX IQ application.  This cool little application is provided as a tool to provide guidance on application platform selection.

Best Practices:

• Form Follows Function
• Create a set of design tenets
• Use the appropriate level of fidelity
• Build with the customer and user's input <-- From agile?
• Build for ease of use, but don't forget the Power User.
• Plan for concurrency
• Balance security with usability
• Build for supportability and maintenance
• Be aware of standards <-- Compliance

Anti-Patterns:

• Golden Hammer
• Breaking UI conventions
• Overuse of animations

My personal opinion and take-away out of this second session, was not as positive as for the first part, but I still got some good pointers, and overall the time spent was well worth it.

Three good demos worth mentioning:

• ProtoXAML : Prototyping UI, with napkin skin... awesome!
• UX IQ <-- Couldn't find source at fist pass, will look further and update when and if I do.
• Woodgrove Financial WPF application.  Source code here.

As part of the now common and to a certain degree expected give-away, books and copy of Office 2007 Ultimate where handed out. 

Two of those books are available online and as PDFs for free:

• Improving .NET Application Performance and Scalability
• Performance Testing Guidance for Web Applications

Tags: events, architecture

In our current project we've been averaging about 7 minutes for our daily scrum standup. 

We kicked of this project Mid April, and are currently in our 2nd sprint.  So far the length of the standup has remained consistent, and this speaks volume on how the department, the team, the individuals have "gotten" what the standup is all about.

Standup meetings for our previous project took a long time, several times it went over 30 minutes and up to 45 minutes, for reasons I can chalk off to:

1. The size of the team:  We'd have at times upwards of 20+ attending the standup.
2. The team members interpretation of the purpose and value of the daily standup.
3. The overall lack of experience with agile practices and internal process immaturity.

I was often a violator of the "rules" that govern the dynamics of the standup.  Keep it short and to the point turned into discussions on implementation approach, use of technology and discovery and issue resolution on the spot.  Big no-nos.

Still, out of these sweet and short 7 minute standup, I know I am the big mouth.  Those of you that work with me or have in the past, know that I can talk anyone's head off when I get into it, so I am diligently working on keeping my status short, relevant and meaningful to the other participants, which means very little tech talk, acronyms or developer specific content.  Remembering the standup is about the project team progress update and not about the development team update is something I need to remind myself daily.

I want to summarize my lessons learned into the simple bullet point advise as I'd like to share it:

• Keep teams small.  This should be guided by the projects needs, common sense and some "best practices". I'd say an "ideal" team size would be between 2 and 4 developers a QA resource, one or two BA, one or two sponsors/product owners and the PM... a total of 6 to 10 total team members sounds about right.  We currently have 8 out of the 9 team members participate consistently in the standup.
• Remind everyone about the 3 points each member should be talking about:
  • What did you do/accomplish yesterday
  • What will you be doing today
  • Do you have any impediments that the PM or the Lead need to be aware of so that they can do their best to remove it for you.
• Be patient: Give yourself and your team the time you need to work out your own kinks.  Don't give up on the standup.  Find your own pace, your own style and your own way of doing it but by all means keep the spirit of the practice in mind at all times.   It is about communication in its best and most effective form, the face to face.

I like the goal and benefit stated in this definition of a standup according to the Extreme Programming (XP) site:

The daily stand up meeting is not another meeting to waste people's time. It will replace many other meetings giving a net savings several times its own length

A good read to get the gist of what the standup should be is this article by Martin Fowler.

Tags: agile, scrum, methodology, management

I am not taking about managers managing a team of OO developers here, I am talking about managers that think that practices and tenets of OO apply and benefit the process of managing a team of smart developer... things like encapsulation (secrecy, mysteries, a lot of closed door meeting), loose coupling (I don't really care about how or what you do, just do it), and lets not bring up Polymorphism.

In the interest of full disclosure, I currently work for an organization that is 90% (roughly?) "there"... we do keep a very open channel of communication, and open door policy does not mean "wood plank at office threshold is ajar".  There is still a little bit of mystery around some initiatives and decisions, but that is almost understandable given history and culture.  This post is NOT about my current experience, it is an outlet from accounts elsewhere that are not foreign to me by both direct and indirect experience and exposure.  Luckily most of this BS does not have a current effect on me, but because it HAS and because I feel for those who have to put up with this idiotic approach, I feel inspired if not obligated to express my opinion about it.

In all seriousness, there just isn't room in a team you want to make cohesive for unnecessary bullshit, mysteries or the dreaded "on a need to know basis" line.  If we want to work together as a team, and we are striving to foster open lines of communication with the introduction of Agile practices, there just isn't room for private meetings or delivery of information in a delayed and layered fashion. 

What is it that is feared?  Are we in a world that is THAT paranoid that we think we have to "protect" ourselves from the people we let into our own "home turf"?  If you don't trust them, then why did you hire them in the first place? 

When smart people get fed crap, the immediate reaction is anger.  There is the sense of being insulted and then devalued and then unappreciated and then ... you get the point.  When they feel this way, the natural tendency is to seek this information out, generating an environment of gossip and conspiracy theorist.  You'd want to know what the heck is going on, period, whether it affects you in any way.  Your first and perhaps more natural reaction is defensive and then perhaps proactive: What can we do about it?  How can I contribute, help, be a force acting to obtain value through change.  But most of these reactions go "unnoticed" or in the best (worst) scenario only viewed as negative/punishable/unnaceptable behavior on the part of the developer.

The context to which this opinion applies or better put is intended for, is that of the professional applications/software development world.  Developers, Architects, Database Administrators, IT guys and gals.

I would like to see the day organizations hire people they can trust.  You should be hiring Professionals, not monkeys.  Professional in my book is not defined by how old you are or how many years of experience you have.  If you are an unprofessional loser right out of college, or in the absence of formal education, during your 1st year at your 1st job in the trait, then nothing will change 10, 15 or 20 years later.  You'll just be the same loser with less hair or more gray hair, or more wrinkles and a pot belly.

If as a manager you have an opinion about a team member that is relevant to your environment, the business or the project, just say it, splat! flat out, not PC, no sugar coating the negative or adorning the positive.   I am not foreign to seeing managers calendar's full of private meetings & "checkpoints" on people.  How insulting is that?  Of course you "have" to make it private because its idiotic to have checkpoints on anyone to begin with!

My pet peeve extends to include common "controlling" type activities such as "web content filtering" or super strict PC usage policies.  If someone is dumb enough to look at inappropriate material (porn, warez, take your pick) while at work (because what they do in the privacy of their own home is their business) or is prone to click on dancing bunnies, you'd probably want to find out sooner rather than later wouldn't you?  Or would you just rather have a false sense of control of a wondering mind by administering smaller and continuous shocks?  I won't fear repeating myself here: If you hire true passionate professionals, this is a non issue.

Hire with confidence and trust.  Assume the best, not the worst.  Measure, keep an eye out for red flags, sure you just can't turn your back on it just like that, but don't bring forth paranoia a the de facto management style, bring, seed Trust and you'll harvest good will, productivity, sense of belonging.  If a person betrays that trust, then act accordingly. This brings home the very important sense of accountability.  I am not advocating be a push over or a tyrant, find your own style, your comfort zone for dealing out consequences.  Each person, each organization should have a defined threshold for tolerance to *these* issues we are talking about here.

Good 'ole "boys" clubs don't work, they segregate, they devalue, they demean.  It is very much Binary.  It sends the signal that if you are not "in" then you are "out", and so, what are you to expect from those that are "out"?  Do you think you can expect, let alone demand loyalty?

Tags: management, methodology