Better software may_june_2012

783 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
783
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Better software may_june_2012

  1. 1. ig Ht PL an so ft wa re te st ing fL of lea rn ing , September 30– Ch oo se fro m a ful l we ek ne tw ork ing , an d mo re October 5, 2012 su nday sse s an d Mu lti -da y tr ain ing Cla Anaheim, CA Bo nu s se ssi on s be gin Disneyland Hotel Mo nday –t ue sday ful l-d ay 31 in- de pth ha lf- an d tu tor ial s ay we dn es day– tH ur sd 5 Ke yn ote s, 42 Co nc ur ren t tw ork ing RegisteR by August 3, 2012 se ssi on s, the eX Po , ne ev en ts, re cep tio ns , Bo nu s A N D s AV e u P t O $ 4 0 0 se ssi on s, an d mo re gROuPs Of 3 sAVe eVeN mORe! fr iday hip summit testing & Quality Leaders so ftw are wo rk sh op on re gu lat ed te sti ng (w re st )www.sqe.com/starwest
  2. 2. May/June 2012 $9.95 www.TechWell.com MAYDAY! MAYDAY! Projects in peril THE NEED FOR SPEED Testing at the speed of mobile
  3. 3. Visual Studioisn’t just fordevelopers.For a limited time, you can save 20%on Visual Studio Test Professional 2010with MSDN.Testing Tools.Visual Studio Test Professional 2010 with MSDNis packed with integrated testing features like testcase management, manual test execution, manualtest record and playback, and lab managementconfiguration to ensure the delivery of qualitycode every time.Integrated ALM tools.Collaborate and communicate effectively at everylevel, and gain visibility into real project status toensure the delivery of high-quality solutions whilereducing costs.Everything you need with MSDN.An MSDN subscription provides a comprehensiveset of resources including development and testlicenses, plus training, support, and access tocritical information for developing on theMicrosoft platform. Find out how you can save today on Visual Studio with MSDN at: www.microsoft.com/visualstudio/save/en-us
  4. 4. fall 2012 ScheduleSan Jose, CA August 21–23 Austin, TX October 16–18Boston, MA August 21–23 Tampa, FL October 22–24 Earn up to 37.5 PDUsCharlotte, NC August 28–30 Chicago, IL October 23–25Minneapolis, MN September 11–13 Bethesda, MD Oct. 29–Nov. 2 Become a certified software tester and... (Advanced Testing Training Week)Santa Fe, NM September 11–13 Philadelphia, PA Oct. 30–Nov. 1 • Increase your value in both your organization andWashington, D.C. September 17–19 the industry Raleigh, NC Oct. 30–Nov. 1Atlanta, GA September 25–27 Bethesda, MD Oct. 30–Nov. 1 • Stand out from your peers with your professionalToronto, ON September 25–27 certification Orlando, FL November 4–6Anaheim, CA September 30–Oct. 2 • Demonstrate you have the knowledge and skills San Francisco, CA November 12–14St. Louis, MO October 9–11 needed for your everyday software testing challenges Vancouver, BC November 13–15Pittsburgh, PA October 9–11 • Benefit from the most widely recognized and fastest Phoenix, AZ December 4–6Portland, OR October 9–11 growing software tester certification in the worldNY/NJ Area October 16–18www.sqetraining.com/certification SQE TRAINING
  5. 5. Three time zones, one solutionApplication Lifecycle Management with Industry Leading Performance and Scalability • First Ever With Built-in Multi-site Support • Native iPad and Android Tablet Applications • Full Traceability Through: - Portfolio - Requirements - Development - QA Testing
  6. 6. Volume 14, Issue 3 • May/June 2012 22 C ON T ENTS features 18 COVER STORY Traditional Test Engineering, Your Days Are Numbered Turning Software Quality on Its Head, Part 2 In the first installment of this article, Dr. James Whittaker discussed revital- izing and improving the value of late-stage testing. James also discussed ideas behind empowering your dogfooders, testers, and the crowd to sig- nificantly and efficiently improve software quality. In part two, Jason Arbon discusses the research and engineering experimentation behind realizing these ideas into new tools and processes. by Jason Arbon 18 22 AGILE CODE FOR AGILE TEAMS What makes a team agile? Is it in the way it plans projects, or how it engi- neers its products? In this article, Steve Berczuk explains how agile code and technical practices can help a team stay agile across the product lifecycle. by Steve Berczuk 26 SELECTING THE RIGHT MOBILE TESTING SOLUTION The mobile market dynamics are extreme, unpredictable, and fragmented. There are numerous operating systems and a multitude of platform versions, networks, hardware, and form factors making it a challenge to maintain mo- bile application quality. Find out how to adjust to the shift from traditional to mobile development—which additional elements are a must and which ones 26 can be maintained. by Yoram Mizrachi in every issue Mark Your Calendar 4 columns Contributors 7 11 TECHNICALLY SPEAKING CONTROLLED FLIGHT INTO TERRAIN • by Lee Copeland Editors Note 9 Entering a holding pattern on a project can give you the opportunity to gather Virtual Resource Shelf 16 additional information about a problem. But, sometimes, holding consumes valuable resources with disastrous consequences. From One Expert to Another 17 14 MANAGEMENT CHRONICLES Product THE MYTH OF 100% UTILIZATION • by Johanna Rothman Announcements 32 Too many managers believe in the myth of 100% utilization—the belief that FAQ 34 every single technical person must be fully utilized every single minute of every single day. This leaves no time for innovation, no time for serendipi- Ad Index 36 tous thinking, no time for exploration, and it often leads to a less successful Better Software magazine—The print organization. companion to TechWell.com brings you the hands-on, knowledge-building informationyou need to run smarter projects and deliver 35 CAREER DEVELOPMENT better products that win in the marketplace and positively affect the bottom line. LEVERAGE REVERSE MENTORING TO POSITIVELY IMPACT YOUR Subscribe today to get six issues. ORGANIZATION • by Mukesh Sharma Visit www.BetterSoftware.com Introducing a reverse mentoring program provides both employees and or call 800.450.7854. managers benefits beyond simply learning a new technology or skill. Find out how to introduce a reverse mentoring program in your organization. www.TechWell.com MAY/JUNE 2012 BETTER SOFTWARE 3
  7. 7. MARK YOUR CALENDAR SQE TRAINING software tester certificationtraining weeks www.sqetraining.com/certification Publisherwww.sqetraining.com/trainingweek June 4–6, 2012 Software Quality Engineering, Inc. Chicago, ILTesting Training Weeks President/CEOJune 4–8, 2012 June 10–12, 2012Chicago, IL Wayne Middleton Las Vegas, NV Vice President of CommunicationsSeptember 17–21, 2012 June 19–21, 2012Washington, DC Tampa, FL Heather BuckmanOctober 22–26, 2012 Editor in Chief August 21–23, 2012Tampa, FL Boston, MA Heather Shanholtzer San Jose, CANovember 12–16, 2012 EditorialSan Francisco, CA August 28–30, 2012 Charlotte, NC Managing Technical EditorAgile Software Development Training Lee CopelandJune 10–12, 2012 September 11–13, 2012Las Vegas, NV Minneapolis, MN Online Editors Santa Fe, NM Joseph McAllister Jonathan Vanian September 17–19, 2012 Washington, DC Community Manager David DeWald Production Coordinator Cheryl M. Burkeconferences Design Creative DirectorBetter Software Conference West Better Software Conference East Catherine J. Clingerwww.sqe.com/BetterSoftwareWest www.sqe.com/BetterSoftwareEastJune 10–15, 2012 November 4–9, 2012 AdvertisingCaesars Palace Rosen Shingle CreekLas Vegas, NV Orlando, FL Sales Consultants Daryll PaivaAgile Development Conference West Agile Development Conference Eastwww.sqe.com/AgileDevelopmentWest www.sqe.com/AgileDevelopmentEast Kim TrottJune 10–15, 2012 November 4–9, 2012 Production CoordinatorCaesars Palace Rosen Shingle CreekLas Vegas, NV Orlando, FL Desiree KhouriSTARWEST 2012 STAREAST 2013www.sqe.com/starwest www.sqe.com/stareastSeptember 30–October 5, 2012 April 28–May 3, 2013Disneyland Hotel Rosen Shingle Creek CONTACT USAnaheim, CA Orlando, FL Editors: editors@bettersoftware.com Subscriber Services: info@bettersoftware.com Phone: 904.278.0524, 888.268.8770 Fax: 904.278.4380 Address: Better Software magazine Software Quality Engineering, Inc. 340 Corporate Way, Suite 300 Orange Park, FL 320734 BETTER SOFTWARE MAY/JUNE 2012 www.TechWell.com
  8. 8. Level up your productivity – Upgrade to Hansoft Simplifying program management and day today lean, agile and Gantt scheduling development. 27, at y our booth # ence Come b tware Confer of Better S Download a free 2-user trial at www.hansoft.se
  9. 9. Test StudioEasily record automated tests foryour modern HTML5 appsTest the reliability of your rich, interactive JavaScript apps with just a fewclicks. Benefit from built-in translators for the new HTML5 controls, cross-browser support, JavaScript event handling, and codeless test automationof multimedia elements.www.telerik.com/html5-testing
  10. 10. ContributorsJason Arbon is currently engineering director at uTest.com, focusing on mobile and analytics. Jason has held test leadership andinnovation roles at Google—on Google+, Chrome Browser, Chrome OS, Google Desktop, and Google Talk. He also worked onteams at Microsoft, including Bing (Search relevance and QnA), WinFS, BizTalk Server, MSN, Windows CE, and Exchange Server.Jason is the coauthor (with James Whittaker) of How Google Tests Software.Steve Berczuk is an engineer and ScrumMaster at Humedica, where hes helping to build next-generation SaaS-based clinicalinformatics applications. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration,Steve is a recognized expert in software configuration management and agile software development. He is passionate abouthelping teams work effectively to produce quality software. Contact Steve at steve@berczuk.com, visit berczuk.com, and followhis blog at steveberczuk.blogspot.com.With more than thirty years of experience, Lee Copeland has worked as a programmer, development director, process improvementleader, and consultant. Based on his experience, Lee has developed and taught a number of training courses and is the managingtechnical editor for Better Software magazine, a regular columnist for StickyMinds.com, and the author of A Practitioners Guideto Software Test Design. Contact Lee at lcopeland@sqe.com.Janet Gregory specializes in helping teams build quality systems. As tester or coach, Janet has helped introduce agile develop-ment practices into companies and has successfully transitioned several traditional test teams into the agile world. She is afrequent speaker at agile and software testing conferences in North America, including the STAR testing conferences.Jonathan Kohl is an internationally recognized consultant and technical leader. Based in Calgary, Alberta, Canada, he is thefounder and principal software consultant of Kohl Concepts, Inc. Jonathan helps companies define and implement their ideasinto products, coaches practitioners as they develop software on teams, and works with leaders helping them define and imple-ment their strategic vision. He is also a popular author and speaker. Read more of Jonathan’s work at www.kohl.ca or contacthim at jonathan@kohl.ca.Yoram Mizrachi is a mobility veteran with a wealth of experience in mobile quality, networking, security, and telecommunications.Yoram founded Perfecto Mobile after serving as the CTO of Comverse Mobile Data Division. He was the CTO and founder ofExalink, which was later acquired by Comverse. Prior to founding Exalink, Yoram held several technology-related positions in thefields of communication and cryptography.Management consultant Johanna Rothman is a regular StickyMinds.com and Better Software magazine columnist. She is theauthor of Manage It! Your Guide to Modern Pragmatic Project Management—winner of the 2008 Jolt Productivity Award—aswell as coauthor of Behind Closed Doors and author of Hiring the Best Knowledge Workers, Techies & Nerds. Johanna is a hostof the Amplifying Your Effectiveness Conference and has presented at numerous conferences. You can reach her atjr@jrothman.com or by visiting www.jrothman.com.Founder and CEO of QA InfoTech, Mukesh Sharma leads the organizations worldwide operations, marketing, sales, and develop-ment efforts, and is responsible for the companys vision. He founded QA InfoTech with a vision to provide unbiased QA testingsolutions and has grown the organization to five Centers of Excellence, hundreds of employees, and more than $10 million inannual revenue. Mukesh can be reached at mukesh@qainfotech.net. www.TechWell.com BETTER SOFTWARE MAY/JUNE 2012 7
  11. 11. Editor’s Note Holding Pattern What do you do when you are stuck trying to decide the best course of action on a project that just went terribly wrong? Do you forge on, because you are the “some action is better than inaction” type, or do you step back, take a deep breath, and wait for a message from the project gods to guide your next move? There is no right answer. And there is no guarantee that one approach will yield the same results the next time. Lee Copeland’s Technically Speaking column, “Controlled Flight into Terrain,” has two examples of cases where entering into a holding pattern had drastically different outcomes. Your project crisis might not be as safety critical as the examples in Lee’s article, but the lesson is a valuable one that everyone can heed. Also in this issue, Jason Arbon continues to turn quality upside down in his article “Traditional Test Engineer- ing, Your Days Are Numbered.” Jason picks up where James Whittaker left off in the last issue and discusses the research and engineering required to turn the ideas in part one into new tools and processes. For the managers, Johanna Rothman sheds some light on “The Myth of 100% Utilization.” Think you have to keep team members completely occupied all day, every day to get your money’s worth? You might actually be hurting productivity. Steve Berczuk’s “Agile Code for Agile Teams” explains how agile code and technical practices can be lever- aged throughout the product lifecycle to keep your team agile. As always, I hope you enjoy this issue of Better Software magazine. Send me an email to let me know how you’ve put the ideas to work on your latest projects. Happy reading, hshanholtzer@sqe.com www.TechWell.com MAY/JUNE 2012 BETTER SOFTWARE 9
  12. 12. ig Ht PL an so ft wa re te st ing fL of lea rn ing , September 30– Ch oo se fro m a ful l we ek ne tw ork ing , an d mo re October 5, 2012 su nday sse s an d Mu lti -da y tr ain ing Cla Anaheim, CA Bo nu s se ssi on s be gin Disneyland Hotel Mo nday –t ue sday ful l-d ay 31 in- de pth ha lf- an d tu tor ial s ay we dn es day– tH ur sd 5 Ke yn ote s, 42 Co nc ur ren t tw ork ing RegisteR by August 3, 2012 se ssi on s, the eX Po , ne ev en ts, re cep tio ns , Bo nu s A N D s AV e u P t O $ 4 0 0 se ssi on s, an d mo re gROuPs Of 3 sAVe eVeN mORe! fr iday hip summit testing & Quality Leaders so ftw are wo rk sh op on re gu lat ed te sti ng (w re st )www.sqe.com/starwest
  13. 13. Technically SpeakingControlled Flight into TerrainEntering a holding pattern on a project sometimes buys you time to figurethings out. Other times, it buys you a crash landing.by Lee Copeland | lcopeland@sqe.comJust for fun, I often browse the shelves of the local university Denver, CO for Portland, OR with 189 persons on board. Ap-library looking for something that catches my eye. Recently, proaching Portland, the first officer, who was flying the air-an interesting book jumped off the shelf and into my hands craft, requested the wing flaps be extended to fifteen degrees(perhaps its bright pink and orange cover helped). Controlling and the landing gear lowered. The captain complied with bothPilot Error: Controlled Flight Into Terrain by Daryl Smith is requests. As the landing gear was lowered, both pilots heardabout poor decisions made by pilots under extreme pressure. a loud noise and felt a severe jolt. The aircraft yawed to the After reading “A controlled flight into terrain (CFIT) is an right. However, the “nose gear down” light was green. Theaccident in which an otherwise serviceable aircraft, under the crew put the plane into a holding pattern over the ocean, andcontrol of the crew, is flown unintentionally into terrain, ob- for the next twenty-three minutes, the flight crew discussedstacles, or water, with no prior awareness on the part of the and performed emergency and precautionary procedures to as-crew of the impending collision,” it occurred to me that if you sure that all landing gear were locked in the full down posi-substitute “serviceable project” for “serviceable aircraft,” you tion. The aircraft continued to circle within twenty miles of thehave a description of many software airport. Thirty-four minutes afterproject disasters. the “jolt,” the first officer asked the Consider this example: “We were “…if you substitute flight engineer, “How much fuel wepreparing for the approach at Belize got?” He responded, “Five thou-City. Small thunderstorms were in ‘serviceable project’ for sand [pounds].” The first officerthe area. There was no moon, no acknowledged his response. Mean-approach lighting system, and no ‘serviceable aircraft,’ you have while, the flight crew continued tovisual approach slope indicator due have discussions about the landingto an outage on the ground. There a description of many software gear. Four minutes later, the captainwere no surrounding lights and it asked how much fuel they wouldwas very dark. At 5 miles inbound project disasters.” have left after fifteen more minutesrain started falling heavily. We had of holding. The flight engineer re-the runway in sight … We were at 350 ft. Suddenly we were sponded, “Not enough, fifteen minutes is gonna really run usat 240 ft. We saw that we were low and both the captain and I low on fuel here.”pushed the power up to max. As the aircraft accelerated we felt Sixteen minutes later, the first officer told the captain,an impact and a loud thump. The lighting was so poor at Belize “We’re going to lose an engine.” The captain replied, “Why?”that we decided not to make another approach so we diverted The first officer replied, “Fuel.” The captain repeated his ques-to Merida. Immediately after our landing and parking at the tion, and the first officer repeated his answer. Finally, sixty-onegate, we conducted a post-flight inspection. We saw a leading minutes after the indication of a potential problem, the first of-edge wing slat dented from a tree strike and tree branches stuck ficer called Portland Tower, “United 173 heavy, Mayday. We’rein the landing gear.” … the engines are flaming out. We’re going down. We’re not These pilots felt strong pressures to land: the importance of going to be able to make the airport.” The plane ran out of fueldoing their job, meeting their commitments, and not seeming and crashed, killing ten and injuring twenty-four people.to be incompetent. However, when the situation deteriorated, While entering a holding pattern can allow us to gatherthey had another option—they could have entered a holding additional project information, we must remember that wepattern. Often just waiting a few minutes can allow uncertain- cannot hold forever. Holding consumes valuable resources.ties to clear. Sometimes we need to do that with our projects— When dealing with a problem, don’t allow your attention towait for a while until additional information becomes avail- be so channeled that it pushes other concerns aside. In this ex-able. Generally, executing “the plan” is not more important ample, at no time did any of the crew translate “pounds of fuelthan your organization’s success. You can always do a mental remaining” into “minutes of flying remaining.” Make someonecost-benefit analysis. What’s the cost if you wait? What’s the responsible to call out the project’s vital signs. Remember, youbenefit of pressing on? What’s the cost if you fail? have the ethical responsibility to speak up. Vague hints about Here’s another example, this one with tragic consequences. project status don’t always get the job done. Your job is to keepOn December 28, 1978, United Airlines flight 173 departed the main thing the main thing. {end} www.TechWell.com MAY/JUNE 2012 BETTER SOFTWARE 11
  14. 14. rEchargE your TEam and ElEcTrify your car B OM IN C E Training WeeK The more training you take N the greater the savings! A D SAV E Maximize the impact of your training by combining courses in the same location. Combine a full week of training for the largest discount! 2012 September 17–21, 2012 fall schEdulE Washington, DC October 22–26, 2012 Tampa, FL TESTING TraINING November 12–16, 2012 wEEkS San Francisco, CAWashingTon, D.c. Training WeeK Indicates coursesseptember 17–21, 2012 pre-approved for PMI PDUs MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY Software Tester Certification—Foundation Level Mastering Test Design Test Estimation and Just-In-Time Software Agile Testing Practices Testing Under Pressure Measurement Testing Workshop Risk-Driven Software Testing Testing with Use Cases Performance, Load, and Stress Testing Workshop Essential Test Management and Planning Leadership for Test Managers Test Process Improvement Mobile Application Testingways to save Take advantage of the different “Ways to Save” on training using our discount programs listed below. Purchase valuable software quality training for your whole team and save. B B OM IN OM IN Early C C E E Training WeeK conference Bird N N A A D SAV D SAV E ERegister 6 weeks prior Combine specialized Have a group and want Bring any course Save $300 when you for any training week training courses in to save more? Get to your location for combine any our our course and receive the same location details on our discount team training. On-site pre-conference training$50 off per registered and save. Discounts policy by contacting our training is both courses with yourcourse day. Take a full vary depending on the Client Support Group. cost-effective and conference registration. week of training and amount of training days convenient for your save $250! combined. team of six or more. See page 6 for more details.For more details on our discount policy, contact the Client Support Group at sqeinfo@sqe.com or call 888.268.8770 or 904.278.0524. 12 BETTER SOFTWARE MAY/JUNE 2012 www.TechWell.com
  15. 15. rEEr WiTh TEsTing Training from sQE Training TamPa Training WeeK Indicates courses october 22–26, 2012 pre-approved for PMI PDUs MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY Software Tester Certification—Foundation Level Mastering Test Design Test Estimation and Just-In-Time Software Agile Testing Practices Testing Under Pressure Measurement Testing Workshop Systematic Software Testing Performance, Load, and Stress Testing Workshop Essential Test Management and Planning Leadership for Test Managers Mobile Application Testing Test Process Improvement san francisco Training WeeK Indicates courses november 12–16, 2012 pre-approved for PMI PDUs MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY Software Tester Certification—Foundation Level Mastering Test Design Test Estimation and Just-In-Time Software Agile Testing Practices Testing Under Pressure Measurement Testing Workshop Risk-Driven Software Testing Testing with Use Cases Performance, Load, and Stress Testing Workshop Essential Test Management and Planning Leadership for Test Managers Mobile Application Testing Finding Ambiguities in Writing Testable Requirements Requirements-Based Testing Requirements LEarNING OpTIONS: Public eLearning Instructor-led training in Live, instructor-led Self-paced Instructor-led training a city near you classes via your computer learning, online at your location for information on our 60+ Public and 40+ Live Virtual course Dates visit www.sqetraining.com SQE TRAINING www.TechWell.com MAY/JUNE 2012 BETTER SOFTWARE 13
  16. 16. Management Chronicles The Myth of 100% Utilization The problem with the myth of 100% utilization is that it often leads to a less successful organization. by Johanna Rothman | jr@jrothman.com A manager took me aside at a recent engagement. “You know, committed on another project. You can’t get together for a Johanna, there’s something I just don’t understand about this meeting. You can’t have a phone call. You can’t even respond agile thing. It sure doesn’t look like everyone is being used at to email in a reasonable time. Why? Because you’re late re- 100 percent.” sponding to the other interrupts. “And what if they aren’t being used at 100 percent? Is that a problem for you?” How Did We Get Here? “Heck, yes. I’m paying their “Because we are human, we are Back in the early days of com- salaries! I want to know I’m getting puting, machines were orders of their full value for what I’m paying them!” unable to perfectly write out magnitude more expensive than1. In grammers, as shown in figure pro- “What if I told you you were the 1970s, when I started working probably getting more value than what’s in our memory, and we as a developer, companies could pay what you were paying, maybe one highly experienced programmers and a half to twice as much? Would imperfectly swap back in.” about $50,000 per year. You could you be happy with that?” pay those of us just out of school The manager calmed down, then turned to me and said, less than $15,000 per year, and we thought we were making “How do you know?” huge sums of money. In contrast, companies either rented ma- I smiled, and said, “That’s a different conversation.” chines for many multiples of tens of thousands of dollars per Too many managers believe in the myth of 100 percent utili- year or bought them for millions. You can see that the scales of zation. That’s the belief that every single technical person must salaries to machine cost are not even close to equivalent. be fully utilized every single minute of every single day. The When computers were that expensive, we utilized every problem with this myth is that there is no time for innovation, second of machine time. We signed up for computer time. We no time for serendipitous thinking, no time for exploration. desk-checked our work. We held design reviews and code re- And, worse, there’s gridlock. With 100 percent utilization, views. We received minutes of computer time—yes, our jobs were the very people you need on one project are already partially often restricted to a minute of CPU time. If you wanted more time, you signed up for after-hours time, such as 2 a.m. to 4 a.m. Realize that computer time was not the only expensive part of computing. Memory was expensive. Back in these old days, we had 256 bytes of memory and programmed in as- sembly language code. We had one page of code. If you had a routine that was longer than one page, you branched at the end of a page to another page that had room that you had to swap in. (Yes, often by hand. And, no, I am not nostalgic for the old days at all!) In the late ‘70s and the ‘80s, minicomputers helped bring the money scales of pay and computer price closer. But it wasn’t until minicomputers really came down in price and PCs started to dominate the market that the price of a de- veloper became so much more expensive than the price of a computer. By then, many people thought it was cheaper for a developer to spend time one-on-one with the computer, not in design reviews or in code reviews, or discussing the architec- ture with others. In the ‘90s, even as the prices of computers, disks, and memory fell, and as programmers and testers became more Figure 1 expensive, it was clear to some of us that software develop- 14 BETTER SOFTWARE MAY/JUNE 2012 www.TechWell.com
  17. 17. Management Chroniclesment was more collaborative than just a developer one on Now, let me address the not-thinking part of 100 percentone with his computer. That’s why Watts Humphrey and the utilization. What if you want people to consider working inSoftware Engineering Institute gained such traction during a new way? If you have them working at 100 percent utili-the ‘90s. Not because people liked heavyweight processes, zation, will they? Not a chance. They can’t consider it; theybut because, especially with a serial lifecycle, you had to do have no time.something to make system development more successful. So you get people performing their jobs by rote, servicingAnd, many managers were stuck in 100 percent utilization their interrupts in the best way they know how, doing as littlethinking. Remember, it hadn’t been that long since 100 per- as possible, doing enough to get by. They are not thinking ofcent utilization meant something significant. ways to improve. They are not thinking ways to help others. Now, remember what it means when a computer is fully They are not thinking of ways to innovate. They are thinking,utilized and it’s a single-process machine: It can do only one “How the heck can I get out from under this mountain ofthing at a time. It can’t service any interrupts. It can’t respond work?” It’s horrible for them, for the product, and for ev-to any keystrokes. It can’t update its status. It can only keep eryone they encounter.processing until it’s done. When you ask people to work at 100 percent utilization, Now, if the program is well behaved, and is not I/O bound, you get much less work out of them than when you plan foror memory bound, or CPU bound, and is a single-user, single- them to perform roughly six hours of technical work a day.process machine, such as a personal calculator that only adds, People need time to read email, go to the occasional meeting,subtracts, multiplies, and divides, that’s probably fine. But as take bio breaks, have spirited discussions about the architec-soon as you add another user to the mix, or another process, ture or the coffee or something else. But if you plan for a goodyou are in trouble. (Or, if the program is not well behaved and chunk of work in the morning and a couple of good chunks ofdoes not finish properly, you are in trouble.) work in the afternoon and keep the meetings to a minimum, And that’s what we have with modern computers. Modern technical people have done their fair share of work.computers are multi-process machines. If you work in a meeting-happy organization, you can’t With multi-process machines, if a computer is fully utilized, plan on six hours of technical work; you have to plan on less.you have thrashing, and potential gridlock. Think of a highway You’re wasting people’s time with meetings.at rush hour with no one moving; that’s a highway at 100 per- But no matter what, if you plan on 100 percent utilization,cent utilization. We don’t want highways at 100 percent utiliza- you get much less done in the organization, you create a terribletion. We don’t want current computers at 100 percent utiliza- environment for work, and, you create an environment of notion either. If your computer gets to about 50 to 75 percent innovation. That doesn’t sound like a recipe for success does it?utilization, it feels slow. And, computers utilized at higher than85 percent have unpredictable performance. Their throughput Agile and Lean Make the Mythis unpredictable, and you can’t tell what’s going to happen. Transparent Unfortunately, that’s precisely the same problem for people. Agile and lean don’t make 100 percent utilization go away; they make the myth transparent. By making sure that all theWhy 100% Utilization Doesn’t Work for work goes into a backlog, they help management and thePeople teams see what everyone is supposed to be working on and Now, think of a human being. When we are at 100 percent how impossible that is. That’s the good news.utilization, we have no slack time at all. We run from one task Once everyone can visualize the work, you can decideor interrupt to another, not thinking. There are at least two what to do about it. Maybe some of the work is really part ofthings wrong with this picture: the inevitable multitasking a roadmap, not part of this iteration’s work. Maybe some ofand the not thinking. the work is part of another project that should be postponed We don’t actually multitask at all; we fast-switch. And we for another iteration. That’s great—that’s managing theare not like computers that, when they switch, write a perfect project portfolio. Maybe some of the work should be donecopy of what’s in memory to disk and are able to read that by someone, but not by this team. That’s great—that’s an im-back in again when it’s time to swap that back in. Because pediment that a manager of some stripe needs to manage.we are human, we are unable to perfectly write out what’s No matter what you do, you can’t do anything until youin our memory, and we imperfectly swap back in. So, there see the work. As long as you visualize the work in its entirety,is a context switch cost in the swapping, because we have to you can manage it.remember what we were thinking of when we swapped out. Remember, no one can do anything if you are 100 percentAnd that takes time. utilized. If you want to provide full value for your organiza- So, there is a context switch in the time it takes us to swap out tion, you need to be “utilized” at about 50 to 60 percent. Be-and swap back in. All of that time and imperfection adds up. And, cause a mind, any mind, is a terrible thing to waste. {end}because we are human, we do not perfectly allocate our time firstto one task and then to another. If we have three tasks, we don’t This article originally appeared on TechWell.com.allocate 33 percent to each; we spend as much time as we please Visit http://well.tc/Myth14-3 to post comments and questionson each—assuming we are spending 33 percent on each. for Johanna. www.TechWell.com MAY/JUNE 2012 BETTER SOFTWARE 15
  18. 18. Author recommended books, blogs, gadgets, websites, and other tools for building better software What "tools" do you use to help you overcome a slump during your workday? When I need a quick reset during the workday, I often head for coffee with a friend at work. Starbucks is good, but the dark chocolate mocha at Tullys in the Bing.com building next door usually does the trick. –Jason Arbon I take a coffee break with my friends or play ping pong When I find myself in a slump, I usually play a or foosball with office colleagues. It rejuvenates and game of some kind on my computer or phone. helps me in bonding with employees, resulting in a I like the pattern-matching type of games— happy work environment. Bejeweled or Mahjong. Sometimes, I play timed –Mukesh Sharma versions, which wake up my brain. Even picking up my Sudoku book will trigger my brain functions in a different way. –Janet Gregory SCM Getting out of the office and taking a walk is one of the best ways for me to break out of whatever thinking pattern was getting me stuck www.accurev.com | info@accurev.com and come up with new ideas. Often, I get the best ideas when Im not thinking of the problem at hand. And while I find listening to music or podcasts sometimes helps me think when in the office, my slump-clearing walks are best done without any background, save for whats in the neighborhood. And, if nothing else, Im getting some exercise! –Steve Berczuk S OFTWARE C ONFIGURATION Slow preparation of strong M ANAGEMENT FOR cappuccino is my preference Agile, Waterfall, & Everything in Between for staying awake. Beside the "coffee injection," this also allows me to spend some time with my Top 5 Software Development colleagues and stay up to date Process Challenges with many daily issues. Download White Paper: www.accurev.com/top512 –Yoram Mizrachi16 BETTER SOFTWARE MAY/JUNE 2012 www.TechWell.com
  19. 19. From One Expert to AnotherPaul Poutanen Since the SMS market isYears in Industry: 17 international and complex, I’m notEmail: paul@mob4hire.com aware of any formal governance around this system. If you are aInterviewed by: Jonathan Kohl company depending on SMS in various companies, you may beEmail: jonathan@kohl.ca It is incredibly difficult to try to getting different SMS products replicate what is out there in the when you purchase the same world without enormous cost. package from a broker next time. An SMS service provider has to purchase messages from different SMS testing depends on testing brokers in different countries. a lot of platforms (a combination of a handset, carrier, and SMS is considered ubiquitous Every device that is used for country). Testing only within your in the mobile space, and the only platform testing is controlled by a organization won’t tell you much, standard digital app that can be human. If something goes wrong, unless you have offices in many found on any device. It is also they can troubleshoot and bring locations where your services extremely popular: According their own devices back online. need to be used. to Wikipedia, approximately 2.4 billion handset users use SMS. When we test messages, we confirm that SMS messages make it to a particular country and Bringing hybrid carrier by utilizing testers who use that carrier in that country. The test is simple. It’s binary. It’s a development and pass or fail. Did the SMS make it or not? deployment to This process of getting an SMS the enterprise. to the end handset is dynamic. SMS aggregators may change hybrid cloud their routes every day, meaning a message that was successful public cloud private cloud when sent in the morning may not work in the afternoon. CollabNet has built the first front end platform to lead the industry shift to hybrid cloud development and deployment. Learn 5 Steps your how an Enterprise Cloud Development The way it works is not simple, especially when Dev Team solution can enable: looking at international SMS routing. There are should know • 80% cost efficiencies over 1,000 carriers and network operators in the • 70% faster to market world. • Compliance and visibility Manage Hybrid Cloud Champion DevOps Codify Dev Processes Value Download the free white paper: Implement Community Architecture Embrace Cloud www.collab.net/ecd Enterprise Cloud Development Maturity For the full interview, visit W W W.COLLAB.NET | +1 650-228-2500 | 888-778-9793 http://well.tc/FOETA14-3 www.TechWell.com MAY/JUNE 2012 BETTER SOFTWARE 17
  20. 20. ISTOCKPHOTO 18 BETTER SOFTWARE MAY/JUNE 2012 www.TechWell.com
  21. 21. O ur brave new world of agile, mobile, and continuous StickyNotes for keys to deciding whether a test should be au- engineering is leaving traditional test engineering in tomated or manual in an agile world. In a continuous engi- the dust. As test engineers, we need to rethink the neering environment, it is even more difficult to decide when entire approach to software quality and engineer and where to automate your testing. Automation used to beour way back into today’s world. Our users and customers done during “breathers” in between ship cycles or deliber-are already suffering because we haven’t adapted. ately aligned with engineering work in a waterfall schedule. Part one of this article (March/April 2012) discussed how In today’s world, developers and testers alike need to be verymany test teams have responded to the time pressure of agile frugal and decisive about when and where to add tests.by shifting their focus to early cycle unit and “small” tests,which are faster or more easily automated. In this shift to Test Plansagile, late cycle or manual testing efforts are often dropped The days of the test plan are numbered. Agile and quickor, worse, the program management and development teams engineering cycles often mean a lot less product planning—theembrace agile and continuous practices, but the old world re- same should happen for testing. In fact, every minute spentgression test cycle is left hanging around like an archaic ritual planning testing activities is time not spent testing a productthat adds a few days or weeks to an engineering process that that is continually going out the door. Testers should drop thewants to be continuous. comfortable and slow process of documentation around test Agile and continuous testing offer the ability to maintain plans. What should guide testing isn’t the completion of a listquality standards in the face of continuous deployments. of tests written a month or more ago. The tests likely passedWithout continuous testing, defects slip into the released bi- the last time you ran them, and they likely will pass again.naries and are often caught by end-users. The emerging mo- What matters is testing the most dangerous and risky part ofbile, web, and desktop application markets that host your the product at any given time. Test that until something elseapps amplify the visibility of these faults. The markets are worries the team more. New features are often more risky,forums for comments on quality that can deter potential new but it is more likely there is still risk debt hidden in an olderusers with reviews pointing to crashes, performance, usability, feature. Agile testing usually focuses only on the latest fea-and functional issues and are very visible to other users and tures and only until the next iteration with its new featuresyour own engineering team. Every continuous build must be and changes. Continually updated heatmaps are a quick andmatched with continuous testing or the product risks poor easy way to track risk, help focus testing energy, and avoidmarket comments and ratings, which affect user perception, the documentation process of traditional test plans.downloads, and even the morale of your engineering team. Attributes-components-capabilities (ACC) is the process ofAgile and continuous testing are critical to maintain quality breaking down the project into a grid of the attributes thatin today’s world of agile, mobile, and continual engineering. the team and the customers would like the product to have The test engineering recommendations that follow as- and the software components that are important, and thensume that the development team is well on its way to best listing the product capabilities (features) that lie at the inter-agile practices, such as strong Unit+ test coverage and con- action of goals and implementation. Now, assign a risk valuetinuous builds and deployment, and that the development to each square. Testing should always be focused on the mostteam assumes accountability for quality. Unit+ tests are a dangerous, “red” areas.strong set of unit tests with multi-component and interface The ACC process can be done in a spreadsheet, on avalidation automation in addition to standard unit testing napkin, or with a web tool that does coloration automagi-scope. Without these, the team cannot be agile with respect to cally. The key is that it can be done in less than thirty min-quality and backlogs of work. If the developers are not adding utes and can be updated in minutes with each new feature orunit tests with every check in, it is an incredibly expensive and product change.slow way to develop products. Most important is the notionthat developers are accountable for quality. Many avoid this Regression Testingresponsibility, but if they take on that role, they will add the The days of the regression test pass are numbered. Testunit test coverage, avoid buggy code, and ensure testability continually. Drop the lists of hundreds or thousands ofis designed into the product. (For details, see the book How canned test cases that usually pass anyway. Instead, performGoogle Tests Software. [1]) Assuming the development team exploratory testing driven by the risk matrix. Produce dif-is on its way toward this model, let’s look at how late cycle ferent builds for different levels of risk tolerance and “baketesting must adapt. time.” Build the infrastructure to automatically and immedi- Take a closer look at the bugs reported for your favorite ately deploy the latest builds to the developers. The Androidapp in the iTunes store or in Google Play marketplace. How test team does this: If developers produce a bad build, it’smany users complain about failed unit tests? Not many. They likely that the call they make on the way home will fail. Thiseither don’t care or the small tests are doing their job. Users means the developers are more likely to check in good codecomplain about basic issues of installing on their particular with some testing. After a few days of baking with the en-device, crashes or hangs while using the app, performance, gineering team, share these builds with ever-larger and less-pricing, usability, or design. Small, automated tests don’t risk-tolerant customers. If you don’t have friends or a betacatch these things; test engineers and early users do. See the community, you can leverage the growing communities of www.TechWell.com MAY/JUNE 2012 BETTER SOFTWARE 19
  22. 22. crowd testers for a dollar or two. When a build comes out at items are not truly agile, they often are just too nervous tomidnight or on a Friday evening, don’t let the build sit around defer judgment to the individual teams or they lack the mod-untested. Deploy it to the team and send it out to the crowd— ular code, tests, and deployment features to move into thethey actually have more capacity on weekends and evenings agile world. More often than not, these hierarchal teams areto find and report bugs. Given the importance of deployment missing out on the benefits of agile.in an agile world, if the application or infrastructure doesn’thave a quick way to deploy, roll back, and monitor these dif- Test Case Databasesferent builds, test and quality engineers should build it before The days of test case databases are numbered. Much likeadding any tests. bugs and work item databases, they are a sign of non-agile practices in an agile world. If testing is based on risk anal-Textual Bug Filing and Triage ysis and is dependent on what new features are added to the The days of bug filing and manually determining priority project this day or this week, the team will know what andare numbered. The time it takes to manually enter into a text where to test. Having a small, vague list of exploratory tactics,form the exact details of the system state, actual results, and such as a set of exploratory testing tours, can be handy, butexpected results hasn’t changed in a decade. How long does it these lists are small and don’t require a full-blown database.take humans to read, understand, and judge the severity of an Even spreadsheets are good enough for the testing of manyissue from text? The better bugs have pictures attached, but of Google’s web apps, as they let many folks log pass/fail inthis is an extra step that still doesn’t tell us anything about the the cells next to simple “areas for testing.” As for queries onactual state of the application. Bug filing and feedback from the test cases, test case counts mean nothing to the customer;users are moving to a point-and-click exercise, where text is they are the least valuable of all project metrics. In my time atoptional and software automatically gathers most of the rel- Google, I witnessed the dismantling of two test case databaseevant application state, images, and videos and even knows efforts. Smart test engineers always want to build them, butwhat test case is executing. Some even generate replay scripts agile teams just don’t use them. If the team really needs toso the reproduction steps can be played back on the developer’s plot the history of pass/fails for a product, the team by defini-machine. These also render the known bugs in context—no tion isn’t in an agile environment, and the team is living in themore crafting a query outside of the application under test and past. Keep the trees green, tests passing, and the bugs fixed.hoping the testers use the same words the other bug filer used.Show bug data in context within the application and make it Release Managementpoint-and-click easy to see existing bugs and file new ones. The days of release managers are numbered. The pro- gram management and technical leads on the project shouldBug and Work Item Backlogs continually assess the quality of the product (with risk input The days of large bug and work item databases are num- from the test engineers). They are accountable for quality. Thebered. A key to being agile is keeping the number of bugs and builds should always go out, but features should be easilywork items to a minimum. When it comes to tracking bugs disabled until they are ready for prime time. Facebook engi-or requested feature work, a valid agile response is “Don’t.” neering follows this basic practice, as do many web and clientReally. Jason Fried of 37signals.com said it best in his book projects at Google. It is OK to have code in the product thatRework: “There is no need for a spreadsheet, database, or isn’t yet ready; the only question is when it will be turned onfiling system. The requests that really matter are the ones you for users to see. If the product doesn’t have these mechanics,will hear over and over again … your customers will be your engineer them into the product to support agile practices andmemory … If there is a request that you keep forgetting, that’s continual deployment.a sign that it isn’t very important. The really important stuffdoesn’t go away.” [2] Team Structure Fix bugs as soon as the team sees them. Any amount of The days of large, dedicated, onsite test teams are num-bug debt is a drag on morale and speed, and it enables de- bered. Welcome users and the crowd into the engineeringvelopers to do the wrong thing, which is add more code. If process. Today, most teams dedicate headcount to onsite testthere are bad bugs in the code, the team shouldn’t release engineers. These engineers are there regardless of whether andthe builds. If a bug is “difficult,” team members shouldn’t when they are needed. These engineers get bored and losedefer it. They should investigate and debug, not add new fea- their objectivity seeing the same product day in and day out—tures. Customer and feature requests shouldn’t be added to a they can only truly represent a first-time user once! They alsobacklog, either. place a cap on testing bandwidth and throughput, as there If the team needs a database to hold and support complex are only so many of them. Many smaller companies now reapbug queries on lists or work items, the team is likely only the benefits of having a virtual, crowdsourced testing team.feigning agile engineering processes. Agile teams are moving Much like VMWare and Amazon virtualized our test lab ma-toward smaller, single-page punch lists of work items for the chines, the virtualization of our test teams is happening withentire team, either on a whiteboard or in a simple shared doc- very similar benefits. While working on Google Chrome, weument with bullets. Large engineering teams that have created passed the same manual test cases we once passed to our five-hierarchal scrum review meetings to review bugs and work person, dedicated manual test team to a virtualized testing20 BETTER SOFTWARE MAY/JUNE 2012 www.TechWell.com
  23. 23. team at uTest.com. This virtual test team enabled us to ex- the incoming bugs. Onsite testers or PMs integrate the bugecute tests more quickly as we could spin up ten, twenty, or data from crowd testers with the rest of the engineering teammore testers when we needed a test pass to complete quickly. during standups. Virtual test teams are here.And we could spin them back down when we didn’t need Some say test engineering’s days are numbered—but really,testing. This virtualization of the testing team also proved it’s many of our rusty tools whose days are numbered. Thisless expensive than dedicated resources for the same task. A leap takes a little bit of risk, an engineering mindset, and will-side benefit was that they found bugs that our onsite testers in ingness to trust early adopters and the crowd with our bits.the lab just couldn’t find, because their machine state was “in Not every option above is a perfect fit for every situation, butthe wild,” with user accounts on various sites across the web, the closer your team can get to these best practices, the moredifferent perspectives of quality, and fresh eyes. Just as with your team, product, and customer will reap the benefits ofAmazon web services, the management of these virtual test agile and continual engineering. If we don’t engineer late cycleresources was simply done via web page. testing value into our agile tools and processes, our products Crowdsourcing is becoming more sophisticated than onsite and customers will suffer from products that pass every unittest management. Crowd testers are rated on every bug, every test but fail for the user. {end}project, and every test case by the engineering team. They areeven rated based on fit for different types of testing. These jarbon@gmail.comcrowd testers can be “pinned” to the project so they are likevirtual team members or cycled out at will to get new perspec-tives and machine contexts and experience. Most importantly, For more on the following topics go tothese testers are closer to the real users and can test on real- www.StickyMinds.com/bettersoftware.world machines, account states, and from mobile locations. n ReferencesThe number of dedicated onsite testers should be kept small. n Automated or manual testing?They shouldn’t be testing; they should be managing the crowdfor any regression and exploratory testing. Some startupshave no on-site testers, simply a program manager (PM) whodirects the crowd testers at companies such as uTest.com.These PMs often spend only an hour a day communicatingthe latest changes in the continuous builds and reviewing 3 www.TechWell.com MAY/JUNE 2012 BETTER SOFTWARE 21
  24. 24. ISTOCKPHOTO 22 BETTER SOFTWARE MAY/JUNE 2012 www.TechWell.com
  25. 25. T here are two closely related aspects to a team’s being agile: 1) planning or project management, and 2) execution or engineering practices. When people think about agile projects, the focus is often either on the planning and project management process or the engi- neering practices. It’s important to understand that both aspects work together. This article discusses how the way you execute your engi- neering practices can help your agile process be effective. Agile Basics Agile methods acknowledge uncertainty and manage it with techniques that rely on transparency, inspection, and adaptation, with an emphasis on working software. Agile projects allow teams to adjust goals in response to technical issues or changes in current needs or future technical or market forces. Some agile methods, such as XP, focus on technical practices. Others, such as Scrum, focus on project management practices. Both planning and execution are nec- essary for an agile approach to work. Good planning makes it easier to execute in an agile way. Agile plans can only be effective if the team follows good engineering prac- tices that give you the feedback that you need to inspect and evaluate and a codebase that will allow you to adapt. To understand how engineering practices can drive improvements in the agility of your team, you need to understand the cultural challenges of being agile, and some basics of agile planning. Cultural Challenges Agile is about incremental progress and continuous improvement. To become a better agile team, you need to acknowledge uncertainty and the possibility of failure. In many teams, this is hard to do. Getting good feedback requires changes in how you define requirements, develop features, and interact with others in your organization. Defining requirements with precise-enough definition to show whether you have met the goal, while also maintaining enough simplicity that you can move from speci- fication to development quickly, can be challenging. Developing, maintaining working code, and coding and designing in a way that allows for incremental development and continual feedback require new approaches and skills. Change, learning, and ac- cepting and giving feedback are often difficult. Agile Planning “Agile planning” means enough planning to move forward and measure progress. Agile requirements are focused on delivering functionality to users and start with three things: • A user, who has a business need • A feature, which is what the system will do • A goal, which is reason the user wants to do the task While many teams can develop lists of features, the user and end-goal parts of the story are often missing. The user and his goal are the most difficult parts to express but also the most important. Having a clear statement of a goal allows you to decide what implementation will satisfy the core need and to evaluate whether the story is even necessary to implement. Since implementing features that do not have a clear use is wasteful, removing items from the backlog can be a major efficiency gain for a team. Tracking and Defining Done Tracking progress on a frequent basis is an important way to identify problems. Agile teams measure progress by continually re-evaluating the amount of work re- maining, rather than effort spent or “percent complete.” Even when the product owner has a clear vision, teams often struggle with defining what needs to be built in a way that can be evaluated. Tests pass or fail, and builds are successful or not, but it’s more difficult to determine if the test is testing the right www.TechWell.com MAY/JUNE 2012 BETTER SOFTWARE 23
  26. 26. thing. Deciding whether a team has completed a story may al- isn’t useful and stakeholders cannot provide useful feedbackways have a subjective element, but you can make it easier if on it until it can run on the target environment. Also, to beyou have a good sense of what “done” means. “done,” you need to address differences between a develop- With an agile approach, some degree of consensus on how ment system and a production-like one. There are two stepsto evaluate completeness is critical. Without a good under- to building code in a way that supports an agile approach:standing of what a complete story is, the team cannot estimate developing in vertical slices and deploying early and often to aaccurately and, thus, cannot set expectations. Not being able target environment.to set expectations can cause a breakdown in trust between The vertical slices approach is to develop end-to-end fea-the team and the product owner. Without trust, it’s harder for tures, from the user interface (UI) through whatever backendmanagement to accept the idea of self-organizing teams, thus systems are involved. Rather than focusing on the data modelnegating the efficiency benefits this approach provides. or the UI or application tier, building end-to end (though less Quite often, even the product owner is unclear about what rich) solutions has advantages. Users can see the applicationto ask for. In these cases, it’s best to make decisions and ac- do something. A “data model,” while important, is not easyknowledge that you may be wrong rather than work with to demonstrate. The team can validate the interactions be-difficult-to-evaluate stories. tween layers and make changes to make work at other layers The developers on an agile project can contribute to easier, thus minimizing unnecessary rework. UI implementa-project success in the face of uncertainty by working towards tion can be influenced by decisions made at the data layer,maintaining agile code. for example, and vice versa. The team and product owners can understand what features are truly necessary and have aAgile Code better sense of what to defer if something is late. Understanding the needs of the agile planning process, Make your application available on a target system earlywe can now talk about how engineering practices meet the and verify the deployment and installation process often. Thisneeds of agile methods and drive them when they are lacking. will give you an early opportunity to identify decisions thatRegardless of the agility of your product backlog, to be an will simplify the deployment and configuration process.agile team you need agile code. Agile code is code that youcan change while still being able to deliver working software The Agile Teamon a regular basis. To be able to implement in vertical slices and be efficient, Agile code can be maintained by a combination of good agile teams are often composed of generalizing specialists.design and having practices in place that provide constant Generalizing specialists can work on multiple aspects of thefeedback on the state of your code so that you can detect system, though they have expertise in a particular area. Thisproblems as soon as they occur. These practices include: means that all work that touches the UI is not blocked if your • Automated unit and integration tests in combination UI developer is overly busy. It also allows a first-pass, end-to- with continuous integration, to provide immediate end implementation by a single developer. As a generalizing feedback on the effects of a change to the code specialist, you are not abandoning the idea that there are no • Refactoring and continually improving the structure of “experts,” but you are encouraging team members to learn code while maintaining functionality about and work with other aspects of the code. Having such • Frequent deployments to a production-like environ- a cross-functional team not only reduces bottlenecks in the ment to identify issues before they can cause a last- development process but can also improve code quality by minute emergency and to make the application visible increasing the number of people who work with—and thus to stakeholders implicitly review—code. By maintaining code in a working state and in a statewhere it is easier to change, you make it possible for the team Agile Code at the Centerto implement changes to a product backlog that a product To be successful at agile, you need to consider the en-owner might ask for. tire product lifecycle, from planning to execution. You also While technical practices such as refactoring, design, need to be very aware of the challenges that the differenceand testing are essential to a successful agile project, avoid in approach will present to teams that have a different initialhaving purely technical tasks on the product backlog. Rather, mindset. In many ways, implementing agile technical prac-consider how doing these tasks furthers the progress of the tices may present less resistance than planning practices, and,project. When working on backlog items, always consider ef- as long as your organization wants to be more agile, workingfort required to refactor, design, and so forth as part of the on the technical practices can help identify the other bottle-estimate, since delivering code that can sustain change is es- necks to agile. {end}sential to agile success. steve@berczuk.comDelivery and Deployment Working software is the measure of progress in an agile This article originally appeared on TechWell.com.project, but “working” means more than just “can demo” Visit http://well.tc/14-3AgileCode to post comments andor even “compiles and passes automated tests.” Software questions for Steve.24 BETTER SOFTWARE MAY/JUNE 2012 www.TechWell.com
  27. 27. ISTOCKPHOTO 26 BETTER SOFTWARE MAY/JUNE 2012 www.TechWell.com
  28. 28. H ere today, gone tomorrow” is probably the best way to characterize the pace of change in the mobile market. In fact, many of today’s popular handsets and tablets become outdated and irrelevant in a few months. The mobile market is extremely dynamic, un- predictable, and fragmented. The numerous operating systems and plethora of platform versions, networks, hardware, and form factors make it challenging to maintain application quality. The OS Challenge New devices contain the latest or near-latest OS versions, and they usually automatically upgrade to the newest available version. There are no guarantees that an application developed according to an older OS version will function properly with a new version; enterprises have no choice but to conform to this pace and continually develop and test version updates for their applications. For example, in January 2011, Android 2.2 OS version was leading approximately half of the Android mobile market. A few months later, Android 2.3.3 took its place. By March 2012, Android 2.3.3 had reached more than half of the Android mobile market and is projected to take over the market. This is one example of the many competing platforms available. For a better understanding of the market dynamics, this example should be multiplied by the number of available platforms in- cluding iOS, Android, BlackBerry, and Windows Phone. Figure 1 shows the usage growth rate of the top five worldwide mobile operating systems. You can see how the mobile market fluctuates with no defined leader or standards. Adapting the Software Development Cycle to Mobile Mobile application testing simply cannot be served by the traditional development and QA cycle. As stressed previously, the market is extremely dynamic and unpredictable. A tremendous number of customers will instantly adopt newly released mobile devices and OS versions and connect right away to applications and websites. Although an organization may not be prepared to introduce an updated application version, users expect nothing less than a flawless user experience. In the mobile market, the risk accumulated between product releases is much greater than in traditional software. This is because the market changes are much faster. For example, when devel- oping a traditional web application, such as online banking, the chances that the IE browser version will change within the six-month development cycle is unlikely. In mobile, the leading devices and OS versions are likely to change within this six-month timeframe. This leaves companies no choice but to accelerate the release cycle in order to limit risk exposure, as shown in figure 2. Figure 1: Top five worldwide smartphone vendors, 1Q 2012 (Source: IDC) www.TechWell.com MAY/JUNE 2012 BETTER SOFTWARE 27

×