Better Software Magazine

Better Software Magazine Articles

That's No Reason to Automate!

Automating test execution is supposed to give tremendous benefits, but often gives disappointing results—because it hasn’t met the objectives set for it. The fault may not lie with the automation itself, but with the objectives you are attempting to achieve. Aiming at the wrong target does not bring success! For example, objectives for automation are often confused with objectives for testing, but they should be different. In this article, learn how to avoid the most insidious traps and how to recognize good objectives for automation.

Feel the Burn: Getting the Most Out of Burn Charts

Burn-down charts have become a popular project artifact, but too often, people accept the default chart from whatever project management tool they're using. What choices can we make about the chart format and scale that will help us create charts that answer the questions that are really important to us? And when the chart looks "funny," what could it possible mean?

George Dinwiddie's picture George Dinwiddie
Software to Go: Developing Applications for a Wireless World

The mobile arena is in constant evolution, changing the way we approach software development both from a business and a technical perspective. Taking the time to set your plan can make the difference between success and just a good idea. In this article, Luis Carvalho shares some guidelines for bringing new applications into the mobile ecosystem.

Luis Miguel  Carvalho's picture Luis Miguel Carvalho
Avoiding Half-baked Discovery

It can be difficult to explain to your customer why cutting half of the features doesn't cut half of the time and cost. Every software project has fixed costs that often get overlooked in project planning—setting up development environments, ramp-up, building frameworks, and setting up configuration management to name a few. Read on for some ideas on how you can position this with your customer.

Didier Thizy's picture Didier Thizy
Testing the Contract Metaphor

A contract represents a service agreement between two parties, the bounded provision of service by one party to the other. This metaphor also applies to how we can think about the relationship between unit tests and code. A contractual mindset encourages test names and partitioning based on clear propositions, backed up with executable examples.

Kevlin Henney's picture Kevlin Henney
Crash Course in Proficient Presenting

Ben has to make a presentation at the next all-hands meeting. It'll be his very first presentation, and just thinking about it has sent him into a panic. Fortunately, he has the support of an experienced speaker and coach who offers advice and encouragement to help him become a proficient, panic-free presenter.

Naomi Karten's picture Naomi Karten
Issues about Metrics about Bugs

Managers often use metrics to help make decisions about the state of the product or the quality of the work done by the test group. Yet, measurements derived from bug counts can be highly misleading because a "bug" isn't a tangible, countable thing; it's a label for some aspect of some relationship between some person and some product, and it's influenced by when and how we count ... and who is doing the counting.

Michael Bolton's picture Michael Bolton
GUT Instinct

Whether or not a unit test is considered good is not simply about what it tests: It is also very much about "how" it tests. Is the test readable and maintainable? Does it define the expected behavior or merely assume it? To be sustainable, the style of a unit test is just as important as the style of any other code. Perhaps a little surprisingly, the most commonly favored test partitioning style does not meet these expectations.

Kevlin Henney's picture Kevlin Henney
Putting the Kart before the Horse?

Go-karting is where most of the current Formula One racing drivers first learned the basics of race-craft. Antony Marcano, a former kart racer himself, recounts a father-and-son racing experience that helps him explain what goes wrong for many organizations that adopt Scrum as their first attempt to "go agile."

Antony Marcano's picture Antony Marcano
Time to Let Go of Obsolete Jobs

Town crier, elevator operator, gas lamp lighter, carbon paper distributor, telegraph operator—you probably haven't seen many help wanted ads for these occupations lately. Why? Because these occupations are gone—obsolete, unnecessary, outdated. We just don't need them anymore. When new paradigms are created, new jobs are often created with them. And sometimes, existing jobs are no longer relevant.

Lee Copeland's picture Lee Copeland

Pages

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.