Zappos - CEO Tony Hsieh 10 Core Values

Here is what he put on his blog... http://blogs.zappos.com/blogs/ceo-and-coo-blog

At Zappos, we have 10 core values that act as a formalized definition of our company culture. Our core values weren’t formed by a few people from senior management that sat around in a room at a company offsite. Instead, we invited every employee at Zappos to participate in the process, and here’s the final list we collectively came up with: ~Tony Hsieh

1. Deliver WOW Through Service
2. Embrace and Drive Change
3. Create Fun and A Little Weirdness
4. Be Adventurous, Creative, and Open-Minded
5. Pursue Growth and Learning
6. Build Open and Honest Relationships With Communication
7. Build a Positive Team and Family Spirit
8. Do More With Less
9. Be Passionate and Determined
10. Be Humble

If my company was bigger than just me, this seems like a good place to start.  I manage 2 teams now, and I would say I try to instill those ideas with my team, although I/we could always use some improvement. ~alex

Choice in Web Technologies for RIA Admin Sites

There are differences when talking about administrative sites vs end user sites.  Administrative sites can require highly interactive between many different domain entities.  For great RIA user experience you could call this the single page model.   In the year of 2010 you must have lots of time and resources if you want to build and maintain this is a javascript based technology (jquery being most popular)

1. Silverlight can provide an amazing user experience, for Microsoft developers this has a medium up front costs and lower long term cost for this high level of user experience - Cons - not supported by mobile.
2. Jquery - expensive to maintain, and more difficult to debug (although SL has an async learning curve), also does not support multi-developer projects as well.  Good to great user experience
3. Traditional web forms - low up front cost / time, medium to\ low long term cost low to medium user experience - mobile yes to some degree, but bad user experience
4. Native mobile apps. Doesn’t replace the need for a web based admin tool as well. Provides the ultimate user experience. Cons – Additional development for a smaller market share.
   

Learning is the Bottleneck

Identifying that learning is the bottleneck in software development gives insight on how to optimize team efficiency. I know this is true on my teams, everyone wants to try something new all the time rather than just crank it out in the simple and often the maintainable way. I can appreciate developers want things the best or right way. Try to spend as much effort on good enough as you do the best way. In no way am I advocating quick fix or hack, I am more referring to big picture project development and architectures.

As you personally move to a higher level of responsibility such as a lead or architect, results become very important. I can argue they are important at all levels. Achieving increased results frequently comes by reducing learning time, which means do something you already know how to do. I am not saying stick with COBOL :), but lean to get your team to spend a significant portion of time getting something done as compared so much time learning. Here is the article that inspired this thought.

http://www.infoq.com/articles/learning_is_the_bottleneck

Automation - The Right Way to Achieve Standards

Generally I think coding standards are worthless, but that is an exaggeration, as I love best practices, and love quality code. There are always the infamous discussions of should it be "ID" or "Id." An example is ProjectID or ProjectId... Ok in the old days this mattered but with most modern languages this is not how people should be spending there time or this should be the icing on the cake after you already know you can create clean code as a team. There is a decent chance people will change and things will change and somehow you will likely have both in your project, sure there are exceptions if you really want the police to come check or you run fxcop.

I would suggest if you want a standard in this regard, use something that catches it at the source. Resharper, tells you immediately after you type it. In this case everyone on your project must use Resharper and you tell everyone follow Resharper rules and there you go, you can easily get 100% compliance.

That is all a side track from the real point which of standards which is: Over the lifetime of your application you want "maintainable" code, what else really matters? How pretty it looks with consistent "Id?" I try to follow those rules myself but FOCUS on getting the big picture right and once you have that mastered move on to the finer details.

So what does "maintainable" code look like? Ideally methods you can basically understand what it is doing in 30 seconds or so. Definitely not something that takes 10 minutes or more and you still are not sure if you understand it totally. Now there could be 20 small methods that each one on its own is understandable but one big 300 line method is not. Or take it even smaller there could be 3 20 lines that are and 1 60 that is not. So from my perspective 3 key ingredients there. Reduce lines of code, cyclomatic complexity and nesting depth, that will get you 90% right there. You want 100% compliance, automate Ndepend with Continuous Integration, and get some automated enforcemnt... Problem solved an no manual work involved other then enforcing or inspiring compliance.

So what else? There are many other things that could equate to bad code, but next on my list is duplication of logic, bad names and wrong placement the list could go on. Duplication can be reviewed automatically too :) (see simian and manually see clone detective). Names and bad placement that is manual code review all the way... Now creating small methods makes them potentially reusable, and you can never reuse that 300 line method, or very rarely.

Anyway I just want to put a quick note that you should focus on the big picture, only make standards that can be enforced automatically. Make the rest best practices, and only spend time with them when your big picture is working well. Also read Clean Code and another one for big picture that is great is 97 Things Every Software Architect should know

Good luck.

Silverlight - The Silver Buillet

No one is saying Silverlight is the Flash killer, but an Adobe Flex killer it might be. As a Microsoft developer I may have a skewed perspective. To give myself a little "expert" credit I can say I have used Adobe and Macromedia products for many years and love them too... I worked on many small Flash projects over the years and even a few non-professional projects in Flex.

Back to my point, look at the history of Flash, it started as a technology to do fancy/flashy animations. Granted it has done a good job, and continues to grow up nicely in that Adobe suite. Flex took a great move to the Eclipse platform, which generates a nice following from the non-Microsoft geeks. But ultimately the way Flex and Flash work together, can I say "sucks?" OK I said it. Adobe does not have the experience Microsoft does in providing developer tools, nor does it have any where near the number of great coders in it's platform. Allowing developers and designers to work extremely well together should really change things.

I would guess some day Flex will add the nice visual design features of Flash but it might be too late. Not to mention these action script files hanging off the side. Currently it's really more designed as one technology or the other, although Flex can play a Flash movie (animations) and good flex guys can do some hacks to get them working pretty-well together.

OK technically yes Flex outputs Flash based code, but in Flex there are no real animation UI's. For the true geeks this is not a problem, they will write code for every animation no problem, but there is no easy way for great UI designers to easily work well with die hard developers. Microsoft has definitely done this right by having a single technology and a the great Expression Blend, that works very well with the Visual Studio. This is an environment that just Rocks!!! Sure Blend 2 and Silverlight 2 have their funkiness but you really can see where this is going and how good it will get. Expression Blend 3/Silverlight 3 look very promising right now.

An example of the platform maturing is that Blend 3 will now work with source control, Team Foundation Server at the minimum, a crucial step towards a perfect working relationship of developer and designer. You also now have the new Blend 3 SketchFlow (now the Product owners can do mock-ups, check-in, the designer can make it look good, check-in, and the developer can code it. The whole Visual Studio platform, provides complete lifecycle support. For QA, for Build Master. You name it.

The other new feature of binding UI's to data-sources means that developers can create empty data-objects that can be bound to a UI page in 1 line of XAML, and the UI guy can add his own test data without any code other than markup. It would even be really easy for the UI guy to even create his own data object without requiring him to be a true geek, only a little training. There are some amazing video's here to see the new Silverlight 3 features.

http://videos.visitmix.com/

Microsoft is really addressing all the shortcomings of Flash and hitting them head on. A "simple" one such as working back and forward buttons in the browser. They have what looks like clean solution in SL3. I could compile a long list of stuff I have tested personally not to mention a lot that I have not.

So ultimately is Silverlight a Flash killer probably not, but it might be an HTML killer, did I say that, OK joking but seriously. HTML, javascript, css with a mix of server technologies is a one big "hack" whether it is asp.net, php,... I have to say it is similar to Flex and Flash's relationship, HTML was not originally designed to be dynamic. Ask windows developer they will tell you web technologies feel like a hack, a piecemeal of mixed semi-unrelated technologies. Even though lately I have been doing a WPF project, I am not a windows developer. As a career I prefer web technologies and I even really like asp.net, almost love it from a business value perspective.

Ultimately as Silverlight grows up, I along many other developers will no longer want to deal with HTML, and my crystal ball says most of the top talent UI developers will feel the same. How many more years do you want to deal with browser compatibility issues? Me zero. How long can the business hold back IT, my guess is not too long assuming developers can be as efficient as they are now, especially if they can deliver RIA, instead of just IA.

Geographically Distributed Scrum Teams

They say Scrum is difficult and it quickly points out your weaknesses. After 2 years of inspecting and adapting with geographically distributed Scrum teams, and even though our processes are far from perfect, I can honestly say it usually feels pretty and my teams agree. We have high team satisfaction, client satisfaction and on the road to high profitability. Distributed Scrum seems to be working...

I am discussing a development team in Poland - SaaS (asp.net/silverlight/sql/soa) with product owners in Seattle, ... 9 time zones are a bit painful, but the whole team averages 40 hour work weeks, during basically normal work hours.

So what about Scrum? No 3x5 cards, that's too bad. Microsoft's Team Foundation Server (TFS) holds our electronic artifacts. We are using the eScrum Template for TFS. Every project always has a working burndown chart. Prior to the Daily Stand up we get an email with the burndown chart. In a Skype based meeting everyone answers the 3 questions fairly religiously. Because the answer to the question "What did you work on today?" is in TFS, we have some overlap. Hearing it on the phone frequently sparks some ideas for further followup discussions.

We run a hybrid scrum process, and I am more of a manager or director, but I do my best to maintain the role of "inspiration enforcement," not the "ruler." I also assist with removing blocking issues due to the lack of product owners on our time zone. I have to say our teams function very well without me, which allows me to easily work remotely most of the year. I just need to be extra available at the beginning of the sprint. The key here is allowing the team to do it's thinking, and I guess a little delegation helps also.

We also have other hybrid roles. Scrum Master / Dev Manager. As Scrum master they run all the meetings, help remove blocking issues, and make sure the burndown is heading downhill (positive direction). Not to mention as a manager ultimately responsible to making sure the product quality stays high, definitely not true Scrum, but I do believe if you ask the teams they feel like they run their own show, the manager is more of a support role, due to shortage of resources they happen to play the Scrum master also. This also allows the teams to says focused directly on their projects for the most part. One good thing is different geo, and different time zone makes it so the Scrum master does not need to do much blocking.

Using TFS. This is a long subject in itself but to keep it short and mention the highlights of what we use it for product backlog items, sprint tasks, bugs, backlog priority, sprint task priority, iterations, areas to name a few. We move unassigned backlogs into sprint backlog. We create developer and QA tasks linked to sprint backlog items. Sprints in TFS are basically just an iteration. BL items, tasks, and bugs are all just different workitems with different sets of clothing. You can also see articles on build automation and code reviews. (Soon).

Velocity. I have seen many posts on improving velocity. Because each team and company is so unique, and I think most of the time people have very large products they are delivering over many sprints, with semi-consistent teams. I don't feel most of what I have read is overly accurate to our situation or level of change, although scrum still excels for our projects. We do backlog (story point) estimation very quickly and early and I would not say it is particularly accurate, as we frequently change the scope before or within the planning meeting(s). We can have a pretty good idea of when things will be completed and that is good enough for us. We stick to assuming we will get 80% of the most important features completed each sprint. Trying to increase velocity might have some positive side affects, but currently assume we get more efficient as we go anyway.

The schedule - 4 week sprints
Day one Sprint Planning - Europe evening understand the backlog, includes PO
Day two Sprint Planning - Design meeting followed by task estimation and creation
About 10-12 days of developement (holidays...)
A stabilization day (just in case)
4 days UAT
Release every sprint

The meetings. Every 4 weeks we release a new sprint. Because we release each sprint we also need time for the customer to review, some teams are good at keeping the client reviewing all the time but frequently it is once a month. This means we need a time for user acceptance tests, although this is at the end of the sprint and they really don't have a choice at this time, our custom software teams give the client more choices. The only time we have for the sprint planning meeting is end of day Europe, beginning of day Seattle. We break the planning meeting into 2. Day one, go through the backlog and make sure we clarify any questions (3-4 hour meeting). The next day when they are fresh during, the morning the development team discusses in detail including tasks, and comes up with list of remaining quesitons, which can usually be handled by email. Developers and QA then go and create their tasks with personal hours estimates and the scrum master creates the burndown in TFS.

Sprint Review meeting, also a little non-traditional. Our product owners also play multiple roles which they end up being busy, so frequently they have not even reviewed all the changes before a Sprint Review. Our QA runs the sprint review. Goes through the Backlog shows what has been accomplished.

So there is an overview. Is it Scrum? Some might say no, I definitely say yes. Inspect and adapt gives leeway in the definition of Scrun. We do try to adhere to the Agile principals. I also agree there would be huge benefit in being collocated, at least some of the time, in many cases this would likely offset the cost of having developers in lower cost center locations. Don't get me wrong, I love this team, and they are extremely gifted, but as I said there is something very valuable in colocation. Good luck with your projects. ~alex

Life before and after Ndepend

There are a lot of reviews of ndepend out there, and I don't think I have read a negative one, granted 1/2 of them got a free copy but I can say I paid for mine. Our team uses ndepend as the "big brother code reviewer," always ready to give his opinion on check-in. We do not use it as a replacement for manual code reviews it only allows our manual code review process to be more focused and productive.

Our team: Our company has about 80 IS strong (developers, scrum masters and QA). My work focuses on what we call the "Product Team," as contrasted to our company's core line of work, which is custom development for the fortune 500.

We have been using Microsoft technologies for 12+ years and currently (ASP.NET 3.5, C#, Silverlight, SQL). Hybrid Scrum has proliferated our organization, using Team Foundation Server (TFS) for most of our electronic process based needs. Item tracking (bugs, backlog, tasks), source control, and build process. I have also been trying to inspire my teams to do TDD but it doesn't seem to stick.

Before ndepend our code reviews were hap hazard and lacked focus, as an example "This is the code I have been working on... Oh that's nice or no that's not so great will you refactor it when you get time?" Then out pops a TFS task, assign to a future sprint/iteration, only possibly to be postponed forever. In the "fridge" as my team had coined, just waiting for you like left overs.

Each team has a different review process, and each team has different criteria of what they see as important. Amazing we can get such consistent results, all of projects over 2 years old turn into something you would not even introduce to your mother. Sure quality is relative but I consider frequent 100 line methods with high cyclomatic complexity and 20%+ code duplication pretty low. How does this happen? Everyone knows small simple methods are best, don't they? And reuse... cut and paste is much faster. Conflicting priories and procrastinating refactors are only a couple of ways to achieve such consistency.

There are many reasons for code reviews. My research would say the industry defines the primary purpose of code reviews to find defects. For the purpose of this article you might define my code reviews as design reviews, although I am only looking at code.

What am I looking for? Hard to read / unmaintainable code, it smells bad, and more importantly is to provide developers better options to achieve the goal of clean code. Consistently finding bad code is is easy, consistently keeping smelling fresh is not. In manual reviews we also look at team standards, security, naming conventions... you get the picture.

Life after ndepend: We have implemented ndepend in a way that I have not seen any other teams openly discuss on the web. Realize my ultimate goal is to get developers to keep their code clean and I can justifiably argue, the easiest time to fix it is when you create it. If the code is fresh in your mind you feel much more comfortable refactoring. I can honestly say our current processes have accomplished our goal of keeping our code clean. We can and will take this progressively further but I can easily say over time our code has stayed so much better, not only would our developers show their old code to their mother, they might even show it off to a peer.

Many companies use ndepend with continuous integration (ccnet). We also are using ccnet for all of my teams projects. We use it in a fairly simple manner, immediate feedback when developers break the build and run our ndepend automation process, that's it for now. What we are doing differently is that when a developer checks in some failing code, ccnet creates a refactor task for the developer and he gets an email from TFS, new task created, so he can go in immediately and clean his code he was just working on. Developers can usually clean 80% or more right after this check-in failure. I know... before check-in is even better.

To inspire the developer further we have a daily email that goes out to all developers and the managers with red, yellow, green project status to show if you have closed all your ndepend failure tasks. Yes every developer wants his project green, we provide everything possible to promote this, including the ability to postpone a task. Back in the "fridge," only this time it is like beer, you can't wait to take it out. While in the fridge the task does not affect the green status. Today 6 out of 7 of our projects are green and 4 out of 7 have no outstanding tasks that need refactoring. Much better than continual postponement and a couple that are trailing are legacy that are being brought up to par, talk about difficult.

So a long article only to say. Immediate code verification feedback and daily email color status, so simple, so valuable.

In a separate blog I will talk about what is the definition of red, yellow and green and what we see as valuable for the rules of ndepend. The great thing about ndepend is each project or team can have their own rules. I will also create an blog about manual code reviews.

Ultimately I believe that keeping developer inspiration high may be the most important goal in software development (customer satisfaction is near the top too). Developers spend so much time maintaining applications, keeping the quality high is part of retaining that inspiration, even maintainance tasks are more fun when you know you must adhere to standards and refactor to keep your code clean.. Good luck...