The Artima Developer Community
Sponsored Link

Weblogs Forum
The Bar is Higher Now

25 replies on 2 pages. Most recent reply: Jan 11, 2005 1:50 PM by bug not

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 25 replies on 2 pages [ « | 1 2 ]
Ian Rae

Posts: 21
Nickname: ianrae
Registered: May, 2003

Re: The Bar is Higher Now Posted: Apr 5, 2004 11:27 AM
Reply to this message Reply
Advertisement
I was shocked to learn that hardware designers use design tools that fully simulate their chip design -- the components, the bus, everything. They can fully test their design under all sorts of simulated error conditions before they go to the fab. Even then it requires several iterations to get things right.

Then I compare this to software, where most developers have no way to test hardware failures, disk-space errors, memory exhaustion, network errors, CPU load, etc. Other then creating the real failures with a lot of manual steps.

How is software ever going to get to the point of full automated testing when you can't even move a class out of situ? The answer is: it's not.

I'm a bit surprised though that you encounter the ship-in-a-bottle approach so often. I thought most teams had at least moved to framework + app logic, where common code was out in a fairly testable framework.

As a point of sympathy, here's what we have to do to test a single line change in legacy C++ code: launch vb in the the debugger, load a test project in vb, run the project, make a phone call, navigate to the feature under test, finally to reach your line of code in the debugger. Yuck.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: The Bar is Higher Now Posted: Apr 5, 2004 12:03 PM
Reply to this message Reply
> I was shocked to learn that hardware designers use design
> tools that fully simulate their chip design -- the
> components, the bus, everything. They can fully test
> their design under all sorts of simulated error conditions
> before they go to the fab. Even then it requires several
> iterations to get things right.


Ah, but you're all missing something here in this rant about how bad the state of software development is: These hardware simulation tools are all software! So software isn't such a bad thing after all! ;-)

Nevertheless, I like the premise of this article. I've found that writing unit tests before or in conjunction with writing my classes does a lot more for decoupling the design than simply thinking about how to keep them decoupled does.

Writing with scripting and automation in the plan can have this same effect; which is to say that writing your app so it can be scripted will make it easier to unit test and vice versa.

Having started out in hardware, I'd say that EE is really engineering, whereas software usually isn't. I'm not sure software will ever really be engineering. And I'm not sure that's a bad thing anyway.

Peter Hickman

Posts: 41
Nickname: peterhi
Registered: Mar, 2003

Re: The Bar is Higher Now Posted: Apr 5, 2004 12:30 PM
Reply to this message Reply
> I've found that writing unit tests before or in conjunction
> with writing my classes does a lot more for decoupling the
> design than simply thinking about how to keep them
> decoupled does.

Problem is that you really need to design something that can be tested. I've had to put tests together for something that was not designed or written to be tested. Writing tests then takes a long time and as a result you get pressured to write 'just the important ones'.

Oh yes, a specification would be nice too. None of this 'self documenting code' BS.

Had a day and it's only a monday.

todd hoff

Posts: 22
Nickname: thoff
Registered: Jan, 2004

Re: The Bar is Higher Now Posted: Apr 5, 2004 12:52 PM
Reply to this message Reply
> I was shocked to learn that hardware designers use
> design tools that fully simulate their chip design

I was shocked to see a whole huge team of people hired to
work months and months to test and validate ASICs.
Getting anything added to the ASIC took an act of
congress.

Totally different than software.

Other things that are different...The ASIC won't ever
be made again (most of the time). The ASIC is often not
a FRU. If the ASIC is bad the product is usually
done for. Software ends up making up for a lot of
ASIC problems, often having to go to great lengths.
They would print out their designs on big plotters, we
never do that in software
even though it would help. Hardware people got the
fast good computers.

Jeffrey Fredrick

Posts: 3
Nickname: jtf
Registered: Apr, 2004

peas & carrots, diet & exercise Posted: Apr 5, 2004 3:54 PM
Reply to this message Reply
<p>I think the problem is that while unit testing gets lots of lip service it is still considered something like eating all your peas & carrots, or flossing after every meal, or having a sensible diet and plenty of excercise. Nobody would argue with the premise, but fewer actually follow through.</p>

<p>My friend and co-worker summed it up simply (http://www.developertesting.com/developer_testing/000025.html): "The best way to write testable code is to test it".

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: The Bar is Higher Now Posted: Apr 5, 2004 4:17 PM
Reply to this message Reply
> 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.

What I see is that a lot of people are deployed into critical systems development without sound engineering education. You're suggesting that it's just practice that makes perfect. In fact nothing can make a human's actions perfect. We are imperfect. So, what software design has to include is this basic premise. You have to design into the system that the software might be wrong.

Examples:

The space shuttle system uses voting for control to make sure that everyone agrees. This can be largely considered a hardware validation, but it works for software created error conditions as well. Typically, we think that in such a system that the fact that the software versions are all the same that the same decision would be made. It is not always the case that the software environment will always be sane.

The telephone switching systems continually deal with environmental issues that the developers could not see in their lab environments. So, the software is designed to be able to retreat to a safe spot so that it can continue to function without dehabilitating the entire switch. There are levels of escalation that allow more severe measures to be taken, including the switching of hardware configurations etc.

In todays general purpose servers and desktops, there is no duplicate hardware or other things to switch to. So, all of these hardware management functions are missing in all but the most sophisticated Multi-Processor systems. We also don't usually consider software errors, except in places where the user might lose files they are manipulating.

The development of large scale, for money web services have made this issue more visible to the the masses that haven't had to deal with it. The financial sector, the medical industry and other places were human life and welfare is at risk have been dealing with these issues.

The collapse of the telecommunications industry, and in particular AT&T and Lucent's continued hard times, have put many people on the Market that do know about that industries practices to deal with software reliability.

I'd bet that we'll slowly see better software design over the next decade as old systems are put to rest.

Java provides an opportunity, with checked exceptions to make it apparent to the users of an API of exactly which things might cause the system to stop functioning normally. But, one must remember that RuntimeException's can still occur anywhere, at anytime, and thus you really need to understand how Exception's work in Java (and other languages that support them), and you need to write code that always provides the correct protection of its own lifecycle so that the user can depend on making progress with the application in any case where it would be possible to proceed if the user was in explicit control of every language statement executed.

This can add considerable complexity. But, you can also plan on it up front, and design failure modes into the applications architecture that greatly simplify the impact on the application.

Channing Walton

Posts: 32
Nickname: channing
Registered: May, 2003

Re: The Bar is Higher Now Posted: Apr 6, 2004 2:07 AM
Reply to this message Reply
> What I see is that a lot of people are deployed into
> critical systems development without sound engineering
> education. You're suggesting that it's just practice that
> makes perfect.

:-) I didn't mean to give that impression. In fact its been shown that experience is not a good indicator of ability (if only I could find that paper).

I agree that we're imperfect, which is why I believe in test driven development and all the other practices of agile development. As kent beck once said, "I'm not a great programmer, I'm a pretty good programmer with great habits".

Graham King

Posts: 5
Nickname: grahamking
Registered: Apr, 2004

Re: The Bar is Higher Now Posted: Apr 6, 2004 11:42 PM
Reply to this message Reply
Great article, I found it very inspiring.

Is there any example code out there that you consider good design according to this criteria ? I'm thinking open source projects or personal work you don't mind putting up on the web ?

Thanks.

Channing Walton

Posts: 32
Nickname: channing
Registered: May, 2003

Re: The Bar is Higher Now Posted: Apr 7, 2004 11:51 PM
Reply to this message Reply
How about jHotDraw ? http://www.jhotdraw.org/

Thomas Eyde

Posts: 5
Nickname: teyde
Registered: Apr, 2004

Re: The Bar is Higher Now Posted: Apr 14, 2004 2:35 PM
Reply to this message Reply
I can give you a bad example. What do you think of the User Interface Application Block from Microsoft?

I find it hard to test and hard to extend. Lot's of sealed classes, internal classes, private and static methods. Almost nothing to inherit or overload. Everything is created deep down in the code based on some cofiguration settings.

You can find it at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/uip.asp

bug not

Posts: 41
Nickname: bugmenot
Registered: Jul, 2004

Re: The Bar is Higher Now Posted: Jan 11, 2005 1:50 PM
Reply to this message Reply
todd hoff said:
> It is so much worse than that.

Amen!

Flat View: This topic has 25 replies on 2 pages [ « | 1  2 ]
Topic: Secure Agility/Agile Security Previous Topic   Next Topic Topic: Spoken Log

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use