A Software Engineer’s definition of “complete” is different from a Manager’s.
When you ask a Software Engineer (developer) if he has “completed” his work, do not walk away satisfied with an answer of “yes,” “almost,” or “90%.” You must be clear on what has been or is almost complete.
To understand a developer’s language, you have to understand the different phases of software product development. Each developer is assigned one or more “units” or portions of the product to be created. The developer will first design the unit, then code it, then test it (called unit test). After unit test is completed, that unit gets integrated with other developers’ completed units to form a whole product and the product is sent to the Quality Assurance (QA) group for testing. During QA testing, numerous bugs will be found in the various units of code and those units will be sent back to the responsible developers for correction. This process repeats itself until a final product is working well enough to be released to a customer.
Of course, this is a high-level description of a software development process. You should ensure you understand the process and specific terminology used in your organization. Then when you ask a developer if his work is complete, you can ask a few more informed questions for clarification. Is it the design, the code, unit test, or QA test? Further, are there bugs that are still being worked out or is it ready for release to the customer? If it is ready for release, does that mean only that developer’s unit, or the entire integrated product?
I remember multiple occasions when my most dependable, seasoned developers told me something was finished, only to see actual working product many months later. They were not purposely trying to deceive me; we were just not speaking the same language. When I ask, “Are you finished yet?” I am thinking of the final product. When my developers hear, “Are you finished yet?” they tend to interpret that as whatever development phase they happen to be working on at the moment.
You might say the developer had a responsibility to communicate more clearly, but then again, so did I. You can teach your staff over time how you want them to communicate with you, but when it comes right down to it, you can only be responsible for your own communication. Whether you are the talker or the listener, you better take it upon yourself to clarify the information being shared. Misinformation can result in chaotic operations and a loss of important customers and revenue, so don’t chance it.
