I am currently a software developer on coop that was in an interesting situation today. I cannot say too much, as the things I do are under NDA, but I make Grasshopper 3D (which is a Rhino plugin) components.

Our firm has under three software developers including me. We all specialize in different languages. This project I was working on, I was in charge of creating a piece of software that has a very broad general use. It's an extension from typical Grasshopper behavior.

With this said, the other developer I worked with has been in this industry for a good... decade or two. He is very knowledgeable towards the use of Grasshopper. His prior education involved great use of it, and his daily work involves the use of Grasshopper (though not explicitly what I am doing, which is creating C# components for it).

With that said, my final component went through a number of iterations. It seemed each iteration was better than the previous. An interesting point is, the other developer I worked with (I was essentially under his wing) manages to break my component every single time. I don't mean this in a malicious way.

By breaking, I meant, he was able to overflow particular lists. He was able to, after almost every iteration, find ways that my component could be improved on. Honestly, I really feel grateful for his suggestions and critique, because these were honestly things that either I overlooked, or did not know could happen.

My question is are three-fold:

  1. Is it normal in software development practices/companies to have someone critique and improve your code? There was no code review. It was simply ways improving the tool through either UX improves or back-end improvements. And honestly, even though there was no code review, I learned so much from his suggestions which I always found success in implementing.

  2. Are there any suggestions for a more "formal" testing procedure? I am relatively new to the software development world, and thus am interested in software dev testing procedures.

  3. How can I improve on my way to "predict" issues?

At one side, I feel like there are issues that I cannot normally find out myself because everyone uses a piece of software differently. On another side, I feel it may be my oversight or incompetence that's causing this.

I'm reading up on this thread, and it seems in a way, we have a loose testing procedure, though it's all dependent on me to ask for critique.

  • 3
    At 1: If your company doesn't do that kind of testing, your customers will. And they will attach much harsher consequences to the problems they find (If it isn't fixed yesterday, they 'vote with their feet'). Commented Feb 5, 2014 at 8:12

2 Answers 2


To improve your ability to predict problems:

  • Look for edge cases. If your function operates on numbers, how does it handle 0? Negative numbers? Very large numbers? If it operates on strings, can it handle an empty string? A string with 10,000 characters? What didn't you expect to happen when you wrote it?
  • Look for problems similar to others that have been found before. You said he was able to overflow particular lists. Be on the lookout for list overflow issues.
  • Look for patterns in the bugs. Is there something in particular that you "always" miss? Then be on the lookout for it.
  • Learn this Grasshopper software you're working on better. Part of the senior developer's ability to see problems may be due to his familiarity with it.
  • Ask the senior developer. As someone with a lot of experience, he probably has good advice about finding bugs and writing code in general, and about Grasshopper specifically.
  1. yes, it's called QA

  2. When anybody discovers a bug, create a test that reproduces it, then fix the code so the test passes. That way, this specific issue should never appear again.

  3. practice, practice, practice.

To reduce your dependency on outside testing, make sure you incorporate as much testing as possible in the coding process itself. Consider every requirement specification as a source of tests. Then write the code to make those tests pass.

  • To iterate on number 2, that's exactly what I do to fix my bugs. I ask the dev to replicate the issue, and through that, I find out what's wrong. What do you do if your requirements are very broad? Commented Feb 5, 2014 at 2:14
  • Keep asking questions of the stakeholders (who gave you the requirements to begin with) to narrow down the exact needs. "Why?" is a perfectly good question to ask, and you can pretty much keep asking it in a loop (though, fair warning: if you literally ask "why" 20 times, every time, it tends to highly annoy most people).
    – gregmac
    Commented Feb 5, 2014 at 3:13
  • I should add that the tests I mention are automated tests, not just replicating the test in development. that's what prevents the issue from ever appearing again.
    – Javier
    Commented Feb 5, 2014 at 7:40
  • I am a bit new to the software engineering world. How exactly are automated unit tests ran? How does the automated unit test press buttons on the screen, for example? Maybe I am misunderstanding it a bit. Commented Feb 5, 2014 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.