Merry Christmas
Wonderful. Counselor. The Everlasting Father. The Prince of Peace.
3: Know My Customer
I'm an engineer; or I was formerly one. Well at least I used to write code for a living. And that gives me insight into a secret engineering credo: we are our own customers!
You see proof of this secret all over the software you use.
Example 1: You click on a button and receive an error message like the following: Function lpzWinRandomFunction returned 0xfe02facd.
Example 2: What should be simple functions (like mail merge) in popular software programs actually require end-users to write "code" in order to get them to work properly (e.g. if/then/else statements, db queries, formatting).
Example 3: Features which have major bugs are left in the software with the excuse that: "It doesn't happen all that often--and the user can just re-start or re-boot. No big deal..."
This kind of stuff is infuriating. It's why software development gets such a bad reputation. Consumers don't tolerate that kind of negligence with their toaster or with their TV. But the industry has been conditioned to tolerate it with software.
We're trying valiantly to be different in our department. Warning: we're not remotely perfect on what I'm going to talk about here. But this is why we have this principle listed: so that we can put it in the forefront of our department's focus.
Good software development starts with understanding one's customer. This can be quite a difficult endeavor. One can always question who the customer is: Is it the Product Manager requesting the solution or feature? Is it his management? Is it the end-user using the feature(s)? And what do we do when priorities conflict among those three. This is a continual struggle for us.
We're doing a couple of things to help with this problem and to better understand our customers.
1) We're dedicating development resources to customers (or portfolios of customers who have similar businesses). We don't actually change the reporting relationship of those developers, moving them to those departments. Not moving them allows us to keep the ability to have a career path and to create centers of excellence in development methodologies, good coding & qa practices, etc. But we leave developers focused on a customer from one project to the next. Critical context is retained as developers continue to understand a customer deeper and deeper.
2) We're dedicating infrastructure generalists to customers so that customers don't have to wade through the technical silos that infrastructure specialization demands.
3) We're designing iteratively, relying on prototypes. This allows us to have a great idea of what the customer is looking for before we ever start coding heavily.
4) We engage users in testing. We try to take each iteration from our dev environments, through test and staging and into production each milestone. We then ask our users (or subsets of our users) to help us test the bits.
5) We test internationally. This is a hard mindset to change for us. Because the development team is in the U.S., it's easy sometimes to think of the international areas last. We're trying to change that and simultaneously design and ship our solutions in the U.S. and at least a couple of other countries simultaneously. We can't always do it all of the time, but we're doing better at doing a few simultaneously to make sure we iron out localization bugs.
6) We're trying to focus on "listening." It's easy for engineers to be arrogant--to think we know better than others. But that can't be the case. We have to listen or we can't really understand what problems we (and our customers) are trying to solve. Some of the times we have to listen "between the lines," so to speak, where a customer knows that something is wrong, but they aren't quite sure what it is--or what the solution might be. This is an art we practice.
I know it sounds cliche--that we need to "know our customers," but it's a focus that we've needed in our department and one that we're improving upon.
Amazing People
Tadd Giles and I have worked together for nearly 10 years. Tadd has always been a passionate man with bundles of infectious energy. He's purely amazing. He now manages the interaction design team for the Church.
When I first met him and hired him to come join a new group I was going to be managing he was a large man. When I saw him a couple of months later on his first day on the new job, he had become an exercize and "eating right" machine, and had shed many pounds.
Fast forward to today. Somewhere along the way he fell into old habits or whatever and put a few pounds back on. So what does Tadd do?
Tadd has started a contest he calls "Win a Shuffle." He will weigh himself on 12/31/06. He invites his co-workers, family and friends to do the same. He will then weigh himself on 3/31/07. Tadd will personally buy an ipod shuffle for anyone who loses more weight (as a percentage of total body weight) than Tadd during that period.
?!
You read correctly. Over 70 people and counting have signed up so far. This is amazing to me on so many counts. First, Tadd will probably win. He's just that determined. Second, he's not requiring anyone to weigh themselves in front of him. He's just trusting in people's good will. Third, he's willing to put his money where his mouth is, and it could frankly end up being a whole lotta money. Fourth, he has inspired many people to join him; and those people will lose weight along with him. If he wins, he wins! If he loses, he still wins!! That kind of inspiration is flat-out inspirational to me. He's even created a simple web site to track progress so everyone can help encourage one another. I love it! Finally, his creativity and charisma are astounding. Yes, he got the idea from the show The Biggest Loser, but who comes up with implementing the same idea in his own company with his own peers with a web site and a cash-out-of-his-own-pocket prize? Answer? Tadd.
I'm sorry. This has really nothing to do with technology at the Church. But I thought I'd share because I think it's pretty cool. Go Tadd! And go everyone who is joining in the endeavor!
Comments
I'm moderating the comments personally initially so I'm inundated. I'll try to answer the questions as I can. Forgive me if I'm slow. :)
I'll probably be a little more selective when I turn comments on so as not to encourage feedback in cases where I won't have time to answer.
Thanks so much for your interest!
2: Receive Revelation
This is the second of the attributes we use to describe the culture we want to embrace at the Church's I.T. department.
We work for the Church which means we work for the Lord. We believe we have the right to call on him to help guide us in our work. And we do it. We start many meetings with prayer. Each Monday morning our I.T. leadership staff meeting begins with a "spirited" hymn, a prayer and a spiritual thought. We often have general authority devotionals in our all-hands meetings where we have opportunities to be instructed and to receive inspiration.
There is ample opportunity to receive revelation in an environment rich with spiritual nutrients. It's one of the great blessings of working at the Church, though it has taken some getting use to on my part.
NOTE: I originally referred to the Church's environment as being "rich in spiritual fertilizer" but some of my staff thought that was probably inappropriate. :)
New LDS Newsroom Web Site
This is an example of a complete re-write of a web site with new technology, new content and a new supporting content management process. This solution took only a few months and, going forward, requires no development to update content.
The audience of the web site is "news media, opinion leaders and the public."
We're still working on a few bugs so be patient with us.
Book Club: Leadership and Self-Deception
1: World Class I.T.
How good does the Church I.T. department really need to be, anyway?
We have to be the best--the absolute best. The Lord and the Church deserve the best computer systems and solutions possible. And our group is focused on adapting our people, processes & systems to enable that to happen. My predecssor (Eric Denna) made a big deal out of stating that we wanted to be a "World Class I.T. Organization." So why state that? How obvious can a goal be?
It's suprising how many people both in our department and among our customers don't have that expectation of us. "You're improving," say many. "You don't need to be the best. You just need to be 'good enough,'" say others.
That didn't sit well with Eric, and it doesn't sit well with me. I visit other countries occasionally in the course of my job. I always try to meet local members of the Church. These are wonderful people. They're faithful, smart, spiritual people. And they pay tithing, just like people in the U.S. do. I consider it a sacred duty to spend that money carefully.
Which is why we have to be world class. We need to spend every I.T. dollar as efficiently and effectively possible. We need to be wise in using a thorough "business case" analysis for each solution we consider. We need to be efficient in creating, implementing, running and retiring systems. We need to pay enough to engage the kinds of people we need, but not so much as to be wasteful or to attract people who are just coming here for the money. We need to have rock-hard security and mature ITIL operational processes. We need to create solutions which solve real customer needs.
We can't get by with "good enough." "Good enough" is wasteful. "Good enough" isn't good enough.
We need to be and we CAN be World Class.
Organizations are like People
Take software companies.
The following roughly describe some actual individuals I know:
- Woman: steady, attentive to details, and averse to big risks.
- Boy: creative, brilliant and unfocused.
- Girl: thoughtful, honest and passive.
- Man: litigious, aggressive, and arrogant.
If you look at each carefully, you'll also see the personality of at least one software company.
I initially went through significant culture shock in coming from Microsoft to the Church. It was like dancing with two completely different partners. Microsoft is an environment where confrontation and debate rule the day, where decisions are usually made based on the bottom line, and where a meritocracy allows young, sometimes impetuous leaders to rise quickly through the ranks, creating a wake as they rise. The Church is... Well... Not like that. Decisions are made based on revelation and a deep concern for the members of the Church. Confrontation and debate is replaced by consideration and respect. Leaders are typically much more mature and steady. Imagine how typical management challenges like recruiting, process design, performance management, and policy compliance would be different in those two environments.
With that in mind, we set out to define the personality, or culture, we wanted our organization to embody. This is way more challenging than it sounds. As a leadership team, we sat down and created a list of attributes we thought represented the organization we felt we could become and which would be most effective in the Church environment. We left off wholly obvious things like "we're honest" and "we believe the Church is true." Some of the things which made the list, however, might seem obvious but needed reinforcement.
These attributes we codified apply to the I.T. department of the Church only. Other groups within the Church have similar, but different sets. I should mention that the book Journey to the Emerald City provided a very valuable context and framework for thinking about these "cultural beliefs." Hyrum Smith's work on having a "personal constitution" was also influential.
Over the next few weeks, I'll list and explain these attributes as I get time. Feel free to comment and I'll post some of the interesting and relevant ones.
COMMENTS ON.
Open Source
The promise of open source, I guess, is free software which is more stable because the world is helping to find and fix your bugs. What's not to love? We'd love it to work out that way more often. We've had some success using open source stuff, but we've also had some problems. Following are a few random places we've dabbled.
1) Java Stack. We use several open source components for our java stack (including Hibernate, Spring and others). It has been painful for us to integrate these all into a common stack, and we've done most of that work ourselves. Now that it's done, our developers are extremely productive in it. You have to ask if the money we've spent developing and the money we will spend keeping it up-to-date is worth the "vendor independence" we gain from not buying some commercial offering. To date we think we're still on the right path, but we'll be watching carefully as tools mature.
2) Linux. Linux is free! Or we wish it were. We pay for libraries we need, we pay for integration services and we pay for support. We hope we won't end up paying for using the IP in Linux, but one never knows. "Free" just doesn't mean what it used to mean.
3) Nagios. We use Nagios for monitoring in our data center. This has been a pretty good experience for us so far. Some of our developers have contributed back to this project (see next point).
4) Contribution. I'm conflicted on having developers contribute to open source projects. On one hand, it's the polite thing to do. You take from the community--you should give back. In addition developers think it's cool to contribute to open source projects. It's a badge of honor, in a way. On the other hand, there are some downsides. First, you risk legal & intellectual property issues if people aren't careful. Second, it can be a massive productivity drain. If you have developers on staff (or if you're a developer interested in getting involved) be cautious. You'd be shocked out how much time can whir by as a developer gets involved in both downloading and contributing to open source projects. It's one thing to download and use the binaries. It's another thing altogether to download the source, modify it, build it, test it and then check your changes back into the sky.
5) Feature Sets. I've found the feature sets wanting in some of the open source software I've played with. OpenOffice is getting much better, but still misses some of those key little features I'm used to in MS Office. I'm hoping it catches up. I've yet to find an email/calendaring systems that comes close to Exchange & Outlook. Open source ERP? Don't we wish? It seems like almost all of the Open Source we might care about is "getting close" or "almost there."
To be clear, I love the idea of Open Source. However it's not the panacea that many would claim. There are hidden costs and feature/service tradeoffs to be made. We carefully weigh each option (both the proprietary and the open source alternatives) and try to make decisions on the merits.
There is an interesting place we'd like to use the open source concepts, however. If you're like me, you've developed a number of spreadsheets, databases and simple apps to help with various callings you've had. We'd like to make that easier for developers to do and to share what they've done. Stay tuned. I'll be talking more on the blog about how we're going about making that happen...
LDS Church Tech Talks
The audience is intended to be software and system engineers who have an interest in what we're doing at the Church.
What topics would you be interested in?
Comments are ON.
Developing Church Software
* The MLS software used by ward clerks
* ERP (we currently use Peoplesoft)
* Other financial (tax, GL, payments, investments, etc.)
* Supply Chain (manufacturing, inventory, retail)
* Public-facing web sites (lds.org, mormon.org, missionary application, etc.)
* Facilities management software
* Etc.
Given the diverse nature of our work, we don't take a "one size fits all" approach to our software methodology. However, for the most part we subscribe to some of the principles of Agile Software Development.
The misconception about Agile is that it is itself a software methodology. It is not. Agile is a set of principles--or preferences. The basic principles are these:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Many sling about the term "Agile" as an excuse to be reckless, ill-prepared, or undisciplined in their development.
"We don't talk about dates... we're agile."
"The customer is right! If they want to grow scope they can do it... we're agile!"
These are of course missing the point. "Agile" isn't a methodology. It isn't a panacea. It isn't a cure for disease. And it's not an excuse. A software methodology which is "Agile" will allow the developers to uncover and solve problems in real time and will allow the flexibility to swap scope as necessary. Delivery dates however can still be immutable, or at least inflexible, in an Agile software methodology. Scope can still be explored and agreed upon up front in an Agile software methodology.
I'll give you an example. We just started working on a major revision of one of the Church web sites. We plan to go live in Q1 of next year. We could have spent days or weeks or even months writing detailed specifications, getting contracts in place, negotiating, etc. But instead we worked with the Church department to create a prototype of what they wanted.
We employ a team of Interaction Designers who are just phenomenal. They can sling xhtml and css with the best of them, but they are also terrific with Photoshop. They will meet with a customer and talk through the workflow. They'll come back a few days later with a working prototype which allows the customer to give feedback based on what they see and play with, not what they read about in a 400 page document. Our interaction designers will even dummy up data for reports giving the customer a feeling for what the real deal will look like. When the prototype is all done, the customer can see precisely what we will deliver to them.
The proto for this web site is now done. We're currently working on a schedule, and we will accurately be able to predict when we'll be finished and how much it will cost.
Granted, things change once users start using the system. But that kind of change we can deal with. The changes that have been painful for us in the past are when we get nearly done with a project only to find out we didn't actually understand the customer requiements in the first place. Using protoypes as specs helps solve that problem.
I read about this approach in a book called The Inmates are Running the Asylum a number of years ago, but wasn't able to successfully implement the ideas when I managed teams at Microsoft. We never seemed to have enough Interaction Designers, or we were always in a hurry to keep developers busy so we'd skimp on up-front Interaction Design, relegating our designers to Photoshop technicians.
But we're making it work at the Church and the approach is reaping dividends for our customers.