aspose file tools*
The moose likes Agile and Other Processes and the fly likes Technical excellence Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Technical excellence" Watch "Technical excellence" New topic
Author

Technical excellence

Mohamed El-Refaey
Ranch Hand

Joined: Dec 08, 2009
Posts: 119
Hi Marry,

In your book "Leading Lean SD ..", can you please summarize what it covers regarding the team and project technical excellency? and in your opinion, how these guidelines and practices can be easily applied by the technical team and how they got convinced with?




Best Regards, Mohamed El-Refaey
www.egyptcloudforum.com
Mary Poppendieck
author
Ranch Hand

Joined: Oct 04, 2006
Posts: 62
From a team perspective, technical excellence means building quality in. If you take a look at your overall release cycle, from the time you start coding until the time the code is used in a production environment, what percentage of that cycle is reserved for "hardening" the code? That is to ask, What percent of a release cycle is reserved for "test and fix" activities? We often find that about a third of a release cycle is spent in things like system test, UAT, etc. This is an indication that the development team was unable to build quality in. Now that is usually not the team's fault - often the process is faulty. A team should know how to test their code when they write it, and they should be able to integrate it very frequently with the code it is going to have to work with eventually. This way a defect will be detected as soon it is injected into the code, not found later.

A process which allows defects to build up, only to be found later, is not a good process, even though many of our software development processes seem to be designed this way. Technical excellence means many things: code clarity, low dependency architecture, fitness for use. But from a process point of view, I'd say that a good measure of technical excellence is the number of defects that we find (and EXPECT to find!) after developers are theoretically "done" with coding. The classic agile practices of TDD (with both xUnit testing and acceptance testing) and continuous integration (at the application level and system level) are a good start toward technical excellence, because they mean that when code arrives at final verification it is EXPECTED TO WORK. Finding defects at this stage is a surprise, because they are almost all discovered in the course of the normal development process.


Mary Poppendieck
Author of Lean Software Development, Implementing Lean Software Development, and Leading Lean Software Development
Mohamed El-Refaey
Ranch Hand

Joined: Dec 08, 2009
Posts: 119
From a team perspective, technical excellence means building quality in. If you take a look at your overall release cycle, from the time you start coding until the time the code is used in a production environment, what percentage of that cycle is reserved for "hardening" the code? That is to ask, What percent of a release cycle is reserved for "test and fix" activities? We often find that about a third of a release cycle is spent in things like system test, UAT, etc.
Mary Poppendieck wrote:This is an indication that the development team was unable to build quality in. Now that is usually not the team's fault - often the process is faulty. A team should know how to test their code when they write it, and they should be able to integrate it very frequently with the code it is going to have to work with eventually. This way a defect will be detected as soon it is injected into the code, not found later.


This means that developers play a very important role in the delivevred quality and reducing the time needed in system test and UAT ... Actually, most of the case developers deliver the code once it is 'just' working, he didn't spend any effort to tackle or break it with different scenarios, he leave it for testers to break his code ...
Quality formula is simply starts from the developer mentality of delivering solid and tested well code ... otherwise, the dev-test cycles will take too much time to finish ...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Technical excellence
 
Similar Threads
Need Ans for HR Questions
Taming the TTW reviews on amazon
Interview question: project structure ?
My One Year Experience
Hierarchical Designations in IT Industry