|
With the global reach of the Church, members from around the world are curious about the type of technical work we do. This web site is designed to give you a glimpse into that work and how you can get involved.
|
|
|
|
Written by Lorin Romrell
|
|
Thursday, 15 May 2008 |
“Who tested this thing?” is a question we hope the customer never needs to ask. Software should just work, without explanations and without workarounds. In the movie My Big Fat Greek Wedding, the bride’s father carried around a bottle of Windex, which he claimed was the cure for all kinds of physical ailments in addition to being a great cleanser. When presented with a problem, he would say: “Just spray some Windex on it!” There are some in our industry who share this notion when it comes to testing software. It’s all too easy to just focus getting a project “completed” and then “spray on some quality” at the end. I’ve never seen a good outcome from this approach. The results are very painful for the customer and breach the very trust we are striving to build.
It’s been great to be a part of the evolution of Quality Assurance in ICS. In the past, our numbers were so small that we only “sprayed a little QA on” before projects went to the customer. We realized we needed to grow to be successful. This growth happened very rapidly and often miraculously, but the results have been excellent. We have been careful in how we scrutinized potential candidates for both the best skills and the best team fit.
As we grew, some teams welcomed the addition of QA resources and experienced enough benefit that they soon asked for more! Other teams were reluctant and asked: “Who are these people? What do they really think they can do to help?” Their reaction was not surprising since many teams had little or no exposure to QA. As we grow, QA is no longer an afterthought. ICS implemented basic changes that standardized defect tracking, identified user stories, introduced automated regression testing, started methodical approaches to product deployment, required continuous builds, and implemented many other fundamental building blocks for building quality software. QA was not solely responsible for all of these improvements, but as a larger ICS organization we have been driving to higher standards and greater quality. The organization now relies far more on our QA group. We now have a software development process where QA engages early in the planning stages and remains engaged throughout the entire project. With this early involvement, we are able to reduce project risk. It’s amazing just how fast a vague requirement is clarified when you think about how you will test it. Since many projects rely heavily on test automation, this early involvement helps us make critical design decisions up front, saving time later on. We have a strong working relationship with our peer groups and this continues to be critical. We work closely with interaction designers in reviewing prototypes. Many issues are resolved in the design, before coding even begins. Software developers have also engaged with QA to make applications more testable. We’ve found that working in close proximity with our peer groups helps all to identify issues quickly and solve them early—while it’s cheapest to solve them.
Now that we have some of the basics in place and are engaged with all of the project teams, there are several areas where we need to improve. We need to increase the rate at which knowledge flows through our QA organization. For example, if one team has a more efficient way for performance testing a product, we want to share that with others. We need to further standardize and centralize our metrics to provide meaningful data to our entire department. These metrics and reports need to monitor every critical step in our processes. The information should be accessible and usable from the top of the organization down to individual projects and teams. We need to expand our testing to help build in maintainability. We need to better understand scalability and release solutions that will grow with the Church. We need to increase our vision, our productivity, and our capabilities to fulfill the needs of the Church.
As we improve in these areas, we will be able to throw away the Windex bottle for good.
|
|
Written by Jayson Christianson
|
|
Monday, 12 May 2008 |
|
We have all heard the stereotypes: Computer guys are hard to deal with. They speak another language, they have no patience for those who cannot understand as quickly as they can, and they have little ability to effectively communicate what is wrong with the way someone is using the computer or software.
Unfortunately, (or fortunately, however you choose to look at it), most of the time we computer folk do not create software for our own kind. We create software for everyone else. This cultural clash can result in a disconnect between the development team and the people for whom the software is built: the customer.
To be better able to meet our customer’s needs, we need to understand who they are and what makes them do things the way they do. It is not up to us to decide how a customer should do something. It is up to us to design and develop software that enables our customers to get their jobs done more efficiently.
“But really,” you ask, “sometimes the customer wants to do something that makes no sense.” It is human nature to prefer to do things in a way that is familiar to you. You have probably never thought about most of your actions in an analytical way. Imagine if you were tasked to explain to someone what it means to be an American (or any other nationality). You don’t normally think about it. You just are. It is in your nature to make assumptions about these unwritten behaviors and project those onto another person or group. Someone from a different culture examining your lifestyle could likely fill volumes, whereas you could probably only fill pages. Similarly, customers may not know why they do things a certain way. We tend to project our ways of doing things onto them and their processes.
Cultures differ across countries, counties, cities, across departments in large corporations, and even teams (think about the .NET team vs. the java team). When observing someone else’s culture, it is natural to describe only the differences and to do this in mostly negative terms. “They don’t do this . . . ” or “They don’t understand why it is better to do it my way. . . .” In reality, your way is probably not better. It is true that there might be a better way, and it is important to help the customer see that. However, before judging and condemning the situation, take some time to understand the customers’ culture and why they perform certain tasks the way they do.
So, how does all this lead to better-quality software? No matter who you are or what position you hold on a team, understanding of your customer’s culture can help you produce better software. From user interaction to development to testing, knowing the fundamental and cultural reasons why a customer would prefer one thing over another can help you deliver a software solution that better meets customer needs. It will also help develop better working relationships with our customers as they begin to feel that we really understand them and their processes. The more they trust us, the more they will open up to us and be willing to work with us. When we realize that building software is not simply about gathering and implementing technical requirements, we can grow into the role of a trusted partner faster and with less conflicts and cultural clashes.
Many of the ideas presented only touch on the expanding science of “Cultural Intelligence.” Take some time to understand and assess your own skills in working within another culture. More information can be found here:
|
|
Written by Cassie Telford
|
|
Wednesday, 07 May 2008 |
FamilySearch has announced an exciting project that will make millions of historical British military records easily accessible on the Internet—a boon for those with British ancestry.
This is a three-year project utilizing the combined efforts of the U.K. family history Web site findmypast.com, The National Archives of the United Kingdom, and FamilySearch. The trio will work together to digitize and index nine million images from the War Office’s Royal Hospital Chelsea Soldiers’ Service documents dating from 1760 and Militia Attestation Papers documents from 1870 through 1913.
These are very rich documents. Many of the 20th-century records of merchant seamen include portraits, personal details, and summaries of the voyages. They also include people of many nationalities and women’s service records. Many of the War Office’s Royal Hospital Chelsea Solders’ Service documents include information about service history, physical appearance, personal conduct, previous occupations, family details, and sometimes even a reason for discharge.
|
|
Written by Joel Dehlin
|
|
Tuesday, 06 May 2008 |
|
A young man I was teaching in a Sunday School class today introduced me to ChaCha.
ChaCha is a question-answering service for mobile devices. I tried it and it’s pretty cool.
You just send a text message with a question to CHACHA (242242). For fun, I typed my first question this afternoon: “How long is a marathon?” I got an answer in just a couple of minutes:
The marathon is a long-distance running event with an official distance of 42.195 kilometers (26 miles 385 yards) road race.
Visit Joel’s blog to read the entire article. |
|
Written by Cassie Telford
|
|
Monday, 05 May 2008 |
|
Did you know that multiple Church music files are available to download? You can obtain them in groupings of 25 as music only or as music and voice files. Sheet music is also available. All three of these formats are available for The Church of Jesus Christ of Latter-day Saints Hymns, Children’s Songbook, seminary music (video soundtracks from CDs), Young Women’s camp, and other selected songs. A course book and music-only files are available for the Conducting Course and the Keyboard Course. |
|
Written by Joel Dehlin
|
|
Friday, 02 May 2008 |
|
Freakonomics is one of the blogs I track that I actually try to read. Recently, Fred Shapiro (Yale Book of Quotations) has been blegging to find quotes that sound outlandish and are attributed to famous people.
For example,
“There is no reason for any individual to have a computer in his home” is attributed to Kenneth Olsen, founder of DEC.
Visit Joel’s blog to read the entire article.
|
| | << Start < Prev 1 2 3 4 5 6 Next > End >>
| | Results 1 - 11 of 56 |
|
