Summary
I don't care how good you think your design is. If I can't walk in and write a test for an arbitrary method of yours in five minutes its not as good as you think it is, and whether you know it or not, you're paying a price for it.
Advertisement
I'm convinced that there is a chasm in the industry and it's getting wider.
I'm tired of seeing design that is brittle and hard to change. I'm sick to death of seeing people groping through their code, trying little things and then building the whole system so that they can run it manually and see if it does what they think it should do.
You think your design is good? Pick a class, any class, and try to instantiate it in a test harness. I used to think that my earlier designs were good until I started to apply that test. We can talk about coupling and encapsulation and all those nice pretty things, but put your money where your mouth is. Can you make this class work outside the application? Can you get it to the point where you can tinker with it, in real time, build it alone in less than a second, and add tests to find out what it really does in certain situations. Not what you think might happen, not what you hope might happen, but what it really does?
That's where we are in the industry now. Some teams can work with their classes that way. Others can only work that way with a small percentage of their classes. And, if you ask them whether they'd rather work in the code without unit tests or the code with them, the answer is clear. You can simply work faster when you your turnaround time is faster. Your steps can be more sure when you know what the effects are.
People who know me, know I'm a rather quiet guy. I don't shout about too many things, but frankly I think there is just too much at stake in the software industry right now. If you haven't seen the difference there is in working this way, you need to. The bar is higher now. Best practices have gotten a whole lot better in the last five years. Don't tell me your design is good when I see you struggling.
I couldn't agree more. The bar should be higher in every respect.
Classes should be testable as you say. Objects should not be thought of "caches for data pulled from the database where stored procs are doing all the work anyway". Strong models should be evolved that are extensible, maintainable, reusable and pattern rich. Systems shouldn't be a rats nest of Hashtables and Vectors that have new developers groping around trying to discover whats going on! Systems should survive their first release.
Users should expect fully tested, robust software they need based on a collaborative effort with a well-focussed, responsive development team. Clients should expect high quality, bug free software delivered on time and to budget.
In short, our software should be as robust and reliable as the hardware it runs on.
There is a wealth of material in the agile community to help all members of the software industry at all levels raise their game - there's no excuse not to do better.
> Classes should be testable as you say. Objects should not > be thought of "caches for data pulled from the database > where stored procs are doing all the work anyway". Strong > models should be evolved that are extensible, > maintainable, reusable and pattern rich. Systems shouldn't > be a rats nest of Hashtables and Vectors that have new > developers groping around trying to discover whats going > on! Systems should survive their first release.
Channing, I agree, those are all great things, but my point is narrower than that. I've worked with many teams who use patterns, have the logic in the right place, etc. but when when you sit down to work with someone.. well, I had an exchange like this a few weeks ago.
client: So what do you think of our design, pretty good, right?
michael: Hmm.... I just sat down with Mark and it took us two hours to instantiate one of your classes in a test harness. Why's that?
client: Yeah, well, we don't have many tests, but we are using patterns.
michael: What's your bug count like?
client: Pretty bad.
michael: You realize that whenever you make a change here it's just "edit and pray", right?
I like the good things. I like coherent names, commmand-query separation, layered architecture, etc. But to me, now, testability is the standard. If your classes are not testable, your design is messed up. If your classes are testable, we can talk about patterns and all sorts of things that make your design better. And more than that, we're actually in a position to do those things safely.
> What exactly makes hardware so 'good'? Is it only simplicity (compared to complexity of software systems), or maybe something else?
As someone that worked in both digital and microwave and optical comms, I can tell you that the reason is quite simple: electronics is very unforgiving of bad practice. Do a bad job and it blows up in your face - quite literally sometimes as I can attest.
In software we can log errors, recover from crashes, pop up dialogs saying 'oops I appear to have lost my dlls' and deal with them later - a bit harder to do in electronics when its on fire. We can redistribute a new release relatively painlessly - not possible in hardware without great expense.
Software is much more forgiving (as are end users of software).
> Is it only simplicity (compared to complexity of software systems)
Hardware can be as every bit as complex as software but electronics demands much more from the process and the people. Poor practice is self-evident to the non technical - it can't be covered up.
Another result of the unforgiving nature of the physical world is that it is widely understood and accepted that it takes time, skill and patience to become a good electronics engineer. You don't get 1st year graduate students building critical parts of electronic systems, they are mentored and supervised very closely. The same, sadly, cannot be said of software.
> > In software we can log errors, recover from crashes, pop > up dialogs saying 'oops I appear to have lost my dlls' and > deal with them later - a bit harder to do in electronics > when its on fire. >
Blame code reusability and layering principles in SW engineering then. You reuse bad components, build yours on top of bad components, and then, regardless of how good you are, the result is still bad, inevitably.
> > Another result of the unforgiving nature of the physical > world is that it is widely understood and accepted that it > takes time, skill and patience to become a good > electronics engineer. You don't get 1st year graduate > students building critical parts of electronic systems, > they are mentored and supervised very closely. The same, > sadly, cannot be said of software. >
Blame good software development environments and tools then: they finally led to a situation when ANYONE can learn programming in 1 month (Java, VB and Co.). SW engineering has finally found itself on one shelf whith banana growing. Why? Because the tools are too good!
> > Software is much more forgiving (as are end users of > software). >
The complexity of software compared to its cost is the reason users can forgive your mistakes. And if it sells - it works, isn't it true capitalism?
You sell an operating system + an office suite and you can easily convince the buyer that you did your best. Complex systems are difficult to evaluate, oftentimes they have nothing to be compared with. And finally, the monster you sell costs just a few hunderd dollars, as opposed to a comparably complex physical system, like a modern car.
I think that the real problem is that people do treat software design like hardware design, pointlessly difficult hardware design.
Let's face it, over 90% of developers out there develop systems like they were building a "ship in a bottle" the hard way. Drop a piece into the bottle, find the place where you need to add it and use long tongs to fix it with glue. If you mess up, start over again.
To me, that is analogous to: find a method where you have to make a change, in place, think real hard, make the change, do a system build, run the whole app and see if you got it right or not.
> Blame code reusability and layering principles in SW > engineering then. You reuse bad components, build yours on > top of bad components, and then, regardless of how good > you are, the result is still bad, inevitably.
There are many reusable components in electronics too: digital chip sets, amplifiers, etc. It would be an interesting survey to see what proportion of bugs were caused as a result of reusing existing components as opposed to new code written for the project.
> Blame good software development environments and tools > then: they finally led to a situation when ANYONE can > learn programming in 1 month (Java, VB and Co.).
This is true, people can learn the syntax of a language and the mechanics of loops, conditions, etc. very easily. However, there is no ide yet that will enable one to build complex systems. To often in this industry we assume that because someone knows the basics of a language they will be able to build complex systems.
In the electronics world each component passes extensive tests, 'soft' simulation, extraction of parasitic elements. Then you receive your chip from the foundry and continue testing. (In fact, parasitic elements in electronics are sort of unforeseen 'bugs' caused by the complexity. But, to my knowledge, they are pretty much 'exposable' at simulation time.)
Electronics engineering today is at the level where it is able to check conformity with the specification and track all kinds of problems in the design. Software is just heating up in this respect. Every HW engineer knows that testing is an integral part of the whole process and that there is no design without testing and simulation. Of course it is not always possible to track bad design, since bad components can work, too... Nevertheless, my TV works much better than any computer with Windows or Linux or whatever else installed on it.
> Every HW engineer knows that testing is an integral part of the whole process and that there is no design without testing and simulation.
Yes absolutely. I believe the software industry is very slower starting to accept that testing should be an integral part of the whole process including design.
In fact, this week I've been looking for contracts in London and have been very surprised by a number of clients asking specifically for experience with agile methods and test driven development. Encouraging signs :-)
Every HW engineer knows that testing is an integral part of the whole process and that there is no design without testing and simulation.
Yes, exactly. Long ago before I got into software design I was an ASIC (Application Specific Integrated Circuits) designer and for a while I worked in the design center of an ASIC Company. Customer companies would come to us with their designs and pay us to build the chips for them. We had certain testing requirements that had to be met before we would build them a chip. So the customer would hand us their design and their sets of test vectors and we would simulate their design using our 'golden' simulator. If there were either functional or timing problems we would require that they be fixed. We would also 'fault grade' their vectors to determine how well they could find 'stuck-at' faults (places in the circuit that might, due to manufacturing defects, become shorted to power or ground). If their vectors fell below a certain grade we would either require that the customer improve on their grade by adding more tests or make them sign a waiver that said it wasn't our fault if they got any bad chips. When they looked at the document they would have to sign and realized the potential financial consequences they usually took the 'add more tests' route.
It's interesting to note that in hardware design the time it takes to create a good set of tests is usually expected to be at least as long as it took to design the chip itself. Sure, some management types will sometimes complain about this, but the experienced designers and managers know up front that's what it's going to take and that it's just not worth it to skimp in this area.
In chip design the consequences of skimping on testing are quite clear and they lead directly to expenses and liability. The connection isn't nearly as clear in software design as perhaps it ought to be.
Flat View: This topic has 25 replies
on 2 pages
[
12
|
»
]
Previous Topic
