Timeline for Is C++ suitable for embedded systems?
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 6, 2018 at 16:07 | history | edited | mike65535 | CC BY-SA 4.0 |
spelling, grammar
|
| Jun 17, 2010 at 19:33 | comment | added | Kortuk | Our requirements are changing on us all the time here, but the systems we spend the most time designing have the fastest coding and maintenance time. We spent a very large amount of time on one subsystem because we know how important it would be in the future and that it would need to change. It is the only subsystem that any changes have been less than a day worth of work on, and it has had many. | |
| Jun 17, 2010 at 19:02 | comment | added | Mark | @sheepsimulator I obviously agree on the second point, I assume the lead system architects are experienced developers. On the first point i actually disagree. I think the more you expect the requirements to change the more time you should spend in the design phase because you need to produce a good, easy to change, design. I know some philosophies propose rapid development. In some cases this works well like lots of bad or inexperienced programmers on staff. All these design philosophies come down to is saying "i have no prayer of designing a flexible system, so lets not waste time trying". | |
| Jun 17, 2010 at 17:57 | comment | added | J. Polfer | @Mark - I agree with your design-up-front sentiments, but only to a point. I think heavy design-up-front works pays off if a) you're requirements are fairly stable/known, and b) the developers doing the design are experienced. In a prev. job, I was tasked with doing a design and it was heavily timeboxed by my team lead, and I thought, "What a dumb thing to do! Design-up-front saves money (cf. Code Complete book)??" But in coding I discovered tons of things I didn't know to look for. If I had done lots of design and minimize code time, it would have been a waste. JME. | |
| Jun 17, 2010 at 4:41 | comment | added | Kortuk | @DoxaLogos, Thanks for the definitions, my company is small, I knew TDD, but that was it. | |
| Jun 17, 2010 at 4:40 | comment | added | Kortuk | @doxalogos, The TDD(Test Driven Development) idea is interesting, but I think it is inherently flawed. I agree 100% with all that you say on it. On the note of unit tests, I have read stories of companies that when implementing a well developed software inspection process they could drop unit tests and save time to release. | |
| Jun 17, 2010 at 4:34 | comment | added | Jay Atkinson | PRD = product requirements document, MRD = marketing requirements document, TRD = technical requirements document. TDD = Test Driven Development. | |
| Jun 17, 2010 at 4:30 | comment | added | Kortuk | @mark, can you define PRD and TRD. | |
| Jun 17, 2010 at 2:40 | history | edited | Mark | CC BY-SA 2.5 |
added 3 characters in body; deleted 1 characters in body
|
| Jun 17, 2010 at 2:38 | comment | added | Mark | @doxalogos err, sorry i've gone and confused TDD with TRD, too many TLA(Three Letter Acronyms) | |
| Jun 17, 2010 at 2:35 | comment | added | Mark | @doxalogos The TDD point is a good one. The one issue i had in my, admittedly limited, experience with companies that force these issues is that they require a TDD but are unwilling to produce a firm PRD. | |
| Jun 17, 2010 at 2:14 | history | edited | Mark | CC BY-SA 2.5 |
deleted 1 characters in body; added 1 characters in body; added 1 characters in body
|
| Jun 17, 2010 at 1:52 | comment | added | Mark | sorry for the epically long rant, i tend to get rather frantic when i see an issue debated heavily when i see it as a simple result of a deeper problem that i think should be the real topic of discussion. | |
| Jun 17, 2010 at 1:21 | comment | added | Jay Atkinson | And to put a final note on my super long comment.. We don't need language experts to work the design. We need expert designers who can work the language(s). | |
| Jun 17, 2010 at 1:13 | comment | added | Jay Atkinson | Now, I'm not knocking unit tests on an application level (above driver) on certain embedded systems. There is some value of the instant feedback of unit-testing and rooting out bugs early in the development phase, but the whole TDD paradigm to give birth to the design seems to me a little braindead. I prefer to take some time to "think" about the problem and diagram it out either in my head, on paper, or on a whiteboard, before starting to code. I also think TDD encourages the market to not do upfront research on requirements, because it's supposed to help with constant requirement change. | |
| Jun 17, 2010 at 1:08 | comment | added | Jay Atkinson | I think you hit the nail on the head with your comment on bending the tool around the problem. It reminds me of the saying, "When all you have is a hammer, everything looks like nail!" Was that a pun?;-) TDD is definitely flies in the face of up front thought, and I don't think I'll ever get comfortable with the idea of making tests to create the design...especially in embedded systems. How in the world can you mock a hardware piece to unit-test a device driver without wasting a lot of time on the mock piece?! | |
| Jun 17, 2010 at 1:00 | comment | added | Kortuk | +1, I enjoyed it, although a bit long. I only use C at work, but I am really trying to move to C++ because there are many bonuses. I have my biases, mostly because of what has gone wrong, or the fact that I have a boss who changes specs within 2 days of telling us what is needed. I am still learning, and I expect to feel that way for about another 4-5 years. I will still learn after that point, but my company does not have a style guide that is followed or an inspection process and I am trying to get both. | |
| Jun 17, 2010 at 0:21 | history | answered | Mark | CC BY-SA 2.5 |