Jeremy Bennett

image
Embedded Software Engineer

Biography has not been added

jeremybennett

's contributions
Articles
Comments
Discussions
    • I can confirm this is an excellent beginner's board for kids, becauses of the simple way they can take cookbook code and modify it. We've got a couple at home, and my 12 & 13 year olds picked them up and just got going with them (they were 10 & 11 when they started). I believe if you are fortunate enough to attend school near Cambridge, ARM engineers will turn up on a Wednesday afternoon with a suitcase of mbeds for your after school computer club. 10 minutes to show the children how to plug it in and fire up the IDE, then they leave them to get on with it. Reportedly immensely popular with the youngsters from talking to parents. Too bad my children are at school in Hampshire!

    • Jack. Succinct explanation - thanks, In Europe we don't have software patents. At least in theory (and large corporations are lobbying hard to change that). A patent is a limited term monopoly, and as such a distortion of the market. Too bad Thomas Jefferson didn't get his way with the Bill of Rights. They were conceived to allow the inventor to recoup the costs of development. But the fees and time involved now mean they are just used by big corporations to fight each other (think Google v Oracle over Java/Android) and to shut out small competitors. You can argue the case for a pharmaceutical company who has spent billions and decades developing a drug to deal with feline incontinence. But is makes no sense for software, where compared to patenting, the cost of equipment and the relatively short timescales developing software that gets patented is trivial. Let software continue to rely on copyright. That is something far more appropriate to the creative nature of programming. It has proved itself over the years and is free. Not what large corporations want to hear - it levels the field for the little guy. But the patent system should not be about allowing the big guys to hold on to monopolies.

    • Good article, but code inspections are just one tool in the armoury. The problem is that good code inspection is phenomenally resource intensive and very tedious. The latter is the killer - software engineers are human beings, and there's only so much tedium you can force them through. My experience is that they can only be used sparingly - which means inevitably AFTER a crisis - thereby negating the point of designing quality in. A technique that does work is buddy programming - effectively code inspection on-the-fly. That too is very demanding (I tend to believe the statistics that 5 hours/day is the most anyone can take), but it does produce very good code. Trouble is only a relatively small proportion of programmers are temperamentally suited to buddy programming. So in practice we fall back on the one technique that seems to work, which is to write the tests before the code. That's a task where the reviewing process is tractable. Combined with tracking tools like Bugzilla, a rigorous regression testing environment (tools like DejaGNU can help), and a strict requirement that the tester and coder are different people, this can deliver good code efficiently. It has the added merit that there are at least two engineers who understand every part of the code. Essential protection against one being run over by a bus (or just getting a new job). This is not new or rocket science. The basic idea is in "The Mythical Man-Month" (Fred Brooks Jr, 1975), based on experience of software engineering in the 1960s. It's taught in every University program. Yet I am always amazed at how many organizations get this basic software engineering wrong. Jeremy

    • I've worked on modeling SoC, and writing compilers and debuggers for years, so understanding assembler is my bread and butter. I was dismayed to find from talking to students at our local university that in their 4 year software engineering course they study only one language, Java. No study of other languages - even to understand the possibilites - and NO ASSEMBLER. I then spoke with a professor of information technology at one of the UK's major universities, and discovered they have also now dropped assembler. I sense that computer science is splitting into two subjects. The first is producing high level application programmers, who know Java, UML and the web. The second producing firmware engineers who know about C, assembler and actual hardware. Perhaps these reflect departments that have historically grown respectively out of maths and EE. Maybe I shouldn't be concerned. Engineers like me who are fluent in UML and Java, but also code assembler and can understand Verilog are becoming a rarity, so I'll be more valuable. On the other hand in a world where 99% of all CPU's sold are embedded, I can't help feeling we're heading in the wrong direction. Jeremy

    • I can see there's a theme developing here... The key thing about Open Source is that is free in the sense of "freedom", not necessarily free in the sense of "no money". That's the crucial difference - open source stops supplier lock in. I'll quite likely pay you to support your open source software (think Red Hat, IBM, CodeSourcery, to choose a few at random). But if you don't deliver good value, I can take the source code to someone else to support, or just do it myself. Ultimately its just a change of business model from product funded to service funded, but since service businesses have a lower cost of entry (the development is amortized across the OSS community), it makes a more effective (liquid) market, ultimately to the benefit of the end user. So my prediction is that 2028 all major software will be open source, with software revenues largely on a service business. This will be partly facilitated by the demise of the patent system, at least as it applies to software. This change will occur in response to the abuse of this legalized monopoly by patent trolls and large companies, suffocating innovation by small companies. Jeremy

    • I can see there's a theme developing here... The key thing about Open Source is that is free in the sense of "freedom", not necessarily free in the sense of "no money". That's the crucial difference - open source stops supplier lock in. I'll quite likely pay you to support your open source software (think Red Hat, IBM, CodeSourcery, to choose a few at random). But if you don't deliver good value, I can take the source code to someone else to support, or just do it myself. Ultimately its just a change of business model from product funded to service funded, but since service businesses have a lower cost of entry (the development is amortized across the OSS community), it makes a more effective (liquid) market, ultimately to the benefit of the end user. So my prediction is that 2028 all major software will be open source, with software revenues largely on a service business. This will be partly facilitated by the demise of the patent system, at least as it applies to software. This change will occur in response to the abuse of this legalized monopoly by patent trolls and large companies, suffocating innovation by small companies. Jeremy