Embrace the Khaos

Acne solutions

2010-11-30T20:15:00.000-08:00

Folks,

Do checkout Natasha's latest web page about acne. She is getting results within one month on some clients.

Face It Today

Wife's new web site - part two faceittoday.com acne practice

2010-11-05T16:38:00.000-07:00

Folks,

Beauty2YourDoor did not make it. Cost to run was not within our goals. We stopped it for the time being.

We are working on www.faceittoday.com our acne site. Check it out.

Dave

Wife's new web site

2010-10-15T21:21:00.000-07:00

Folks,

I have been working on the wife's new web site. Do checkout

www.beauty2yourdoor.com

Lots of information about how to use Sothys products.

2010-05-10T13:28:00.001-07:00

“I would rather have a good plan today than a perfect plan two weeks from now.”

General George S. Patton

IT governance is a written plan detailing how decisions are made and who has the right and responsibility to make them. That’s the simple form of what governance is all about. To add some meat to what governance can include:

1. Reporting structure & hieratical relationships

2. Defines membership

3. Defines the scope of governance

4. Defines meeting & reporting cadence

5. Autonomy and accountability

6. Alignment of goals

7. Set objectives, timelines, and funding.

A well structured governance document will address these needs. When you are ready to develop such a document don’t forget your Agile training or background. Look to minimize structure or process impediments. Detail just enough and nothing more. At the end of the day its about relationships and communication. Be generous in these areas.

· Steering Committee:

o Provides overall program direction, funding, sets priority, and resolves roadblocks. They are the ones who ultimately give the go ahead.

o Membership;

§ Executive Sponsor

§ CIO

§ Business VP’s and or Directors

§ Finance

§ Etc…

o Reporting:

§ Program management

§ Stakeholders

o Do’s:

§ Take advantage of this group to showcase results and progress. Provide visual and data rich presentation.

o Don’t:

§ Status them to death. Keep commutation crisp, focused, and if possible graphical.

o Accountability

§ Ensure business success by executing and delivering business value through IT. Meet all of the stakeholders stated and unstated goals.

· Program Management:

o Provides day to day direction at the program level. Programs are normally defined as having more then one project or of size that a program office (manager) is warranted. A single project that would have a program manager would include a development team, a test team, an integration, and maybe a beta test team. Lots of parts in flight that would need a program manager. Tracks multiple projects, ensures funding and priorities are consistent, and resolves roadblocks. Focuses on constrained resources and works to resolve them.

o Membership;

§ Program managers

o Reporting:

§ Steering committee

§ Project managers

§ Other program managers with impact considerations

o Do’s:

§ Take advantage of this group to showcase results and progress. Provide visual and data rich presentation.

§ Status reporting cadence frequency is greater the steering committee.

o Don’t:

§ xxx

o Accountability

§ Ensure overall project is on track.

· Project Management:

o Provides day to day direction at the project level. The project is normally focused on a single defined effort. Examples; build a new web page; create a new function, connect two or more current functions, etc. Project manager tack progress, look for obstacles, remove roadblocks, and keep the project on schedule and budget

o Membership;

§ Project managers

§ Resource manages (if involved)

o Reporting:

§ Project management

§ Other project managers

§ Development team including test, documentation, release, etc.

o Do’s:

§ Take advantage of this group to showcase results and progress. Provide visual and data rich presentation.

§ Status reporting cadence frequency is greater the steering committee.

o Accountability

§ Ensure overall project is on track.

This is a very basic overview of what governance is all about.

If you want to go deep

A long read

Dave

(De-dup) (De-dup) == (de-dup + pointer)

2010-05-05T16:05:00.000-07:00

Why do I care?

Deduplication (de-dup) commonly refers to the management of data such that redundant data is compressed (de-dup’ed) without any data lost. Wow, that’s a mouth full. We need to break this down into easier to consume concepts. Note, while at Sun Microsystems I worked on ZFS. One of the last projects within the ZFS space I helped was the addition of de-dup.

Lots of data looks the same. An e-mail sent to 100 people with a 1M file attached looks the same to the system. First, stop sending large file. Use google doc’s. or some such practice. The total cost of ownership (TCO) is now 100M of storage for just one email! More complex real world examples are:

Sending a large file to your remote site (i.e. moving market data around the world following the open markets).
Full backups of your business environment.
VMware virtual environments.

I’ll take you though a simple example to illustrate how de-dup works.

Application A does a write of “Hello World”

As you can see “Hello World” is now on the disk and we have incremented a counter.

Note, we did not write “Hello World” again but only updated File B to include a pointer the “Hello World” and incremented our counter.

Note, we wrote more data then just “Hello World” however it was blocked such that we could take advantage of de-dup.

We performed a “delete”. Note, we did not remove “Hello World” but we did remove the pointer to it from File A and decremented the counter. Once the pointer goes to zero then we can truly delete “Hello World”.

This has been a very simplistic overview of how de-dup works. The net is full of very detailed data on this subject.

Why do you care? Cost saving on storage devices, cooling, management of data, cost to backup, reduced carbon footprint, and recycling of old hardware. I’m sure the list is greater.

Take a moment to enquire about the environment you are developing in. Does it have a de-dup’ed backend service? Imagine telling your client that based on your review of their new application they will need to buy 100% more storage by year end. The client then starts speaking in tongues or worst. But wait I might have a solution for you. Lets deploy a de-duplication based storage solution. You should only see about a 10% increase in storage. Plus you might already have the correct hardware. So, lets do a bit more work before we draw what might be the wrong conclusion.

Dave

Brief history of NFS v4 - A Development Manager's view

2010-04-29T11:29:00.000-07:00

Hello IETF & NFS v4,

While at Sun Microsystems I had the opportunity to lead the development of NFS v4. Now that I work at Thoughtworks as a consultant I felt it was time to capture a bit of history before it fades into the distant past.

I'm already a bit fussy on how NFS v4 got started. NFS v3 still had lots of love in the Network Attach Storage (NAS) community. To my surprise and disappointment there were still some major players still using NFS v2. Lets just say that some big folks in Detroit were still using V2 due to problems with another companies V3 implementation.

December 2000 was the official start of the working group. Internet Engineering Task Force (IETF) would be where we proposed and developed NFS v4. Note, NFS does not stand for anything. Its just NFS. Our legal department, the development community, and just about everyone would correct me if I tried to give it a real name. And there are several not so complimentary names around.

So off we go to the IETF. Spencer Shepler was document author (I'm a bit fuzzy here but Rob Thurlow was co-lead, I think. But not for long) and co-lead with Brian Pawlowski of Network Appliance (stock:NTAP). The IETF development process basically follows this process. Work on design via e-mail for several months, meet three times a year for a face to face meetings, and then back to e-mail. Its an open development model. Anyone from large corporations to students can have an impact on the development of an internet standard.

For NFS v4 to become a standard one must present the IETF with at least two independently developed implementation. When I looked around the IEFT meetings I saw lots of appliance folks. These outfits were only concerned with service side implementation. Plus there was one windows client development crew. Not sure I would have met the requirement. And Linux was really starting to bet legs in the market.

Therefore, I (Sun) funded the Center for Information Technology Integration (CITI) group at the University of Michigan. We funded them to build both client and server for Linux. As one of the members of the IEFT community said, "A stroke of genius!" Both NFS v4 lead development companies benefited from this relationship. We hired their graduates who already had experience developing NFS. I loved joking that we had the only engineer in the world that had worked on two implements of NFS v4 before it shipped.

Now we had at least 5 companies and CITI developing NFS v4. So, how does one keep all these independent moving parts heading in the same direction, improving the spec as we go, and try to deliver at around the same time?

Connectathons and Bakeoffs & The NFS Conference

Connectathon was an event I directed for several years. It will be a subject for another blog however basically its a plugfest. Everyone with a server or client or both that supported an IETF standard protocol would meet once a year to test their implementation. This was an engineer to engineer event. In other words no marketing, no management, no product manager just folks that could develop and test a protocol. This was an annual event.

Bakeoffs were just smaller more focused Connectathons for NFS v4 developers only. We held them three time throughout the year.

The NFS Conference was an event I developed. This annual event brought together all the thought leaders in the NFS space. Lots of company's would present their product road maps, technology directions, and update the community on their thoughts. This meeting was held once a year. All the developers of NFS v4 would also meet there to review progress and layout plans for the next Connectathon or Bakeoff.

Back to the question - how does one keep all this motion in alignment? Meeting or better put "meet ups." Like the stand ups we do daily at Thoughtworks. This is where you have to bring all your stuff and try to play with everyone else is stuff. One hates to show to a party empty handed. So, four times a year all of us would get together, connect all our systems, and see who has what working (all under NDA). Sometime we'd lead, sometime we'd followed, but I could tell who was fully in the game and who was just there to watch.

Meetings after meetings we would find problems with the specification, our implementation or some other part of the system. The engineers would work these out at either the meetings or over e-mail. Life continued like this for a long time. One of the leads said in jest, "Dave, NFS v4 is not a protocol; its a career!" He is now a CTO. I wonder if he still fells that way.

All good things (efforts) come to an end. We released NFS v4 with Solaris 10. It was on January 31, 2005. Some 5 years after we started. Wow! All new code for an all (most) new protocol.

Feature set:

Improved access and good performance on the Internet.

"Good performance" is kinda of a tricky thing. What's does that really mean?

Strong security with negotiation built into the protocol.

Kerberos; industrial strength.

Good cross-platform interoperability.

Plays well with Windows concepts

Designed for protocol extensions

Do checkout NFS v4.1 and beyond. Some very cool happening there.

For complete details see NFS v4 at IEFT

If one could do something over I would:

Used Agile development methodology
Constrain scope - deliver smaller incremental value
Use a cross company program office

That said, I had a blast, worked with very bright Engineers (dev and test), Managers, Program Managers, and the list goes on and on. I'd credit individuals, however, I'm sure I'd forget someone therefore won't even try.

Dave

Embrace the Khaos

2010-04-27T15:51:00.000-07:00

The Manifesto for Agile Software Development states:

Individuals and interactions over processes and tools

Clearly a call to action. The action being let the people and their interactions lead. Very clear. Easy to follow. We'll build a system, an Agile development system. We'll staff all the right people, Developers, Interation Managers, Business Analysis, Systems Analysis, Program Managers, and Automated Test Developers. We buy a bunch of software licenses, some desktops, some servers, a few desks and chairs. We'll give them all a few tools; their tools. Then we'll just get out of their way.

Oops someone forgot the Client. The folks writing the check. The folks who have a clearly defined vision of their business need. We are, after all, there to create business value (Working software over comprehensive documentation).

The client has lots of business expertize. They built or maintain or are growing a ongoing concern. They make money. The only reason to be in business (from my MBA days). Plus they have a staff that's doing the same work as you are proposing.

Yup, normally (there are exceptions) they have staff doing just what you have been employed to do. Their staff may have an unacceptable backlog, higher priority development needs with limit time, lack the skills needed to address a given business need, or whatever created an opportunity for your engagement.

"They" the clients staff can and will have control of your effort. They can set:

The architecture direction
Choose the framework
The tools
Coding standards
The pacing of development

Just to name a few.

The client's control may conflict with your Agile training, background, and perceive ability to create the business value in a cost effective Agile manner.

Your natural tendency is to stay true to your Agile background. Don't.
You will want to force the client, for the clients good, to let you do your job. They won't.

Let go - Embrace the Chaos

We success or fail as a team. The team is a full rich collection of members including the developers and testers, the BA's and SA's, and the client. I would even ask you to stretch your list to include finance, the "C's", and even the folks that clean the building. It takes all of us to make this happen.

This is no "one" way or one "right" way. There are lots of ways. Agile allows us to focus on the people and the results.