« March 2010 »
S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31


Sunday, 21 February 2010
My wikispaces site will close at the end of February
Topic: General

My Wikispaces subscription will expire at the end of February, 2010, and I am planning to let it lapse. If you have any links or bookmarks to the site, at http://davenicolette.wikispaces.com/, please be aware the links will stop working when the subscription expires.

I have no complaints about the Wikispaces service. They do a fine job, and if you need a hosted wiki I would gladly recommend Wikispaces. They have very good availability, editing content is easy, the site is responsive, and pricing is reasonable.

Unfortunately, over the years I've accumulated content on multiple hosted sites and I have material scattered all over the place, including a good deal of obsolete and redundant content. I need to get it consolidated and organized for logistical and cost reasons.

Some of the material from my wikispaces site will appear online again eventually. In the meantime, please feel free to download anything you want from the wikispaces site while it is still available.


Posted by Dave Nicolette at 10:51 AM EST
Post Comment | Permalink
Monday, 15 February 2010
Merging the developer and tester roles, part 2
Topic: Continuous improvement

A few days ago, I wrote about the idea of merging the roles of developer and tester, and touched on some of the ways this could improve software delivery processes. That post considered resistance to the idea on the part of people who self-identify as testers. What about resistance on the part of people who self-identify as developers?

Naresh Jain posted an interesting tweet the other day that is relevant to this topic. It reads as follows:

Software developer means "person who writes code" while the English word developer implies EVERYTHING required to build something.

The well-known testing specialist Michael Bolton, in a response to a comment on his blog, recently wrote:

But when it's not universally practiced, practiced at varying levels of quality, and addressed towards discovering solutions rather than discovering problems, I don't see any reason to relax vigilance.

In context, "it" refers to test-driven development, or more generally, good software development practices that are not widely used at present. By "vigilance" he means vigilance in looking for the kinds of bugs developers really ought to be embarrassed to deliver to testers in the first place, but (strangely) aren't.

Personally, I've been quite astonished at some of the things developers have said to me with respect to testing and code quality in the past few years. In 2008, I spent a day visiting development teams and IT management at a fairly large company, as a sort of extended interview process pursuant to a coaching opportunity. I asked the developers how they ensured their code was sound before handing it off to the testing group. I expected they would say they did a bit of ad hoc manual testing, at least, before proudly showing their code to anyone else. They didn't. They found the question puzzling. They felt that it was the responsibility of the testing group to find bugs in their code. Quite honestly, I did not understand how they could be satisfied with that; how they could look themselves in the bathroom mirror every morning and feel that they were really professionals. I asked them, What do you do, then? Do you just compile the code and throw it over the wall? They found that question puzzling, too. They glanced at one another for moral support, and shrugged. And that is not the only example of this attitude that I've encountered over the years. I can't help but wonder, if a developer doesn't bother to make sure his/her code works, then what function does he/she serve in the organization?

If I were one to theorize on the basis of very little data (and I am, as it happens), I would theorize that this attitude is largely the result of two influences:

  1. Behavioral conditioning. Developers have produced crap for so many years, and testers have ferretted out trivial programming errors for so many years, that everyone assumes this is the way things must be. We have become so accustomed to the problem that we accept it as normal. We don't even see it as a "problem."
  2. The lure of the next challenge. Most developers enjoy figuring out a design that solves a problem. Once they've figured out how to solve a problem, following up to tie off all the loose ends just isn't as much fun. They want to move on to the next problem. It takes a certain amount of self-discipline to finish up all the little details of the current problem before moving on. If you have a handy excuse, like "it's the testing group's job to find my bugs for me," then it's easy to succumb to the lure of the next interesting problem.

 

For the very simplest of applications, it may be feasible to promote code directly from development to production. But what about software that runs in enterprise IT environments that have stringent non-functional requirements? What about embedded software that has to be tested with the hardware before the product can be mass produced? Depending on the domain and context, additional testing may be required in between development and production; testing that the development team may not be set up to perform. This is where testing specialists can add significant value. I think this will remain true even when (or if) my vision of development generalists becomes a reality.

For context, let's assume an enterprise IT organization with certain characteristics. This picture will be familiar to those who work in large IT shops. The organization has a SOA environment that provides an ESB for accessing shared technical assets, back-end legacy applications, and externally-hosted services. The SOA environment provides single sign-on support, most of the -ilities, and supports multiple classes of service with an appropriate charge-back structure for internal departments that use IT resources. Typically, business applications are based on Web technologies, even though they are internal applications. The technical infrastructure comprises different network subdomains with different security profiles. The internal webapps use the familiar MVC-based layered architecture and may be deployed in multiple subdomains on various configurations of real and virtual servers, depending on operational requirements.

For development, business application development teams work in a technical environment that is far different from the production environment. Let's assume the company uses Java and one of the popular Java-based webapp frameworks for these internal business apps. For development and basic testing purposes, people may deploy their code to a single instance of a container such as Jetty or Tomcat. This may be embedded in an IDE, such as Eclipse or JetBrains, or it may run in standalone mode on the developer's workstation and/or on a test server or continuous integration server. Nearly all the development and testing work in this environment uses a monolithic deployment of the application; that is, all architectural layers are deployed together under one instance of the server or container, and there is one instance of each layer.

In the production environment, different layers of the application may be deployed in different subdomains. For instance, the presentation layer may be deployed to the outer DMZ, the business layer to the inner DMZ, and the persistence layer also to the inner DMZ, where it interacts with the ESB and not directly with database systems or other back-end resources that may reside in the core subdomain. Presentation and business layer application components may not run under the same container, and neither may run under the containers used in the development environment. Client-side niceties such as Web 2.0 scripts actually live outside the corporate network perimeter altogether. The presentation layer code is subject to various mechanisms external to the application, such as single sign-on support, reverse proxies, load-balancing switches, or what-have-you. To support changing workloads, operations may redeploy portions of the application to more or fewer virtual server instances. To support availability, recoverability, and performance requirements, operations may move the application from one server cluster to another (and no application can depend on "owning" a server), add or remove hardware resources, and so forth. All the business applications publish events that feed logging, audit trail, chargeback, fraud detection, license management, and business intelligence facilities. None of this is directly testable in the development environment, and yet new or modified applications must not cause problems in the production environment.

That means there is another level of testing to be done in between development and deployment. This is where testing specialists can add the most value.

The purpose of this level of testing is not to "find bugs." The purpose is to gather information about the operational parameters of the software, to be used in capacity planning, workload balancing, hot failover site configuration, quality of service management, and other matters above and beyond the basic functionality of the application. To do this, testers must be given software that works; not software so full of trivial bugs that it won't even run.

Development teams have the professional responsibility to deliver code that meets all functional requirements and as many of the non-functional requirements as are feasible to test in the development environment. Testing teams have the right to expect the applications they receive already work. Otherwise, they cannot perform the level of testing they need to perform for the benefit of the enterprise.

Some developers choose not to "believe in" contemporary software engineering techniques that help us deliver working code with relatively little personal stress. That's fine. Everyone has the right to "believe in" whatever they please. As long as the developers deliver code that meets all functional requirements and as many of the non-functional requirements as possible, they are free to use any methods; even methods that make their own lives harder than necessary, if they insist. The only thing they are not free to do is to continue delivering crap, as in the previous century.

One of the most straightforward ways developers can learn to deliver working code effectively is to learn the skills of testing. Those of us who pursue a generalizing specialist path in our career development have found that there is a sort of mental "switch" to be flipped; we shift ourselves from development mode to testing mode. Thinking as developers, our goal is to ensure our code performs its intended functions and handles "normal" error conditions gracefully. Thinking as testers, our goal is to find the cracks in the wall; find the ways our code can be broken. This is something that requires awareness and practice, but is not such a great mental leap that it actually calls for two different individuals on the team, not to mention all the waste inherent in silos, hand-offs, WIP inventories, and back-flows between the two specialists. More than anything else, though, it requires us to accept our professional responsibility to deliver working code, and stop depending on testers to find our trivial programming errors for us. They have better things to do than that.


Posted by Dave Nicolette at 9:28 AM EST
Post Comment | View Comments (1) | Permalink
Friday, 12 February 2010
Toward fully-automated meetings
Topic: Fun

A February 12 article in New Scientist, Boring conversation? Let your computer listen for you, describes the state of the art in Automated Speech Recognition (ASR) software. According to the article,

IBM Research in Almaden, California, [...] has developed a system called Catchup, designed to summarise in almost real time what has been said at a business meeting so the latecomers can... well, catch up with what they missed. Catchup is able to identify the important words and phrases in an ASR transcript and edit out the unimportant ones.

This technology offers an exciting breakthrough for managing meetings in the workplace. Given software that can interpret speech, all that is missing is software that can generate speech, and we can achieve fully automated meetings that do not demand the attendance of any real people.

There used to be a word game, way back in the dark ages when people used paper, in which one composed business-speak sentences by choosing words randomly from several lists; verbs, adjectives, nouns. It would be straightforward to develop software that generates sentences from lists of words. Combined with Catchup, we could realize a system to carry on both sides of any conversation without human participation. This would enable employees to go about their work without having to attend any meetings. A company would be able to get at least three times the amount of work done without adding staff.

Consider these word lists, for example:

List 1 List 2 List 3 List 4 List 5 List 6
in the next quarter
in the next fiscal year
to maximize shareholder value
to reach our financial targets
unquestionably
generate
facilitate
productionize
leverage
quantify
innovate
superior
market-leading
innovative
customized
customer-focused
Byzantine
products
services
innovations
marketing
successes
breakthroughs
overtake
supercede
win
grow
achieve
results
marketshare
growth
profit
cashflow

From lists like these, software can assemble meaningful statements to contribute to the discussion:

Assemble: Random(List 1), ', we must', Random(List 2), Random(List 3), Random(List 4), 'to', Random(List 5), Random(List 3), Random(List 6).

Examples:
  1. To maximize shareholder value, we must facilitate customer-focused innovations to supercede market-leading growth.
  2. In the next quarter, we must generate superior breakthroughs to grow marketshare.
  3. To reach our financial targets, we must innovate innovative innovations to win results.

 

Then Catchup can pick out key words and phrases

Keyword 1: 'value', Keyword 2: 'customer-focused', Keyword 3: 'growth'

and feed them into another meeting attendee's avatar:

Assemble: Random(List 1), 'Clearly, we should', Random(List 2), Keyword(3), 'and', Random(List 2), Keyword(2), Random(List 4), 'to', Random(List 5), Keyword(1).

Examples:

  1. Clearly, we should productionize growth and generate customer-focused innovations to achieve value.
  2. Clearly, we should quantify marketshare and leverage breakthroughs to overtake quarter.
  3. Clearly, we should innovate innovations and innovate innovations to innovate innovations.

 

...and so on in the same vein. For the duration of the scheduled meeting, the avatars can engage in a frank discussion of critical issues facing the enterprise, such as this:

Frank: Unquestionably, we must leverage market-leading successes to overtake profit.
Francine:Clearly, we should quantify innovations and generate superior breakthroughs.
Francisco:I definitely agree that we must facilitate customized services to win growth.
Francesca:Certainly, if we innovate Byzantine marketing, we will achieve profit.
Franco:I feel I must remind everyone that when we leverage superior products, it will be possible to supercede cashflow.

Then, as the meeting time nears an end, the facilitator's avatar can say something like this:

Frank: It's time to wrap up now. I think we can all agree this has been a very productive meeting. The future looks bright!

This is truly an important breakthrough innovation to leverage superior successes and productionize customer-focused productivity.


Posted by Dave Nicolette at 7:59 AM EST
Post Comment | Permalink
Thursday, 11 February 2010
Two lightweight, hosted project management tools
Topic: Tools

I don't usually promote tools, and even in this case I'm not sure if I'm promoting anything, really. But I've been playing around with these two lightweight project tracking and collaboration tools, and I think they're pretty good. People should be aware of them. One is called Agile Zen and the other is called LeanKitKanban.

Some of the key features that I find compelling about these products are:

  1. They are hosted services. You don't have to buy/run/administer/support/babysit servers to host them in-house. That means your employees can spend their time on activities that differentiate your business from the competition rather than on back-office application support.
  2. There is no requirement to use any particular operating system or browser as the client. Any "standard" browser on any OS will work.
  3. The pricing is reasonable. If you have "enterprise" needs, then you may need to pay for "enterprise" tools. Unfortunately, most commercial software vendors seem to want all your money just for the privilege of using their tool. These tools are priced low enough that the subscription fee won't be a decision factor in your choosing an appropriate tool for your needs.
  4. These tools support collaboration over the Internet. That means teams can have dispersed members (not the agile ideal, but often a practical reality), multi-team projects can have teams located in multiple locales, individuals can telecommute when it makes sense (again, not the agile ideal and yet sometimes an important aspect of the organizational culture), and stakeholders can see up-to-the-minute status of their projects at any time, wherever they are.
  5. These tools are lightweight and simple. There's no need for a training course just to learn how to enter project information or get analytic reports out of the products.
  6. These tools don't lock you in to a vendor-defined process framework or delivery cycle. They're based on general principles of lean software development (as described on the website of the Limited WIP Society, for instance), they give you a useful lean-based structure that visually resembles a Kanban board, and they leave the rest up to you. While most commercial products try to support different customers' needs by defining a gazillion configuration options, these tools do so by leaving most of the details undefined and allowing you to enter whatever you please (or nothing at all) in most of the input fields.
  7. It's easy to set these tools up with information radiators. Put large monitors where needed and log them into your company's account. Every update to project-related information will appear on the monitors. No stress, no bother, no distractions from the good work of delivering customer-defined value.
  8. Both these companies offer a single-user basic level of service free of charge so that people like me can experiment with the tools, show them to our clients/employers, and recommend them. They don't collect contact information and they don't require any sort of evaluation license. This is a wise marketing strategy that more software companies ought to consider. It is working for them right now, as you read this blog post. Making things easy for people is good business. (IBM, Microsoft, Oracle: Listen up!)

 

  Agile Zen LeanKitKanban
Pricing (as of 11 Feb 2010) 1 project, 1 user - free
3 projects, 3 collaborators - $9/month
10 projects, 10 collaborators - $29/month 20 projects, 20 collaborators - $59/month Infinite projects, infinite collaborators - $99/month
For up to date pricing, see http://agilezen.com/pricing
1 board, 5 users - free
5 boards, 5 users - $19/month
10 boards, 10 users - $100/month
20 boards, 25 users - $200/month
For up to date pricing, see http://www.leankitkanban.com/Account/Registrations/Pricing
Collaboration Features
  • Updates are shown on all screens that are viewing the same board, when you manually refresh
  • You can subscribe to email or Instant Messenger notification of updates
  • Updates are shown on all screens that are viewing the same board
  • You can subscribe to email or RSS notification of updates
  • When another user updates a board, a notification of the action appears on your screen
Kanban Features Supported
  • Lanes - user-defined. Backlog and Archive are predefined.
  • WIP limits (when exceeded, the background color of the lane changes automatically to provide a visual indication)
  • Lanes - user-defined. Backlog and Archive are predefined.
  • Queues - they call this "horizontal swim lanes" (vertical and horizontal splitting of lanes is supported)
  • WIP limits (you are prompted for a reason to exceed the limit at the time you drag a card into the lane)
Kanban Features Not Supported
  • Queues. You would have to handle this by convention on your team; suggest pulling work items to the rightmost lane in the (imagined) queue.
  • Order points. This is not usually needed for software-only projects or software product support work.
  • Order points. This is not usually needed for software-only projects or software product support work.
Freedoms
  • No fields are required with the exception of the card Title.
  • The "tag" feature enables you to label, filter, and sort work items in any way that makes sense for your working context. There are no predefined work item types.
  • When you exceed a WIP limit your train of thought is not interrupted with a dialog box. The background color of the lane changes, providing a visual indication that you have exceeded the WIP limit.
  • No fields are required with the exception of the card Title.
  • Backlog and Archive (special types of lanes) can be split horizontally like any other lane. This feature can be used to manage releases or to support an iterative process model.
Useful Guidance
  • Simplicity of design and a thoughtful UI minimize the need for textual documentation.
  • Context-sensitive help is easy to access and very clear.
  • Each lane is of one of the types Ready, In Process, or Completed
  • Context-sensitive help is easy to access and very clear
  • The online help wiki is comprehensive and well-written
Handcuffs None. It's easy to adapt the tool to your process. Types of cards - You are limited to predefined values: Feature, Task, Defect, Improvement
Ease of Use
  • Smooth and consistently responsive. Occasional brief hiccup on the server side.
  • Automatically saves updates.
  • Feels a bit clunky, perceived responsiveness is uneven.
  • Updates are not automatically saved. You have to remember to click the "save" icon.
Analytics
  • Cumulative Flow Diagram
  • Cycle Time
  • Lead Time
  • Wait Time
  • Work Time
  • Efficiency
  • Phase Breakdown - where all the work items are in your process
  • Cumulative Flow Diagram
  • Cycle Time Diagram
  • Efficiency Diagram
  • Card Distribution - where all the work items are in your process

Screenshots from Agile Zen:

Screenshots from LeanKitKanban:

Updated 12 Feb 2010: Agile Zen does not automatically refresh your display when collaborators make changes. You have to refresh your display. Sorry about the error.


Posted by Dave Nicolette at 11:57 AM EST
Updated: Friday, 12 February 2010 4:30 PM EST
Post Comment | View Comments (4) | Permalink
Wednesday, 10 February 2010
Merging the developer and tester roles
Topic: Continuous improvement

Warning: This post expresses ideas that are not politically correct. It will offend different people for different reasons. Parental guidance is advised.

In the past few years, one of the most interesting and positive trends in IT has been the merging of professional roles and the growing popularity of the idea of the generalizing specialist.

Business application development doesn't usually call for narrow-and-deep specialized skills in any one particular area, except possibly for short consultations on occasion. Instead, that sort of work benefits from generalists who can keep in mind the big picture and who can carry out whatever technical tasks the project calls for at any given moment. The agile approach to software development is especially well-suited to business application development, and it has become very popular over the past several years. Agile practices such as collocated team, cross-functional team, dedicated team, stable team, and collective ownership, as well as the guideline to maximize a team's truck number or bus number, have meant that technical specialists who previously worked in separate silos were working side by side for extended periods of time, spanning multiple projects. It was quite natural for them to start learning one another's specialties, at least to the extent necessary for business application development and support.

Those who have worked on business application development projects will relate to this. The level of database-related work involved rarely rises to the level that requires a narrow-and-deep specialist in database technology. There is no reason why an application developer cannot take care of the database-related work necessary for a business application development project in nearly all cases. A DBA can be brought in on occasion when necessary. The same general rule holds for other technical specialities, as well: Network technology, security, user interface design, etc. While user experience design (UX) is a genuine specialty, most business applications don't require more UI design than to follow conventional, well-known guidelines. While technical architecture is a genuine specialty, business applications almost always follow one or another reference architecture; every CRUD webapp doesn't require a fresh architectural design. The old saw that technical people and business people don't know how to talk directly to each other has been false for many years. So it goes for other specialized roles, as well. The result has been the emergence of the technical generalist — an ideal skillset for most agile-style application development and support work. The term generalizing specialist refers to a specialist who learns other skills to level-up his/her skillset.

From a lean point of view, a team of generalists alleviates flow problems stemming from all three of the famous M words: muda, muri, and mura. Its most direct effect is to reduce mura: unevenness or irregularity in work flow. To visualize how a team of generalizing specialists can achieve smoother work flow than a cross-functional team of specialists, consider the canonical Rational Unified Process (RUP) process diagram:

RUP was a step on the journey from the dysfunctional methods of the 1980s toward improved methods of delivering value through software. To address problems of long lead times and misalignment of results with business needs, RUP defined an iterative development/delivery process. Notice that the horizontal representations in the diagram of various types of activity on a project grow thicker and thinner depending on the RUP phase. This shows how the project's need for particular types of work grow or shrink depending on exactly what the team is working on at the moment. Sometimes there is more analysis going on than coding; sometimes there is more testing going on than analysis; and so forth. When the team comprises specialists, each of whom carries out only one type of activity, the work flow is uneven. Although work is always happening on the project, individual team members experience long periods of relative inactivity punctuated by short periods of very intense activity and, probably, overtime. This is mura. This sort of mura results in some misalignment of results with business needs and some amount of needless additional lead time, although it is far better than the linear and spiral processes that predate it.

There is a sort of domino effect in this process model, as well. The mura leads to muri (overburden) in that during the periods of intense activity for any given specialist on the team, that specialist is trying to complete a great deal of work in a short time. Whenever humans do that, they inevitably overlook details due to fatigue or excessive mental context-switching. Other team members are idle while they wait for the results of the specialist's work. Waiting is a form of muda (non-value-add activity). While his/her teammates are waiting, the specialist's mura leads to defects. Defects lead to rework, which is another form of muda. In extreme cases it can lead to employee burn-out and high turnover, which reduce the organization's effectiveness in delivering value on a larger scale and for a longer time than the scope of any single project.

The problem is not inherent in the RUP model as such, but is a natural consequence of maintaining traditional role specialization. You can see the same effects using Scrum or Kanban or any other process framework, if the team members are specialists. It just so happens that the popular RUP diagram illustrates the natural variability in activities quite nicely. Variability in activities is normal; problems occur when we assume each activity requires a different specialist to perform it.

The growth of the generalizing specialist did not stop with purely technical specialties. As IT professionals have pulled testing forward in the process, increasingly emphasized behavior-oriented examples over implementation-based test cases, and improved the tools to support executable requirements, collaborative elaboration of requirements, and acceptance-test driven development (for example: FitNesse, Cucumber, Freshen, etc.), the traditionally-separate roles of Business Analyst and Tester have grown together into a single role. Even in the early years of agile adoption, Testers found it frustrating to deal with code bases that were not "stable," because the tools available to them assumed all testing would be done after-the-fact. To deal with continuous testing during development, Testers found the only logical thing to do was to sit down next to the Business Analysts. Many agile team leads, ScrumMasters, and project managers have reported that even when they do not explicitly plan to combine these roles, team members tend to fold the two roles together anyway. It's understandable — it would be difficult to separate the activities of Business Analysts and Testers in an agile context. If the functionality of a system is described in the form of executable examples, and the definition of done is that the examples run successfully, then it's only natural for analysis and testing work to be done by the same team members. Indeed, when those roles are formally separated on a project that is ostensibly "agile," the separation itself is a process smell.

A similar phenomenon has occurred at the line management level. Scrum is an iterative process framework that supports empirical process control; a natural fit for agile-style product development work. Some of the proponents of Scrum predicted that the traditional Project Manager role would evolve into something quite different; something along the lines of the Scrum role called ScrumMaster. This is a process facilitator, team coach, mentor, enabler, obstacle-remover role; but explicitly not a commander or boss role. The ScrumMaster role is formally defined to have responsibilities but no authority. As agile methods, and Scrum in particular, became part of mainstream IT, what actually happened is not that PMs transformed into SMs, but rather they became generalizing specialists who combine the functions of a PM and the functions of an SM. The result has been a shift in the IT industry from a Theory X management approach, common in the 1980s and 1990s and fundamental to the dysfunction of IT in that era, to a Theory Y approach that is consistent with agile and lean thinking.

At the present time (early 2010), we seem to have reached a cultural barrier when we attempt to fold together the roles of Developer and Tester. People who self-identify as testing specialists are especially resistant to the idea of merging the roles. They go to great lengths to explain why this isn't feasible, or why developers are genetically incapable of testing software. Most of the examples they present to support this view are very weak. I'll describe one example shortly.

I think the reason for this is we have reached an old status quo stage of transformation, industry-wide, with agile adoption (in terms of the Satir Change Model). Professional testers have carved out a niche for themselves as specialists in the agile world. They know exactly how to function and how to add value on agile projects provided role definitions do not change again. As Satir observed (paraphrased), people prefer the familiar to the comfortable; the comfortable to the better. The Satir Change Model is well-documented. It's usually illustrated like this:

In the context of step-by-step agile transformation, I like the way Willem van den Ende explains it in his blog. His illustration of progressive, incremental improvement represents each improvement as a foreign element introduced to an old status quo. The pattern Satir identified is repeated as each improvement is introduced and gradually becomes part of the new status quo. It's easy to visualize the growth of the generalizing specialist concept in this way, as work practices have evolved over the past decade.

The foreign element being introduced to the old status quo at the moment is the notion that development and testing activities can be carried out by the same individuals on any given software development team, in the context of business application development. (I keep repeating the bit about "business application development" because other domains have other requirements.) The goal is to improve delivery effectiveness by reducing mura (unevenness of flow, caused by hand-offs between specialists on the team), which in turn will reduce muri (overburden, caused by peaks and valleys in demand for specialists), which in turn will reduce muda (non-value-add activity, in particular defect correction and rework, but also inventory in the form of "completed" programming tasks awaiting formal testing).

When trying to explain why developers "can't" test their code effectively, testing specialists sometimes come up with rather weak examples. In describing a "new" category of software defect he calls Ellis Island bugs, the respected testing specialist Michael Bolton describes a small program that illustrates the Ellis Island problem:

The program takes three integers as input, with each number representing the length of a side of a triangle. Then the program reports on whether the triangle is scalene, isoceles, or equilateral. [...] no matter what numeric value you submit, the Delphi libraries will return that number as a signed integer between -128 and 127. This leads to all kinds of amusing results: a side of length greater than 127 will invisibly be converted to a negative number, causing the program to report "not a triangle" until the number is 256 or greater; and entries like 300, 300, 44 will be interpreted as an equilateral triangle.

He goes on to repeat the example in C and Ruby, and reaches the conclusion that this represents a category of software defect that is very difficult to predict, and that developers are likely to miss. Each language and each set of underlying library functions makes different default assumptions about how to interpret the input strings, and each platform handles integer values differently. Therefore, the only way to catch this type of defect is by exploring the behavior of the code after the fact. Typical boundary-condition testing will miss some Ellis Island situations because developers will not understand what the boundaries are supposed to be.

The italicized phrase in the preceding sentence illustrates what I mean about "weak examples" to support status quo role segregation. These programs, in whatever language, accept any input without validating it. That's just plain bad programming. In the context of agile-style development work, we would not begin work on a feature that was so ill-defined that boundary conditions were not understood. When we don't clearly understand what "done" will look like, we continue our discussions with stakeholders until we do understand it. That's common to all agile processes.

Using the typical behavior-driven approach that is popular today, one of the very first things I would think to write (thinking as a developer, not as a tester) is an example that expresses the desired behavior of the code when the input values are illogical. Protection against Ellis Island bugs is baked in to contemporary software development technique, and is redundantly supported by other agile practices the team would normally follow: Pair programming, automated unit testing, customer collaboration. When you add to that the growing trend of software craftsmanship, the idea that developers will tend to overlook Ellis Island conditions doesn't hold watir. (Just trying to lighten it up, since this is one of the offensive bits.)

I can definitely agree that if a development team did not follow contemporary software engineering practices, then they would need someone to tag along after them to look for bugs in their code, like the shovel-bearing clowns who follow horses in a parade. The real problem in that case would not be that developers categorically write unbelievably bad code like the triangle program, but that the team in question was not following well-known effective development practices. The real solution is to fix the real problem, and not just to grab another shovel.

Eventually, I foresee a different set of professional career paths than those which evolved from traditional software development processes. At one level, there will be narrow-and-deep specialists who build technical infrastructures and deal with edge-case non-functional requirements for high throughput, high availability, high performance, high volume data storage/access, or extreme security needs. These people will usually work in the central IT department of a large corporation, or as innovators in start-up firms that have creative new ideas for using information technology. These will be the software craftspeople. At another level, there will be generalists who can assemble the building blocks of business applications cleanly and with appropriate attention to quality, following standard guidelines for issues such as UI design, solution architectures, and data storage. In contrast with present-day organizational structures, they will work in the business units that need the software, and not in a separate department. They will have deep expertise in the business domain and reasonably good general technical skills.

I think the resistance we see at the moment to merging certain traditional roles is a point-in-time snapshot of a longer-term process of change. The choice before us as individual practitioners is whether to prepare for and progress with the changes, or find a niche job where we can play out the remaining years of our working lives within our current comfort zone. The cheese is being moved, with our without our approval.


Posted by Dave Nicolette at 10:06 AM EST
Post Comment | View Comments (2) | Permalink

Newer | Latest | Older