Course code: WEB-10
  • Years with company: Less than 1
  • Years programming: 15+
  • Primary programming language: C
  • Other programming languages: C++, C#, Python, Ruby, Shell Scripting
  • Unit test harnesses: Ceedling, Nose
  • Something else: I came from a safety critical background out of school, and since testing was required with independance -- software engineers were dissuaded from spending alot of time testing. I have railed against this throughout, as I feel that the benefits to the developer far outweigh the cost. I am suprised that this feeling is not more prevalent in embedded developers that I talk to, but I wonder if it isn't more of an issue of experience and introduction.
  • Test practice now: Unit tests, manual integration tests, a system test group.
  • Target system: Various embedded platforms -- from embedded linux down to tiny bare metal microcontrollers depending on the application.
  • Dev tools: Various - Yocto, Keil, various IDE's provided by chip vendors, various debuggers, etc. Like the target systems -- it depends on the application.
  • Build time: 31-60 seconds
  • Coding standard: Defined and released in our SCM system. Pretty vanilla -- seems to have some parentage from automotive systems (fair amount of MISRA like stuff). Most of the standard is more shoulds than shalls, however, and I haven't seen much review against it.
  • Function too long: At my current company -- no hard and fast rules. I think the code standard provides some weasel wordy style guidance. My personal rule is if it isn't clearly focused on a single 'job' and is trying to do too much -- refactor it.
  • Code reviews: Using a Github style code review during the pull request. Currently no checklists / requirements on the code review. Seem to be taken seriously and done well. Much more focused on functionality than boilerplate.
  • Code time: 60
  • Test time: 20
  • Debug time: 20
  • Favorite thing about dev: I love making things and solving problems, and software is about the most direct analogy to this that I know of. Software is awesome because you can make anything you can imagine -- which is SO COOL.
  • Least favorite thing about dev: Blind hatred or love of 'agile/scrum' while simultaneously misunderstanding it. Monolithic schedules that change all the time. Not wanting to invest to get more efficient or use new tools.
  • Tdd knowledge: I've read most of your book along with other blog posts / online resources. I've been playing with some of the ideas this last 6 months, but not formally as TDD -- more just testing things with automated test.
  • Why are you attending: TDD and unit test applied to embedded systems -- especially mocking and faking. I need more ammunition to convince the organization that 'if we did things a little differently, we could have much better software for not much additional cost.'
  • Back