• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Software by Numbers

 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
the impossibility to build exhaustive test cases for testing 100% of your application -- Valentin
Why do you think this is impossible? -- Ilja
I believe Valentin meant that while it's technically possible to reach 100% unit test coverage, the point of diminishing returns is probably somewhere before that 100%.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
I believe Valentin meant that while it's technically possible to reach 100% unit test coverage, the point of diminishing returns is probably somewhere before that 100%.


Well, ok - but we don't *need* 100% test coverage. What we do need is enough test coverage for 100% of the features that we are confident that they work and will continue to work in the future...
 
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What kind of tools are you thinking of? --Ilja Preuss
That's why I wrote "tools" and not tools. I don't know (yet) how such tools would look like, all I know is that tools are a good way of automating complex tasks and software engineering badly needs them. That's my feeling.
I don't think that will happen in the near future. There are some metrics which can help asses the internal quality, the quality of the "plumbing" of a system, but I don't think that creating a well structured system will be automated anytime soon. --Ilja Preuss
Neither do I. It will take time but we will (have to) achieve that if we want to make our engineering area evolve as did (and still do) other engineering fields.
But as a professional software developer, working with other professionals in a well functioning team, I feel it is my responsibility to care about the "screws and bolts", as well as caring about the functionality of the system. It is a matter of pride. --Ilja Preuss
And I guess this is where we both differ. Personally, as a software developer, I like to care about the business I'm writing the software for and not those boring and ever-recurring mechanical tasks that support the business. As soon as I spend more time dealing with those tasks, I ask myself whether this is the proper way to develop software, and I (almost) always answer no to that question.
[ May 03, 2004: Message edited by: Valentin Crettaz ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Valentin Crettaz:
I don't think that will happen in the near future. There are some metrics which can help asses the internal quality, the quality of the "plumbing" of a system, but I don't think that creating a well structured system will be automated anytime soon. --Ilja Preuss
Neither do I. It will take time but we will (have to) achieve that if we want to make our engineering area evolve as did (and still do) other engineering fields.


What do the solutions to this problems in other engineering areas look like? Aren't they as dependent on caring professionals to define the "high quality plumbings" as we are?
 
Valentin Crettaz
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What do the solutions to this problems in other engineering areas look like? Aren't they as dependent on caring professionals to define the "high quality plumbings" as we are? --Ilja Preuss
They sure are, but they also have machines that help them attain this high quality. I partly regard IDEs and UDEs as a sort of machines software programmers, developers and architect use to build software systems. And what I say is that the *machines* we have today have to evolve quite a bit to achieve the degree of quality we can find in other engineering areas.
Mechanical engineering, for example, has been evolving for thousands of years. In comparison, software engineering (about 60 or so years) looks pretty young to me. Do you think that in 1000 years or even 100 years, people will still dumbly write primitive Java or C# statements in a code editor? I don't think so...
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Valentin Crettaz:
Mechanical engineering, for example, has been evolving for thousands of years. In comparison, software engineering (about 60 or so years) looks pretty young to me. Do you think that in 1000 years or even 100 years, people will still dumbly write primitive Java or C# statements in a code editor? I don't think so...


Mhh, possibly not Java...
On the other hand, I am trained as a precision mechanic. The first 6 (six!) months, we learned how to rasp. And it probably *was* the most important lesson to learn.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic