Slashdot Mirror

"B12 is an edge case "

Exactly why TDD is so important when designing a diet! ( Ducks )

... the pompous notion that process can somehow prevent logical errors

Pompous?

  Preventing logical errors is the key idea here: Introduction to Test Driven Design (TDD).

excerpt: If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it?

So... what's your strategy for preventing logical errors?

Yes, pompous. There are no valid blanket statements on the meaning of bugs found during testing. That would depend on the bug found. Could be a systematic issue with the development process. Could just be that people aren't always perfect.

A bug found in testing could be due to an issue in development, an issue with the requirements, an issue with the test.

In fact, when I work with teams, I teach them that if your testing "phase" finds bugs, it's a problem with your process that needs to be addressed immediately, so the concept of ensuing[sic] that QA doesn't find anything is a great concept to bring out.

So if my testing finds a bug, all other work needs to stop so the problem with my process can be addressed immediately. (Even if the problem with my process is just that people are involved.)

So what if I water down my QA process so that no bugs are found, no matter how bad the code is? Does that mean there are no problems with my process?

... the pompous notion that process can somehow prevent logical errors

Pompous?
Preventing logical errors is the key idea here: Introduction to Test Driven Design (TDD).
excerpt: If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it?

So... what's your strategy for preventing logical errors?

There are a lot of techniques available that can make software reuse possible. One of them is Test Driven Development. When every bit of your functionality is checked with automated tests you can easily put your sourcecode into another contexts, rerun all the tests, and if they are ok it is a good indicator that it will work.

We also need a paradigm shift to concurrent programming. This will IMHO inevitable happen, as the processors are becoming more and more multicore. The currently used threading model is totally infeasible, we need something like the Erlang model.

Erlang seems to be on the right track. The thesis Making Reliable Distributed Systems in the Presence of Software Errors should be a must read for everyone who cares about reliable software. We are going to have to live with the fact that software will never be error free.

Another concept for reliable software could be multi agent systems, that have similar ideas like in Erlang but go a far step forward.

All in all, reliable software and reliable software reuse definitely is possible. Just not with mainstream technology.

Programming languages are just tools, you want to keep up on the trends? Learn more about how best to use the tools. Employers now are more and more concerned with getting a high quality product out the door in a reasonable time and the claims of using OO or structural langauages are just hype.

It is the developemnt strategy that will either make or break a project. Knowing the latest trends on requirements capture, design, testing and coding techniques for your niche and knowing how to adapt and taking pragmatic approaches will be far superior than knowing the latest trends in programming languages

No, tests don't say how your code is supposed to work. They say the expected results for certain limited cases. This is nowhere near as clear as an actual prose description. Its also very dependant on the unit tests themselves not having bugs- and thats pretty rare. I count on a textual abstract description being accurate as far more likely than test code in my experience.

It sounds to me like you've never encountered very good unit tests. Try doing test-driven development for a couple of months and you may have a different opinion. Certainly I don't notice any of the problems you mention as being significant anymore.

I don't have a problem with most of these development methodologies perse, but most of them seem to lack the entire concept of DATA and INFORMATION.

You should check out things like Agile Modelling and Agile Data for more information. I don't think it's core to agile methods, as not every application uses a database. But if you're big into databases, these sites can help you see how agile approaches could work in your environment.

Do these methodologies include some prep work on gathering business requirements and understanding the underlying information relationships?

It's not just prep work; it is work that should happen all the time. That's why Refactoring and Domain-Driven Design are such a big deal to people doing Extreme Programming. We strive for representational harmony across all levels, from talking with users down to the database schema. And not just in the spec, either; as we learn more about the domain and find better representations, refactoring lets us safely change the structure of the code to match.

Any "enteprise" programmer has dealt with SQL, so we've all done declarative programming. But mixing SQL with procedural code highlights the impedance mismatch between objects and database tables.