onCommit

Is Agile Failing Us Or Are We Failing Agile?

Tue, 22 May 2012 20:53:00 -0700

I got a call today from an agile tool vendor today. They had heard we were evaluating virtually every other tool vendor in the space and started to get nervous. This tool like all of the others provide agile project management capabilities which seem to be where folks like to start there journey into agile development.

What I told him probably came as a bit of surprise, and maybe made him even more nervous. I told he was worrying about the wrong thing. Whether or not they lost some seats to a competing tool was minor compared to whether or not 'agile' actually survives! People have started asking, Is agile failing us? Perhaps rightfully so too. Our experience is not unlike many of the stories finding their way into the blogs around like this one: long live agile, is agile dead? ..or this one: Agile is Dead. A lot of the venom seems to be pointed at SCRUM, Why Is Scrum So Widely Adopted And Why Is It Dangerously Deceptive?

My own take is somewhat different based on what I've seen at large companies and what I here from my peers at conferences or meet-ups like Build Guild.

What I see and hear is teams trying to go fast without the foundation of the Software Engineering Practices needed to support it. I am going to cover this very topic at next months AgileCT meeting and can't wait to see how it is received and what feedback I get from that group. The executive summary of which is captured in this image.

My apologies to South Park and their fans ;-) To get another level of detail I'd refer back to my Orthogonal Scorecard. The good news for us legacy corporate types is that we don't have to make the entire journey from Martin Fowler to Jez Humble. Continuous Delivery in my opinion is Continuous Delivery extended and matured over time. The Zen to CI's Buddhism if you will.

What I've added more recently is some details for the 'Test' column since it is an overloaded term.

Unit
Acceptance
Behavioral/Scenario
Performance

The inability to run all of these every single day may be an indicator that your not ready for agile. I'm fairly convinced most teams don't do Acceptance Test well enough. I also think BDD might be the most important advancement in software engineering since Object Oriented Languages. Not for it's technical merit so much as the fact that it can drive the collaboration needed between the Business and Development.

Testing after all is not about code coverage, it's about making the code better and maintainable. It's about an outside-view of the code. When doe well it is how new team members will learn the app and it will allow you to fearlessly refactor and change.

I know for a fact that 'agile' works. So when I hear someone ask, "Is agile failing us?" I know this is the same old trick corporate world has used time and again. It's easy to blame tools and techniques, the quality of your developers, the difficulties of doing large integrated testing. What's harder is to change your organization, to partner for success and share in the failure. Until then I'm pretty sure it is we who are failing agile and not the other way around.

Permalink | Leave a comment »

No Bull, Chaos Monkeys, CAP Triangles and Conway's Law

Tue, 01 May 2012 19:21:00 -0700

If nothing else, I read a lot. I use my scoopit as an RSS reader, filing the 'good ones'. I'm always looking for nuggets of wisdom or insight or just some plain technical foo. I'm fascinated by the Etsy's, Flickr's and Amazon's and marvel at how well they've tackle everyday operation problems on a massive scale. The list seems to grow everyday as case studies or key note speakers share stories of success or transformation.

All the while I try to figure out what it is going to take for what I now term, legacy corporate america, to realize that traditional organizational structures and prevailing management principles [1] also have to change if they're ever going to realize the profound gains Agile has to offer. Software methodologies or management techniques like SCRUM are only superficial changes. I've seen agile teams rack up technical debt at incredible rates if you don't also get operations and testing coming up with fresh new aproaches as well. Having offshore teams write QTP test is NOT the answer.

I long to work on a system as well thought out as Netflix and their fresh take on the CAP triangle. The CAP (Consistency, Availability, Partioning) triangle is the idea that a system can only have two of the three dimensions at a given time. Netflix throws Availability out the window and designs their system to succeed all on their own.

We’ve sometimes referred to the Netflix software architecture in AWS as our Rambo Architecture. Each system has to be able to succeed, no matter what, even all on its own. We’re designing each distributed system to expect and tolerate failure from other systems on which it depends.

If our recommendations system is down, we degrade the quality of our responses to our customers, but we still respond. We’ll show popular titles instead of personalized picks. If our search system is intolerably slow, streaming should still work perfectly fine.

One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage. [2]

Can you imagine approaching your Business partners or Operations team and suggest that they impliment a system that randomly disables production instances and services? Instead I come from a long history of big monolithic systems that puth their eggs in the Consistency and Availability camp and then fail to succeed at either, more often than not. Whole armies of people and lots of money are required to make changes to production and people still have to cross-their-fingers-and-hope all goes well. People get scared so they start adding PM's and Release Managers or more Testers or maybe this time it's the BA's fault so get more of them, or re-org them. It's always something but in the end nothing gets done because to fix the problem we'd have to re-think the entire organization.

...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations - Conways Law.

Ok, but we can't just change the whole org, all at once! No, but you can allow one team to be successful, and then another and another. Put folks from all of your silos on one team and let them figure out how to develop and delivery an app like Etsy or Flickr does. I'm talking midday deploys to live production systems, without fear. Only then will folks be able to grok the real meaning of Agile.

[1] No Bull - http://www.energizedwork.com/nobull

[2] Choas Monkey - http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

Permalink | Leave a comment »

Getting a Hold on the End Points

Mon, 19 Mar 2012 06:08:00 -0700

One of my better managers over the years once told me, to get a hold of a process I like to get a hold of the end points. I have never forgot these words, and now, some 12 yrs. later, I find that I need them.

Solving DevOps in the enterprise, or worse, ALM, is like any other giant project, it's too much to swallow all at once. So much so in fact that it highlights all of the short comings of up-front, waterfall thinking. There is no way to figure out, in advance, all of things it takes to implement ALM. Or, more accurately, even if you could, no way to implement all of it at once, like some sort of big-bang integration.

So, it is with this end point in mind that I suggest to folks who are looking to right their software development ship, to start with the input. To understand the input is to understand another tidbit that same boss shared with me, Source + Tools = Product. Or, as I like to think about it, Code in, Product out! To boil it down even further, it's the build. It is mind boggling to try to comprehend how such a critical step, the manufacturing of our product, is often an after-thought. And so, capability number one of getting a hold of the end points is, Release Authority. The build is the Alpha and Omega of your product! Processes like deployment and testing is what's in between.

I first read about Release Authority in Anti-Patterns and Patterns in Software Configuration Management. Although Martin Fowler had also already offered us the idea of a dedicated build machine, in his case to serialize the builds and commits and to offer a chance to stop the assembly line if something broke. A dedicated or centralized build machine also offers some other benefits as well. They ensure that the build takes place entirely from a Source Code Control tool and don't rely on something on a developers machine. So, at the very least, all of the code has been checked in. Another benefit is that the build process itself has to be portable if it is to work on both a developers workstation and in a build farm.

Maciej Zawadzki taught us that there are only two kinds of builds, throw-away, and authoritative. Throw away builds are any builds that don't take place on the machine(s) that are designated for builds and possibly even some of the ones that are. For instance, we have CI builds and nightly code scans that don't produce deliverables and are therefore also throw-away builds.

I was also once told by one of my worst managers, we're not in the business of making snow flakes! After a pregnant pause, I told him, 'we' are, in fact, in the snowflake business. No two software builds are the same. Not only do we manufacture snow flakes, we can re-produce them if needed! If you look really closely at any one of these snow flakes you'd see, source code, libraries, tools, and static files, numbering into the hundreds and thousands, In fact, upon close inspection you'd realize that each snow flake was incredibly complex. And it is for that reason that capability number two is Bill-of-Materials. The ability to produce a BOM is a huge milestone in the build process and the answer should NOT be, it's all in source code control. Putting *.jar on the classpath to a folder full of libs all stored in your subversion repository is not being control of the BOM. Fortunately, modern build tools like Maven make this easy to do once you can answer the question for yourself. Maven's site report does a great job of listing all of the tools and libraries used in a given build.

In the vein of BOM I also feel it is very important to be able to positively ID your own artifacts, and it needs to be more than just a file name. There are four pieces of info I like to add to the manifest of JARs, WARs and EARs I make. *Who* built it, *when* was it build, *where* did the source code come from, and *what* version of the repository. Folks love to think that they can look at a file in Prod and know exactly which code it was built from, when and by whom.

There are a few more things I'll list that are just too easy not to do. Automated Unit Testing just happens with Maven so why not write some test? Static and Dynamic Analysis of the code

These basic items represent foundational items that put us in a position to build upon further as we try to tackle Continuous Integration on our way to Continuous Deployment and Testing.

Permalink | Leave a comment »

DevOps Orthogonal Scorecard

Tue, 06 Mar 2012 17:05:00 -0800

I know how much leadership loves a scorecard so I set about making one. I knew I wanted to base my scorecard on some fundemental attributes and started with the functional de-composition of applications as told by Jez Humble's Continuous Delivery book. In it he breaks apps into for pieces, Code, Config, Data and Environment. But I also liked how they characterized the Delivery Pipeline as Build, Deploy, Test and Release. Now initialy I did one scorecard for each thinking of the first as a SCM scorecard and the later as a the Delivery Pipeline. I knew right away there was a smell to having two scorecards when the all-too-obvious idea of combining the two into an orthogonal view sprang to mind.

I know think of it as a SCM / DevOps view suitable as the scorecard I will use to communicate my teams progress from here on out. What I need now it start to identify what capabilites or attributes might be the criteria for each box, probably can do some re-mapping of some of Agile Maturity Models floating around for a first cut then evolve it from there.

Permalink | Leave a comment »

10 Tips for Succeeding with Enterprise Agile Development

Thu, 05 Jan 2012 06:06:00 -0800

What follows are a few suggestions for adopting enterprise agile development successfully.

The traditional functionally-organized engineering group won't work. Splitting up software development into program management, user experience, product management, development, quality engineering, and documentation is too restrictive. Instead, establish Centers of Excellence. Each Center should focus on a core function such as team leadership (e.g. Scrum Masters), product ownership, user experience, system architecture, information management, quality, publications, etc.

Form Special Interest Groups driven by the CoEs to define, implement and monitor new guidelines. Keep the guidelines minimalist and simple. Guide the teams. Don't legislate them.

Establish team-based metrics to track team (and workgroup) performance, not individual productivity. Be clear about individual roles and responsibilities.

Establish a common vocabulary and standard rules (such as the 'definition of done') to be used by every workgroup.

Automate as much as you can. a) Workgroups should have the option of using physical or electronic boards. However, those boards will have to be rolled-up into an overall project status board. The rollups will have to be electronic to promote transparency. b) Automated regression testing is a critical success factor. Don't skimp on it. c) Consider an internal social networking tool for information sharing such as Yammer or Salesforce.com's Chatter.

Conduct retrospectives at the workgroup level and among workgroups. Inter-group communication and software handoffs will likely need improvement.

Get professional help. Good training and coaching are invaluable. Don't try to do this alone. Select a few staff members to become internal coaches/mentors (a kind of train the trainer approach).

Focus attention on 2-3 workgroups and get them to high levels of excellence in advance of everyone else so they can be role models. You'll be tempted to treat all workgroups the same and attempt to synchronize them at the same competency level. That's unlikely to be successful. Workgroups will perform at different levels. Embrace it.

Expect and encourage mistakes, that's right, encourage mistakes. Being truly agile means making mistakes and learning from them.

Set target delivery dates and hold them firmly. Everyone needs to recognize that the company is serious about meeting dates. Just be sure to give the workgroups the flexibility they need to determine what to deliver by the due dates.

via toolsjournal.com

As someone who has watched a couple of companies struggle to understand how to make agile work these suggestions are fascinating. Personaly, I've felt enterprises don't put enough into CI/CD to allow Agile to succeed but he idea of CoE's takes that idea and applieas to to each discipline imo.

What I like about the CoE's is that while a traditional functionaly organized team won't work, there still are these problems that fall along one or more functional domains. Lets just take *testing* as one example. Testing isn't just one thing but a whole litany of things. Sure deveolpers can focus on Unit Test while the old QA hats can focus on Functional testing but what about Smoke Test or Performance test? They require a much more cross functional approach becausr they can be so many things and require system knowledge of the app and the infrastructure.

I can confess that I don't personaly appreciate the need to automate roll ups of an overall project status board I do think the idea of automating Testing is key but I'd expand that idea beyond just functional regression. As I said in my previous post, tool(s) are needed that everyone can use here. Collaboration on the writing of test and the ability to share or run the test of others is so foundational to overall collaboration and success. In a way, test one great way to ensure a *common understanding* of the application with executable specifications sitting on the top of that heap.

With a solid testing foundation you are also in a position to *expect and encourage mistakes*. Everybody makes mistake but nobody likes leaked defects.

In my spirit of top 10 list having 11 items on them, I'd add, at the #1 spot, *Define what Done means!* It's not enough to say Done means Delivered unless that criteria is applied to the end of the iteration and not the Delivery Date. To have to be done at the end of a sprint/iteration really forces your hand on a lot of the technical practices that really enable Agile to succeed.

Permalink | Leave a comment »

Top 10 Ways to Transform Software Development in the Enterprise

Mon, 02 Jan 2012 10:19:00 -0800

In the spirit of end-of-year top 10 list I thought I'd try my hand at one of my one. Changing a culture is all about changing behaviors so here is my take on where to start and the baby steps down the road towards transformation.

Establish Release Authority - Sadly, this most fundemental of points still needs to be explained in many organizations. Even if you already have a Build System, it's important to remember why that's important as well. This idea I learned pretty early on from Anti-Patterns and Patterns in Software Configuration Management. If you still have developers building localy and emailing artifacts, then you are indeed starting from scratch. Release Authority is the most foundational of concepts upon which everything else is built.
Build Your Code with Every Commit - I'm avoiding saying CI here intentionaly since I'm trying to build in baby steps. Be it polling or triggers you need to know that code still, at least, compiles. Keeping the build *green* at this stage is an important cultural norm to establish. Once the build it broke, deal with it. Stop commiting until it is fixed or rolled out. Bring shame to anyone who commits broken code.
Unit Test - It is simply too easy to turn on automated unit testing to not be doing it. Be very clear about what is, and isn't, unit testing. The term is all-to-frequently missused. Always ask if unit testing is being done and if the answer is *yes* make them explain exactly what they mean by that. Too often it means a local build was done and they clicked a few things to test there functionality/widget/fix which is NOT unit testing. Unit testing is one more small bit of assurance and not a silver bullet by any means. It is also another level of pre-commit validation and as such folks whose commits break the build should be publicaly embarrased and ridiculed ;-)
Scan Your Code - Much like unit testing it is simply too easy to do this these days not to be doing it. The richness of these tools vary by language but find what your language offers and leverage it. Static and Dynamic analysis, like unit testing, is not a silver bullet but then quality is like security and needs to happen at every step along the way (read Caper Jones if your not familiar with this idea). Java shops should look into Sonar if you haven't heard of it. These tools are a lot like the cockpits of an airplane, they wont fly the plane for you but they provide lots of feedback to help you make informed decisions.
Get Control of your BOM - If you cannot easily show your Bill-of-Materials you're probably not in control of your product. Putting third party liberaries into you SCC tools doesn't count either since you can't prove what is actualy used or not or where they came from or if they've been tampered with. There isn't really just one thing to do to get control of this so the next couple of items on the list will try to identify the 'How'.
Setup a Binary Repository - I can still remember a time when not everyone was using SCC but it didn't take too much convincing to get everyone on board. Today, binary repositories occupy that distinction. Checking your binaries back into your SCC tool is not the answer either. Tools like Artifactory and Nexus do the job well and can be had for free.
Manage your Dependencies at Build Time - Maven paved the way here but there are several alternatives these days. If your an Ant shop, look at Gradle as the way forward. I'm still a big fan of Maven but Buildr has got my attention as well. Either way modern build tools can help you manage your dependencies with the Binary Repository. At this point we have a basic CI system.
Automate Deplyment to Dev - Much like #1 was foundational to every else after it this item is the foundation upon which we can build a Continuous Deployment/Delivery system. By focusing on one environment and driving toward zero-touch, self servicable deployments we can pave the way for everything to follow. It's a huge task so stay focused on Dev. Up until now we could have done most everything for free but this is where we'll likely need to spend some money. With that in mind get in touch with your companies budget cycle and give yourself lots of time to make the case and garner support. Much like getting control of the BOM was a huge task, this one is even bigger, much more complex and varried. To that end the next couple of items will shed some light on the 'How'.
Think About the Functional Decomposition of your App - Continuous Delivery taught me that we can functionaly decompose an into 4 pieces: Code, Configuration, Data, and Environment. The first 7 items in this list focused on the code and now that we want to deploy it's time to think about the rest. A deployment pipline tool like UrbanDeploy or DeployIt can help a lot with middle tier configuration and even DB changes.
Think About How Every Can Collaborate on Testing - Automated testing has a long and not so rich history in software development. Virtualy any enterprise that has tried will tell you that it doesn't work, I'm here to tell you they were doing it wrong! Tools like QTP and testing through the UI are simply the wrong aproach. What's really needed is a tool(s) that everyone can use so that we can think about the life-cycle of a test. How do new test get written? and more importantly, how are they shared? How does a defect become a test become a regression test? We also need to think about more than just functional testing. We need to consider Smoke Test and Performance Test and how we bake these into that automated deployment. We need to think about which test get run when and how long they take.. I'm going to read Agile Testing in the hopes that it can help me here as this is precisely where I am today.
Specification by Example - Ok, I said 10 and really this is a part of #10 but worth it's own entry. Specification by Example is quite possibly the most important advancement in Software Engineering since OO was introduced, at least in my opinion anyway. And while I'm no fan of Silver Bullets this may well come the closest to being one. If 2012 is the year of breaking down silo's then Spec by Example is one example of how to do that when the Business and Developers learn to write the spec together, derive scope from that spec and ultimately turn it into an executable scenario/test.

Permalink | Leave a comment »

Business Driven Development

Tue, 25 Oct 2011 14:31:00 -0700

Acceptance Test Driven Development

View more presentations from Naresh Jain

This deck has a couple of visuals that are keeprs! What's more, I really think this style of development / testing is the most important advance in software engineering in a very long time. While I've never fully bought into Uncle Bob Martin style TDD I would however advocate for 100% coverage of User Stories with Acceptance test. When it comes to Unit test I do like non-functional quality measurements to be baked into the business requirements from the start. For legacy apps I'd target ~80% coverage for the most complex and/or the most used pieces of the code base.

I'm usualy not big on semantics but I do think calling this style of development, Business Driven is both the smartest and most accurate description of the process. In the end it is is always the *Business* you have to sell too, so why not give them what they want?! It drags product owners right into the actual development process since they have to write acceptance test. I'm also betting that once they get a taste of that, they'll be hooked and wont be able to stop writing test.

I also like the idea of leveraging the idea that Business and IT *pair program* these test to deliver both business facing and technology facing test. Really pause for a moment and think about that, the Business and IT pair programing, using a Domain Specific Language in a way that ensures they reach a mutual understanding of what is expected! How does it get any beter than that?!

Udate: 2 Jan 2012

Having recently read Specification by Example I have been convinced that the name is important semantics and all

Permalink | Leave a comment »

Using Sonar to monitor and remediate code bases

Thu, 23 Jun 2011 18:34:00 -0700

via slideshare.net

Steering a Super Tanker is an excellent presentation that shows some innovative way to identify and attack technical debt. At the heart of this presentation is the notion of identifying and remediating modules with high complexity per method, an approach I too would advocate. However I find it curios that the motion chart axis are set to complexity/method in the Y and LOC in the X with color and size set to complexity/method and overall complexity! The beauty of the motion chart is it's 4 axis representation so I find the size and color setting to be redundant. It's no coincidence that the color exactly correlates to the Y axis while there is also a strong correlation between overall complexity and LOC. It's not until the Gaming the Metrics section that the author comes close to a setup I use everyday. I find that setting the Y axis to Coverage, X to rules compliance with Color set to Complexity per method and size to LOC provides an excellent overall view of the modules. With this arrangement we can see zero-test modules and identify any high complexity items as risk. So long as our highly complex items also have high coverage then we might not have to panic so much.

The other really great thing about this view and the Motion Chart in general is the ability to spot things over time. At my last job where I was monitoring millions of lines of code accross 50+ projects I would periodicaly view the motion chart, in motion. This video playback representation of the data over the previous three months frequently allowed me to spot interesting events within projects. One great example that I love to cite was when I witnessed a sharp increase in coverage on a couple of the hundreds of modules under inspection. First one, then a second and third module shot up the chart (coverage) and then drifted to the right (rule compliance). All three modules where a part of the same project and prompted me to reach out to the project owners to commend their efforts and learn how it come to be. What I learned was the team had installed a lava lamp to indicate broken builds and the business owners had come to be aware of the lamp upon seeing it lit up. The short story is this lamp then led to a discussion as to why the build was broken and ideas about how to improve. The developers had felt like they weren't funded to write to unit test but explained how they could have helped identify issues in local builds before the code was committed. So, the business added a Unit Test coverage target, along with a rules compliance target, to thei non-functional requirements thus authorizing the developers to spend time on these task. Within 2 weeks the three modules had 80%+ coverage and improved their rules compliance by 15-20%!

While the Motion Chart is a great visualization I'd also suggest keeping a close eye on Clouds->Top Risk and Hotspots. Clouds offers a much more granular view and can spot complex/low coverage packages that can be hidden in high LOC components. Hotspots provides a no-nonsense, actionable view of potential areas to dive in one.

In general, the biggest issue I battle with Sonar implimentations is that people really want to be *told* what to fix. It takes time to get folks used to Sonar reporting and to establish a culture that knows how to drill in for themselves based on the issues at hand. Sonar provides so much data it can be overwhelming at first. I've found that focusing on Coverage in the Most Complex or Most Used modules/packages is a good place to start for legacy apps.

Greenfield apps should establish non-functional requirements for Rules Compliance and Coverage and consider using the SQALE model to focus efforts by life-cycle. Use sonar after each sprint/iteration and/or release to continualy monitor, talk about and remediate issues as they appear.

Permalink | Leave a comment »

SQALE | Software Quality Assessment based on Lifecycle Expectations

Thu, 02 Jun 2011 09:36:00 -0700

via sqale.org

An interesting looking emerging Software Quality Framework. Mapped right onto the SDLC it seems to combine a lot of ideas that have come before it. Sonar had already been reporting on Static and Dynamic analysis results in terms of things like reliability, portability..., they even had a technical debt plugin SQALE seems to use the technical debt metaphor but in a very practical way. You decide your Quality thresholds and SQALE would tell you, in terms of amount of remediation (TD?) how far from your target you are. SQALE does introduce some interesting data visualizations that makes it easy for programmer and App owners to quickly see how they are doing and make decisions about where to direct your resources.

The layered approach to the disciplines combined with the cumulative nature of the total index and it seems to re-enforce the idea to start with unit testing and then write good code as a means to improving the overall quality. No funny weighting, just the aggregate TD.

The more I think about it, the more I think this approach is diametrically opposed to the current Sonar dashboard. In Sonar, you want to get your compliance percentages closer to 100 while it prioritizes the rule violations by severity. The natural response is to work on any Blocker first, regardless of it's classification, Maintainability or Changeability for instance.

In the SQALE model, it implores you to get a testing foundation first, both unit and functional, to keep your numbers low. Their spider graph puts a green bullseye in the middle with a red outer ring. Instead of trying to get your graph out towards 100 you want to drive it towards 0. It also shows the *stated* goal for each axis or the amount of acceptable technical debt for each *phase*. This approach seems much more in line with agile methodologies where as Sonar's makes a better fit for Legacy applications. New agile apps can avoid ever creating a mountain of technical while legacy apps surely have a mountain to chip away at.

More than anything else, I see the SQALE model as a mechanism to drive a Software Quality initiative within the Enterprise. Every aspect of it appeals to the sensabilities of corporate culture. A well defined defined model that lets you pick your level of involvement combined with easy-to-understand metrics to measure results with.

Permalink | Leave a comment »

Technical Debt as a Business Goal

Sun, 29 May 2011 22:10:00 -0700

via theagileexecutive.com

As Figure 1 demonstrates, a Java file with Cyclomatic complexity of 38 has a probability of 50% to be error-prone. If you do not stop it prior to deployment through technical debt criteria, it is likely to affect your customers and play havoc with your deployment quite a few times in the future. The fact that it did not do so during the first hour of deployment does not guarantee that such a file will be “well-behaved” in the future.

I am going to go back through my *work* related post from Lasterday and bring them over here, revisiting them as I do so.

I remember this chart in particular really grabbing me, the idea that a 50% probability of a defect could be predicited from nothing more than complexity. Could we start to produce *potential defect rates* a la Casper Jones and function points? Even if it has decent testing at say the Unit and Functional levels? Is every 80 points a defect or more?

The idea of tying TD criteria to release criteria is an interesting one though I'd prefer to have *business goals*. If the *business* is the driver then there is no question but if the dev team set's these *technical* thresholds, then how do you rationalize a delay back to the business??

What would be some reasonable goals? Minimum 50% unit test coverage? No more than $2 TD/LOC? Does something like SQALE make the most sense as a way to define and track quality goals?

Permalink | Leave a comment »

Code in, Product out.

Wed, 25 May 2011 17:47:00 -0700

Welcome to my new personal branding site, onCommit. Named after SCC style *hooks* that can trigger builds and everything else we can automate after code is checked in. I will try and bring over stuff from my Lasterday site but this site will allow me to better channel my proffessional interest separate from my personal ones. My facebook friends wont have to look at all of my geeky post and my LinkedIn contacts don't have to see my kids recital ;-)

There is an companion Twitter account @onCommit. Stay tuned.

Permalink | Leave a comment »