Have a wonderful Christmas and holiday. I'm thankful for the Savior. I love him and honor his name.
Wonderful. Counselor. The Everlasting Father. The Prince of Peace.
3: Know My Customer
I know my customers, those in the field and those at headquarters.
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.
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
Wow. The response to the blog has been outstanding. I knew there were many interested in technology at the Church, but I didn't realize the interest would pick up this quickly.
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!
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
I call down the Lord's help in doing my work to aid in exalting the human family.
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. :)
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
Last night we went live with a refresh of the Church newsroom web site. The old one is here, and the new one is here.
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.
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
I've just started reading Leadership and Self-Deception, Arbringer Institute. Has anyone read it? If so, I invite your comments. If not, grab a copy and join me in reading it!
1: World Class I.T.
I contribute in making ICS a world-class IT organization that sets the standard for the industry.
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.
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
An organization is like a person. It can be healthy, sick or even dead. It can be born (or re-born). It needs to be fed and entertained. And it needs regular sleep. It's interesting to me that an organization has a personality. It can be social or private, funny or somber, passive or aggressive (or passive aggressive), steadfast or volatile , frivolous or staid.
Take software companies.
The following roughly describe some actual individuals I know:
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.
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
A number of you mentioned that you were interested in how/if the Church uses or contributes to the open source community.
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...
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
We're planning to do tech talks in SLC, Provo and in Seattle where we'll talk about some of the technologies the Church uses.
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.
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
As I mentioned in my first post, the Church is a diverse operation and therefore has a diverse toolbox of software required to operate:
* 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:
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.
* 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.
A Job that Matters
Why do you work? For prestige? For fun? For experience? For money? For scope of responsibility? For the people you work with? I have worked for all of those reasons. You wouldn't believe the feeling of working for a cause you believe in deep down in your soul!
If you're LDS and have a passion for technology then consider a job at the Church! We're looking for people who are passionate about Java, .net, middleware, networking, database, and technology in general.
You'll love the people you work with and relish the opportunity to work for a cause you love!
Check out our job site.
If you're LDS and have a passion for technology then consider a job at the Church! We're looking for people who are passionate about Java, .net, middleware, networking, database, and technology in general.
You'll love the people you work with and relish the opportunity to work for a cause you love!
Check out our job site.
German Engineering
I just got back from Frankfurt Germany. What a beautiful country! Almost no trash in the streets. The buildings are beautiful. The people are friendly. The taxis legally go 120 mph! It was a wonderful trip.
Of all the cool things about Germany, one thing stuck with me: the luggage carts! This thing isn't just an ordinary luggage cart. Oh no. As luggage carts go, this thing is a Cadillac! It's easy to push. No wobbly wheels. It's formed perfectly to fit several large pieces, and also some small ones.
So I'm walking in the Frankfurt airport and I'm pushing one of these smooth luggage carts. The man I'm walking with, John Carmichael, tells me I can take the luggage cart right up on to the escalator. I have to admit I'm a little dubious. So I give it a try.
I push it onto the flat part of the bottom of the escalator. He says: "just let go." So I let go. The brake automatically comes on when I let go. I didn't even know I was pushing a brake lever! The wheels are perfectly spaced so that one fits at the back of each step. And when the angle starts to pitch upward, the cart just leans back! I try to catch it, thinking it will fall. But it just works! The wheel guards have plenty of space so that leaning back doesn't set the wheel guards down on the step and the cart is balanced such that the cart just effortlessly glides up the escalator and is ready for me to start pushing again at the top. Amazing!
OK, doesn't sound like a big deal, right? How many airports you've been to have this feature? Not many. But someone carefully sat down and planned this feature of the airpot to create a better user experience. And then made it happen! They could have included a rear-view mirror and a horn, but they kept it simple and solved a big problem with baggage carts in an airport (namely having to wait for an elevator).
I'm sure it cost more, but it left me with a great impression of that airport.
Software developers could learn a lesson from this bit of engineering.
Our industry can vastly improve our output. We should take a lesson from the Germans.
Of all the cool things about Germany, one thing stuck with me: the luggage carts! This thing isn't just an ordinary luggage cart. Oh no. As luggage carts go, this thing is a Cadillac! It's easy to push. No wobbly wheels. It's formed perfectly to fit several large pieces, and also some small ones.
So I'm walking in the Frankfurt airport and I'm pushing one of these smooth luggage carts. The man I'm walking with, John Carmichael, tells me I can take the luggage cart right up on to the escalator. I have to admit I'm a little dubious. So I give it a try.
I push it onto the flat part of the bottom of the escalator. He says: "just let go." So I let go. The brake automatically comes on when I let go. I didn't even know I was pushing a brake lever! The wheels are perfectly spaced so that one fits at the back of each step. And when the angle starts to pitch upward, the cart just leans back! I try to catch it, thinking it will fall. But it just works! The wheel guards have plenty of space so that leaning back doesn't set the wheel guards down on the step and the cart is balanced such that the cart just effortlessly glides up the escalator and is ready for me to start pushing again at the top. Amazing!
OK, doesn't sound like a big deal, right? How many airports you've been to have this feature? Not many. But someone carefully sat down and planned this feature of the airpot to create a better user experience. And then made it happen! They could have included a rear-view mirror and a horn, but they kept it simple and solved a big problem with baggage carts in an airport (namely having to wait for an elevator).
I'm sure it cost more, but it left me with a great impression of that airport.
Software developers could learn a lesson from this bit of engineering.
- Does our software just work?
- Does the user have to think?
- Do we solve important problems, and leave the unimportant problems alone?
Our industry can vastly improve our output. We should take a lesson from the Germans.
General Conference and Languages
General conference is a semi-annual event which happens in April and October of each year. Many of the General Authorities (the leadership of the Church) give talks to the membership of the Church. I personally find these events inspirational and motivational.
Walking through the translation room during general conference is a pretty sobering experience. Everywhere you look, you see young people with ear phones and draft copies of talks. They're preparing themselves to translate the talks as they're given so that we can send out the translation as we send out the video to the world. These audio/video streams go out to all corners of the earth.
Here is just a partial list of the langauges that the Church translates (either live or as follow-on DVDs):
Albanian, Amharic, Arabic, Armenian, Aymara, Bislama, Bulgarian, Cambodian, Cantonese, Cebuano, Chuukese, Croatian, Czech, Danish, Dutch, Efik, Estonian, Fante, Fijian, Finnish, French, German, Greek, Guarani, Haitian, Hiligaynon, Hindi (Fiji), Hindi (India), Hmong, Hungarian, Icelandic, Igbo, Ilokano, Indonesian, Italian, Japanese, Kekchi, Kiribati, Korean, Kosraean, Kuna, Laotian, Latvian, Lingala, Lithuanian, Malagasy, Mam, Mandarin, Marshallese, Mongolian, Navajo, Norwegian, Palauan, Papiamento, Pohnpeian, Polish, Portuguese, Portuguese (Portugal), Quechua-Peru, Quiche, Quichua-Ecuador, Romanian, Russian, Samoan, Serbian, Sinhala, Slovak, Slovenian, Spanish, Swahili, Swedish, Tagalog, Tahitian, Tamil, Telugu, Thai, Tongan, Turkish, Twi, Ukrainian, Urdu, Vietnamese, Yapese, Yoruba
Walking through the translation room during general conference is a pretty sobering experience. Everywhere you look, you see young people with ear phones and draft copies of talks. They're preparing themselves to translate the talks as they're given so that we can send out the translation as we send out the video to the world. These audio/video streams go out to all corners of the earth.
Here is just a partial list of the langauges that the Church translates (either live or as follow-on DVDs):
Albanian, Amharic, Arabic, Armenian, Aymara, Bislama, Bulgarian, Cambodian, Cantonese, Cebuano, Chuukese, Croatian, Czech, Danish, Dutch, Efik, Estonian, Fante, Fijian, Finnish, French, German, Greek, Guarani, Haitian, Hiligaynon, Hindi (Fiji), Hindi (India), Hmong, Hungarian, Icelandic, Igbo, Ilokano, Indonesian, Italian, Japanese, Kekchi, Kiribati, Korean, Kosraean, Kuna, Laotian, Latvian, Lingala, Lithuanian, Malagasy, Mam, Mandarin, Marshallese, Mongolian, Navajo, Norwegian, Palauan, Papiamento, Pohnpeian, Polish, Portuguese, Portuguese (Portugal), Quechua-Peru, Quiche, Quichua-Ecuador, Romanian, Russian, Samoan, Serbian, Sinhala, Slovak, Slovenian, Spanish, Swahili, Swedish, Tagalog, Tahitian, Tamil, Telugu, Thai, Tongan, Turkish, Twi, Ukrainian, Urdu, Vietnamese, Yapese, Yoruba
Finnish Temple Dedication
On October 22, 2006 the LDS temple in Helsinki, Finland was dedicated by President Gordon B. Hinckley. A dedication is a gathering where members of the Church come together to celebrate an event (like the building of a new building or the anticipation of great things happening in a new area or country). A dedicatory prayer is offered by someone as part of the event.
This particular dedication is significant for a number of reasons.
It's wonderful to see how technology is used by the Church to serve the members all over the world!
For those who study Finnish in your spare time, click here.
This particular dedication is significant for a number of reasons.
- President Hinckley is the oldest living prophet the Church has had in modern times, and he's still travelling and getting the work done!
- The saints in Finland have been anxiously waiting for a temple since Finland was rededicated for the work of the Lord in the 40's.
- The proceedings were broadcast via satellite to saints in places like the Ukraine and Russia--places where a temple dedication hasn't been broadcast before and where the saints haven't before had a temple within a reasonable travelling distance.
It's wonderful to see how technology is used by the Church to serve the members all over the world!
For those who study Finnish in your spare time, click here.
I Work at my Church.
I've been a member of the Church of Jesus Christ of Latter-day Saints all of my life. When I was young, Church was a place I went on Sundays & on Wednesday nights and a code of conduct. I had no idea the Church actually had a support institution.
A buddy of mine sent an email one day and asked if I'd be interested in working for the Church. Sounded intriguing, but I frankly had no idea of the scale of the Church's operation.
Think about it, though. The LDS Church:
In short the Church is more than just a Church; it's an enterprise. But it's an enterprise with inspired leaders, with employees who are faithful members, and with an extended work force of millions of members who are willing to contribute their time, talents and money to the Church.
I met Eric Denna, who was then the CIO, and others and was intrigued, but I wasn't ready: maybe some day.
After working for Microsoft in Redmond, WA for almost 11 years, our family moved to Utah ostensibly so that we could be closer to extended family, but actually so that we wouldn't have to take all of our vacations in Utah.
The Church called again and asked if I was interested. I felt like our family had been blessed so much that we ought to try to give back. We were already living in Utah, and I was driving my wife crazy trying to figure out whether to start a software company or teach school.
You could have heard a pin drop when I told my friends back at Microsoft that I was going to work at "my Church."
"Huh? Does your chapel have a server or something?"
"Wow. How much do they pay?"
"So are you maximizing profits or prophets?"
"Who's your competition?"
And so on. I had decided that it would be a fun challenge and an exciting opportunity to make a difference to an organization I care very deeply about.
So here I am.
In this blog, I'll talk about the technology we use at the Church, about what it's like to work at the Church and some random musings about this or that. I take responsibility for anything I say here.
I hope I can say something useful.
A buddy of mine sent an email one day and asked if I'd be interested in working for the Church. Sounded intriguing, but I frankly had no idea of the scale of the Church's operation.
Think about it, though. The LDS Church:
- uses a global satellite system to broadcast general conference translated into hundreds of languages.
- has web sites which service almost 5 millions users per month with over 40 million unique page views per month.
- builds and services thousands of chapels and hundreds of temples all over the world.
- has a large-scale welfare operation which manufacturers, packages, inventories, and distributes goods all over the world and which mobilizes massive relief operations in emergencies.
- keeps track of, supports and distributes the Gospel message for over 12 million members.
- has an employee base and mission-critical systems to support the varied Church functions: missionary and temple work, priesthood leadership, tax, finance, investments, printing, translation & distribution of content, collection of tithes, employee travel, human resources, and many more.
In short the Church is more than just a Church; it's an enterprise. But it's an enterprise with inspired leaders, with employees who are faithful members, and with an extended work force of millions of members who are willing to contribute their time, talents and money to the Church.
I met Eric Denna, who was then the CIO, and others and was intrigued, but I wasn't ready: maybe some day.
After working for Microsoft in Redmond, WA for almost 11 years, our family moved to Utah ostensibly so that we could be closer to extended family, but actually so that we wouldn't have to take all of our vacations in Utah.
The Church called again and asked if I was interested. I felt like our family had been blessed so much that we ought to try to give back. We were already living in Utah, and I was driving my wife crazy trying to figure out whether to start a software company or teach school.
You could have heard a pin drop when I told my friends back at Microsoft that I was going to work at "my Church."
"Huh? Does your chapel have a server or something?"
"Wow. How much do they pay?"
"So are you maximizing profits or prophets?"
"Who's your competition?"
And so on. I had decided that it would be a fun challenge and an exciting opportunity to make a difference to an organization I care very deeply about.
So here I am.
In this blog, I'll talk about the technology we use at the Church, about what it's like to work at the Church and some random musings about this or that. I take responsibility for anything I say here.
I hope I can say something useful.
Subscribe to:
Comments (Atom)