Noah Campbell

Stevey’s Blog Rants: Good Agile, Bad Agile

This is a must read. Steve talks about a system where developers are provided incentives to be successful and not coerced.

The comment section adjusts Steve’s attack on Agile processes without getting into the religion (yet…this is a flame bait piece, no doubt). It doesn’t defend Agile methodology, but it does bring to bear the fact that Google has really only delivered one business unit, with success, to market. That is AdSense. Everything else that comes out of Google’s development department either helps Google increase operational efficiency or expands the use of AdWords; so there is no real incentive at this point to really release anything before their competitor.

The best quote in the comments:

In a different context, different approaches are requried [sic]: how well do you think the Google approach would fit (to pull an example from the air) adapting a trading system to handle new kind of derivative? Or making a new kind of revenue earning service avilable [sic] on a mobile network? Beleive [sic] me, “it’ll be done when it’s done” is not an acceptable answer when the sponsor can see many millions of dollars (a chunk of which is headed for their bonus…or not) being lost if the opposition gets into the market far ahead of them.

Here, the business is driving because they see a real incentive and probably understand that time is of the essence. A rank and file developer does not typically understand the business and will not be able to simply jump into the project and lend a hand (well maybe at Google, but that’s not because they have an good agile process…I’ll elaborate in a moment) because the effectiveness of the team will be comprised in more ways then one. TMMM states that adding more developers to a project will decrease the project time line negatively. I don’t think Google has figured out how change this axiom.

So what does Google do right, or what Steve calls “Good Agile?”

all you need is a work queue

This is a tenet of Scrum and called a sprint backlog. It sounds like Google has a global work queue where any engineer can take something off the queue and process on it. This is smart, because this process is key to the objectives of the engineering team. Enterprise architects are at work here.

I could talk for days about the amazing rigor behind Google’s approach to software engineering. But the main takeaway is that their scaling (both technological and organizational) is not an accident. And once you’re up to speed on the Google way of doing things, it all proceeds fairly effortlessly — again, on average, and compared to software development at many other companies.

and

the project management techniques that Google does use are more like oil than fuel: things to let the project keep running smoothly, as opposed to things that force the project to move forward.

These both speak to Google’s brain trust being applied to all areas of their business. I’m happy to see that management understand workers need to be motivated and lead, not told what to do. There is also a strong bias towards discipline and standard. It appears, based on Steve’s attention to these points, that it works behind the scenes, out of view of the engineer. I believe strongly that leadership must motivate and facilitate effective behavior by providing feedback and leading by example, something Google does without shoving it in the developer’s face.

Marty, thank you for your post! This is a discussion that is long overdue.

I think your definition of System Architect is spot on because that is the definition that most accurately identifies those that call themselves architects. A system architect main role is to make sure that the internal system is built in the most efficient manner. They are aware of the best practices and patterns at a system level. This is where most engineers end up either through experience on multiple projects or maintaining one project for a long period of time.

However, Marty’s definition of a solution and enterprise architect lack any real meat in their responsibilities. He, for better or worse, expands the responsibilities of a system architect in terms of scope and experience. I think describing either one of these types of architects in terms of a system architect misses one very important distinction. Solution and Enterprise Architects must understand the business of their organization.

A solution, or line architect, is responsible for understanding how the systems of a line of business interact in order to support the business unit’s objectives. A solution architect is knowledgeable about the particular line of business, or LOB, because she has had experience in the LOB and understands how technology enables the LOB to succeed. There is a mixture of business and technology that a line architect must balance. A line architect has the ability to look at a system and determine that capabilities of a system are good enough. They also understand the solutions major vendors offer and how aligning her architecture with there will be advantageous.

An Enterprise Architect is aligned strategically with the business and focuses solely on working with senior management to determine which processes are critical to the business and therefore must be implemented in silicon to be most effective. An enterprise architect will look at processes and determine if they best meet the needs of the organization and work with senior management to seek a more strategic, in terms of the marketplace, and efficient business process.

What does this look like in practice when everyone plays their part.

An enterprise architect would analyze the business and work with senior management to identify a process that is absolutely critical to their business, lets say its AdSense the company is Google. The enterprise architect would set the priority that AdSense must be operationally lean so profits margins can be maximized. A solution architect, understanding the systems within the AdSense business unit and pulling from experience from similar lines of business, will understand that their three of the five systems they use are not optimal for the type of information sharing that is needed to meet the enterprise architect’s priority. A solution architect will decide to buy or build based on her experience and the needs of the business. A system architect will focus on maximizing the efficiency of the system he owns, hopefully with the additional resources that accompanied the EA and LOB architect priority, and build a better system.

How would I change Marty’s definition? I would start by looking at the landscape in which each will function because all architects need to understand the environment in which they operate to be successful. Failing to accept these decisions will have detrimental effects. When was the last time an Enterprise Architect who decried a particular technology, like .Net or J2EE, as a company standard been successful…never. This is why architects are seen as living in a cloud or an ivory tower.

Briefly, each environment an architect operates in looks like the following. A system architects understand code, libraries, platforms, etc. A LOB architects understand vendors, business objectives, processes and technology to an extent. Finally, an enterprise architects understand business strategy and operational efficiency, IT as a competitive advantage and governance. All serve a specific purpose and communicate in well defined channels.

Translucent Databases

Looks like a new trend in data management is emerging. Personally, I would like to hear from Jeff Jonas on the topic since he pioneered this subject. He not only took on translucent database, but he used event correlation in his NORA product, now buried in IBM’s DB2 product line. He calls it perpetual analytics. Very sophisticated stuff that is completely proprietary so Translucent Databases is the best starting point one has to understand this type of data management.

Amazon Business Solutions - Fulfillment by Amazon - An Amazon Fulfillment Services Group

Wait, doesn’t Amazon sell books? I predict that Amazon is positioning themselves to be a business platform company for the web generation.

A very interesting presentation. Here are my notes.

InfoQ: The Roots of Scrum

Toyota: The software iron triangle: cost, quality, and time is broken! Instead it is quality, product variety and low cost.

Synthesize, not Optimize: Optimize will put a project on a mechanistic frontier. Synthesize will lead to an organic frontier

22:30: People not involved with the project. aka managers need to keep out of the way of the developers. I don’t agree with this because the messaging is wrong. There is supposed to be a team leader in the Scrum model, so hopefully that is the person responsible for the teams deliverable.

Scrum team is autonomous, transcendent (act as a team, not as solo career guy) and cross fertilization.

Ref: Rosing at Google Fast Company April 2003

ba the zen of scrum: Get the right people in the right meeting so the “magic” happens

Leaders or ScrumMaster, not managers, in Scrum. Same difference; except, there are no bad leaders because no one will follow them.

3 Questions: What did I do yesterday, what will I do today, what are my impediments?

DuPont: Empirical Process. Software is an empirical process because of the high level of uncertainty.

First Scrum: Abandon GANTT because it is not accurate and has no value.

Toyota Way is consulting group that has had dramatic effects on American companies.

Joel on Software has some scathing advice for the Ruby elite:

I understand the philosophy that developer cycles are more important than cpu cycles, but frankly that’s just a bumper-sticker slogan and not fair to the people who are complaining about performance.

Developer productivity is important, but I’m not sure it’s as important as developers tend to make it. I’m wonder if there is any research on the impact of productivity tools and the overall budget. Is the principal of diminishing returns relevant here? Are tools that are too productive, counter productive? One example comes to mind. ASP.Net is extremely productive, until you step outside what it’s been optimized for. Java is generally “challenging” at every level, but in a good way. Either way, is developer productivity really that important?

Why Johnny can’t code : Salon Technology

This is a great article that talks about making programming more accessible. I think that today’s basic is JavaScript. With sites like Script.aculo.us and Dojo that provide ready to use, visual code samples, I think Johnny can approach basic and create some truly novel web-based applications.

A great discussion about J2EE Security.

Using JAAS in Java EE and SOA Environments by Denis Pilipchuk — Java Authentication and Authorization Service (JAAS) should unify security approaches in Java applications, but it has never integrated very well with Java EE, particularly where representing users is involved. Denis Pilipchuk looks at the current situation, the compounding issue of SOA, and assesses future directions for JAAS.

JAAS was originally intended for client authentication for the JavaSE platform. It has be hi-jacked by the application server vendors, for good reason, for use on the server side.

There is still a long way to go for J2EE security. It has the difficult task of taking on an enterprise’s security policies and enforcing them programmatically…a task that cannot be taken lightly. XACML and SAML go a great distance for describing a security model, but are relatively new. The J2EE specification needs to incorporate it as soon as possible so enterprise security can thrive.

logbag.com

LogBag is interesting in that it intends to group log messages into “bags.” They do this with an API which has prompted Cameron Purdy to note that this yet another logging framework. I have to agree.

I recently wrote a small proof of concept that does just this using the Esper api without any changes to the source. It will group messages based on when the occur. So if you want to capture all the severe log messages that occurred in a 10 second sliding window, you can.

If there is any interest, please leave a comment on this post.

Takeo Igarashi has some very, very cool 3d modeling software that takes 2-d drawings and creates a 3-d model. Highly entertaining and potentially the future of custom avatars. Very fun.