Author Topic: Software design book recommendations  (Read 3954 times)

0 Members and 1 Guest are viewing this topic.

Offline genericpurpleturtleTopic starter

  • Contributor
  • Posts: 13
  • Country: gb
Software design book recommendations
« on: August 06, 2018, 10:07:54 am »
Hello all! First of all I apologise if this isn't quite in the right subsection of the forum, I didn't really know where it should go and this seemed the most fitting.

I am a junior embedded software engineer and at work we have some extra money in the "consumables" budget and it has been suggested that it be spent on books. As well as getting the newest edition of the Art of Electronics by Horowitz, I was thinking it may be worth also getting some books on software design. I did Electronics at university and we hardly did any programming and any programming I have done has been mostly self taught and as such I do not doubt that I have a lot of bad habits in the way I structure my code, so a book that covers good design principles for C I think would be helpful.

I've found a book on C compilers called Advanced C and C++ Compiling by Stevanovic, which I may purchase as I think I could definitely develop my understanding of whole compilers work also. If anyone has any other book recommendations of this nature, or essentially any aspect of embedded software engineering or even software engineering more generally it would be most helpful.

Cheers!
 

Offline vidi

  • Contributor
  • Posts: 24
  • Country: sk
Re: Software design book recommendations
« Reply #1 on: August 06, 2018, 01:28:21 pm »
1. Clean code by Robert C. Martin
The examples are dedicated to Java, but the same principles/rules can be applied also on application in embedded programming (unless you want to do some really low level stuff like kernel optimization, DMA drivers, ...)

2. Design Patterns: Elements of Reusable Object-Oriented Software
Might be obsolete these days, but it was really handy to understand high abstraction levels.

3. Modern C++ Design by Andrei Alexandrescu
Dedicated to uncommon C++ techniques and hidden features, mainly related to meta programming. It is also quite old now.

4. Art of computer programming by Knuth.
Bible of algorithm analysis.

« Last Edit: August 06, 2018, 05:44:42 pm by vidi »
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Software design book recommendations
« Reply #2 on: August 06, 2018, 02:38:40 pm »
Writing Solid Code, Microsoft Techniques
It shows interesting points
 

Offline mac.6

  • Regular Contributor
  • *
  • Posts: 225
  • Country: fr
Re: Software design book recommendations
« Reply #3 on: August 06, 2018, 07:02:16 pm »
Mastering regular expressions
http://shop.oreilly.com/product/9780596528126.do

Not directly related to embedded sw, but a must for dev tasks, especially when you do not spend time doing regexp
 

Offline Dielectric

  • Regular Contributor
  • *
  • Posts: 127
  • Country: 00
Re: Software design book recommendations
« Reply #4 on: August 06, 2018, 07:10:56 pm »
If you're relatively new, Elecia White's book would be good:
http://shop.oreilly.com/product/0636920017776.do
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: Software design book recommendations
« Reply #5 on: August 07, 2018, 03:29:53 am »
A great book about embedded projects is Better Embedded System Software by Philip Koopman.

It's not really about programming, but has tons of insights and suggestions about embedded projects and what makes the good ones go smoothly.
 

Offline agehall

  • Frequent Contributor
  • **
  • Posts: 381
  • Country: se
Re: Software design book recommendations
« Reply #6 on: August 07, 2018, 10:39:25 am »
Mastering regular expressions
http://shop.oreilly.com/product/9780596528126.do

Not directly related to embedded sw, but a must for dev tasks, especially when you do not spend time doing regexp
OT: RegExps should die. Period. They are the horror of all code and the cause of many many many problems. I know several languages encourage the use of them but honestly, the number of times I've actually had to resort to RegExps can be counted on the fingers of my hands. There are usually much better ways of solving problems.
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: Software design book recommendations
« Reply #7 on: August 07, 2018, 11:38:41 am »
Mastering regular expressions
http://shop.oreilly.com/product/9780596528126.do

Not directly related to embedded sw, but a must for dev tasks, especially when you do not spend time doing regexp
OT: RegExps should die. Period. They are the horror of all code and the cause of many many many problems. I know several languages encourage the use of them but honestly, the number of times I've actually had to resort to RegExps can be counted on the fingers of my hands. There are usually much better ways of solving problems.

Regexp syntax is quite horrifying and errorprone, and getting the expression right will take some iteration and testing. Maintaining the regexp expressions is not for faint hearted either. There is nothing wrong with the regular expressions per se, as they are very powerful tool in right hands.
 

Offline Doctorandus_P

  • Super Contributor
  • ***
  • Posts: 3321
  • Country: nl
Re: Software design book recommendations
« Reply #8 on: August 09, 2018, 11:59:29 am »
I think that people who are interested in writing good / decent code already write a lot better code than the people who do not even think about code quality, so kudo's for the interest in this topic.
I once wasted a few hours analizing the initialisaton routines of a small uC  divided over a lot of functions  which essentially did almost nothing, and should have been 10 or so straight forward lines of code.

Basic code design principles are partly agnostic of the programming language used, but it still helps if you study a book for the same programming language you're interested in. I know some  C ( and a bit less fluently with C++). With C++ you can & should initialize data in the constructor of a class, while in C classes don't exist and stuff is initialized where declared, or in a separate function.

Therefore  my choice for book suggestions would be from the books recommended by the C++ standards committee:
[url][https://isocpp.org/search/google?q=book/url]
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: Software design book recommendations
« Reply #9 on: August 09, 2018, 01:54:49 pm »
I have found the following books quite useful for embedded systems design and implementation:

Patterns for Time-Triggered Embedded Systems by Michael J. Pont:
https://www.safetty.net/publications/pttes

Never mind if the book is not targeted your particular microcontroller. The patterns are the meat of the book.

Test Driven Development for Embedded C (Pragmatic Programmers):
https://www.amazon.com/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X

Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems
https://www.amazon.com/Practical-UML-Statecharts-Event-Driven-Programming/dp/0750687061

Somewhat useful stuff also in here:

Making Embedded Systems: Design Patterns for Great Software
https://www.amazon.com/Making-Embedded-Systems-Patterns-Software/dp/1449302149
 

Offline Leiothrix

  • Regular Contributor
  • *
  • Posts: 104
  • Country: au
Re: Software design book recommendations
« Reply #10 on: August 10, 2018, 03:28:53 am »
OT: RegExps should die. Period. They are the horror of all code and the cause of many many many problems. I know several languages encourage the use of them but honestly, the number of times I've actually had to resort to RegExps can be counted on the fingers of my hands. There are usually much better ways of solving problems.

Regexs are the best way of doing the things that regexs do.  If you haven't had the need to use them that means probably haven't had to do much in the way of string processing.

Edit:  I'm talking about full-size computers here, embedded is different, especially the smaller devices.
« Last Edit: August 10, 2018, 03:47:55 am by Leiothrix »
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: Software design book recommendations
« Reply #11 on: August 10, 2018, 03:38:50 am »
"Head First - Design Patterns"

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Software design book recommendations
« Reply #12 on: August 10, 2018, 05:47:02 am »
1. Clean code by Robert C. Martin
The examples are dedicated to Java, but the same principles/rules can be applied also on application in embedded programming (unless you want to do some really low level stuff like kernel optimization, DMA drivers, ...)
It's not specifically only java. It's object oriented programming. I read it last month, SOLID book, can definitely recommended.

The thing is, you can read these architecture books by software guru's but they will go against each other on several fronts. Don't use them as bible. Use then for inspiration.
 

Offline Richard Crowley

  • Super Contributor
  • ***
  • Posts: 4317
  • Country: us
  • KJ7YLK
Re: Software design book recommendations
« Reply #13 on: August 10, 2018, 06:36:22 am »
The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks Jr.

Mr. Brooks was the project manager for the landmark IBM System/360 computer family and then for its massive operating system: OS/360.

Key things that have been of benefit to me for 30 years include:

Brooks' Law: "Adding manpower to a late software project makes it later."

The "Second System Effect" where you commonly over-engineer the system.  Some recommend simply throwing out Rev.2 altogether.

The "Surgical Team" of seven key members (ideally individuals) of a development team. Alas, I usually work on projects where I am all (or most) of these seven roles.  Nevertheless, it is good to remember the division of labor and different expertise and contributions to the project.

The full text of the book is available online at:
https://archive.org/stream/mythicalmanmonth00fred/mythicalmanmonth00fred_djvu.txt

And a good summary at: https://en.wikipedia.org/wiki/The_Mythical_Man-Month
 
The following users thanked this post: nugglix

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: Software design book recommendations
« Reply #14 on: August 10, 2018, 09:41:45 am »
1. Clean code by Robert C. Martin

I read that book and didn't like it. It's more of a fashion title, I guess, because some advises are straight wrong IMO, like e.g. "don't comment your code" - which is a very bad idea. Not all code is obvious, or self explanatory, by classes' names.

Anyway, if you want to know the rules that book is pleading for, you don't need to read the whole book. It will be a waste of time. There is a page (or a very small chapter - I don't recall exactly) at the end of that book, where all the rules are simply enumerated. The name of each rule is self-explanatory, but don't follow them blindly. Some of them doesn't always makes sense.

Read only that page/chapter, and you'll know it all.

Offline genericpurpleturtleTopic starter

  • Contributor
  • Posts: 13
  • Country: gb
Re: Software design book recommendations
« Reply #15 on: August 10, 2018, 03:43:40 pm »
1. Clean code by Robert C. Martin

I read that book and didn't like it. It's more of a fashion title, I guess, because some advises are straight wrong IMO, like e.g. "don't comment your code" - which is a very bad idea. Not all code is obvious, or self explanatory, by classes' names.

Anyway, if you want to know the rules that book is pleading for, you don't need to read the whole book. It will be a waste of time. There is a page (or a very small chapter - I don't recall exactly) at the end of that book, where all the rules are simply enumerated. The name of each rule is self-explanatory, but don't follow them blindly. Some of them doesn't always makes sense.

Read only that page/chapter, and you'll know it all.

Yeah refusing to comment code is a pretty silly practice. Thanks for the warning.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Software design book recommendations
« Reply #16 on: August 10, 2018, 04:56:58 pm »
Yeah refusing to comment code is a pretty silly practice. Thanks for the warning.

Most "advisers" would recommend heavy commenting beyond reason. To the point that there are people who believe that "proper" commenting is more important than the code itself. When someone recommends less comments, it's rather refreshing.
« Last Edit: August 10, 2018, 05:21:00 pm by NorthGuy »
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Software design book recommendations
« Reply #17 on: August 10, 2018, 05:04:28 pm »
You have to wonder how much time these 'gurus' spend actually doing real development and programming as they appear to have full time careers writing, consulting and promoting their pet analysis/design/programming systems.
 
The following users thanked this post: nugglix

Offline nfmax

  • Super Contributor
  • ***
  • Posts: 1556
  • Country: gb
Re: Software design book recommendations
« Reply #18 on: August 10, 2018, 05:23:19 pm »
Here's a couple to look at:

Henry Ledgard, Professional Software, Addison-Wesley 1987
Volume I - Software Engineering Concepts, ISBN 0-201-12231-6
Volume II - Programming Practice, ISBN 0-201-12232-4

Ledgard was one of the designers of MULTICS. The emphasis is on software quality & professionalism. Quite thin, but every page is worth study.

Brian W. Kernighan & Rob Pike, The Practice of Programming, Addison-Wesley 1999, ISBN 0-201-61586-X

Oddly enough, this feels a bit more dated now than Ledgard, but it has some good stuff.

 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Software design book recommendations
« Reply #19 on: August 10, 2018, 06:49:37 pm »
Yeah refusing to comment code is a pretty silly practice. Thanks for the warning.

Most "advisers" would recommend heavy commenting beyond reason. To the point that there are people who believe that "proper" commenting is more important than the code itself. When someone recommends less comments, it's rather refreshing.

The code itself tells the reader what it is doing. The name of a variable or signal tell the reader its purpose.

Comments tell the reader why the code was written as it was, especially if the why is non-obvious.
 
The following users thanked this post: Jeroen3, Richard Crowley

Offline genericpurpleturtleTopic starter

  • Contributor
  • Posts: 13
  • Country: gb
Re: Software design book recommendations
« Reply #20 on: August 14, 2018, 09:23:01 am »
Okay so this is the complete list of books we purchased. Any more recommendations would still be welcome, for anyone stumbling across this thread in the future. Thank you to everyone who recommended stuff. Who knows when they'll get read, but when they do, I'll try to let you guys know how useful I found them.

Advanced C and C++ Compiling

Test Driven Development for Embedded C

Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems
   
Making Embedded Systems: Design Patterns for Great Software

The Art of Computer Programming Volume 1: Fundamental Algorithms

Modern C++ Design: Generic Programming and Design Patterns Applied

We also got some electronics ones too.

The Art of Electronics

Microelectronic Circuits: Theory and Application

Practical Electronics for Inventors
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: Software design book recommendations
« Reply #21 on: August 14, 2018, 09:54:32 am »
Beware of TDD cult, either! (Test Driven Development)

In theory, it should work very well, it seems to make sense, and it's seductive. In practice, you'll end up spending most of the time maintaining the tests and the testing infrastructure, instead of actually developing your product.

There might be situations where TDD becomes advantageous, I don't know, but in my experience it was the other way around: Overall, TDD was a major drawback and a huge time sink with no visible advantages.

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Software design book recommendations
« Reply #22 on: August 14, 2018, 11:24:38 am »
In practice, you'll end up spending most of the time maintaining the tests and the testing infrastructure, instead of actually developing your product.
Isn't that the entire point of TDD?
 

Offline vidi

  • Contributor
  • Posts: 24
  • Country: sk
Re: Software design book recommendations
« Reply #23 on: August 14, 2018, 03:54:47 pm »
Quote
I read that book and didn't like it. It's more of a fashion title, I guess, because some advises are straight wrong IMO, like e.g. "don't comment your code" - which is a very bad idea. Not all code is obvious, or self explanatory, by classes' names.

You are taking "don't comment your code" out of context. This rule is tied with "a function do just one job" and "keep your functions small". By my C# lecturer, function should has no more than 15 lines of code - otherwise the design is wrong. So, right question to ask is - Cannot be a single purpose function, 15 lines max, written the way that you know what does it do on first sight ?

Obviously this rule does not make sense in area of cryptography, hard-core math algorithms, black-magic hardware workarounds, compiler optimization, ...
but it does for cca 95% of common code.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: Software design book recommendations
« Reply #24 on: August 14, 2018, 05:11:44 pm »
By my C# lecturer, function should has no more than 15 lines of code - otherwise the design is wrong.
That's kind of a silly "rule" too, but the intent is reasonable. Another way to think about how to decompose your problem into smaller functions is to consider how you'll test the code. You do test, right?  >:D

If a chunk of code is doing all kinds of different things, writing a test harness for it will be a lot of work. But if your code really is a function in the math sense, it will probably have only a few lines and be easy to test.

The codebase I'm working with now has a couple of C functions that are 1000+ lines of source. One of them compiles into about 17k of machine code.  :o  |O  :wtf:
 

Offline Richard Crowley

  • Super Contributor
  • ***
  • Posts: 4317
  • Country: us
  • KJ7YLK
Re: Software design book recommendations
« Reply #25 on: August 14, 2018, 05:56:09 pm »
In practice, you'll end up spending most of the time maintaining the tests and the testing infrastructure, instead of actually developing your product.


Not a support of TDD, but it reminds me of the "Surgical Team" in Brooks: Mythical Man-Month  In that book he outlines this concept attributed to Marlan Mills:

Quote
A proposal by Harlan Mills offers a fresh and creative solution.  Mills proposes that each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.

A little thought shows that this concept meets the desiderata, if it can be made to work. Few minds are involved in design and construction, yet many hands are brought to bear. Can it work? Who are the anesthesiologists and nurses on a programming team, and how is the work divided? Let me freely mix metaphors to suggest how such a team might work if enlarged to include all conceivable support.

The surgeon. Mills calls him a chief programmer. He personally defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation. He writes in a structured programming language such as PL/I, and has effective access to a computing system which not only runs his tests but also stores the various versions of his programs, allows easy file updating, and provides text editing for his documentation. He needs great talent, ten years experience, and considerable systems and application knowledge, whether in applied mathematics, business data handling, or whatever.

The copilot. He is the alter ego of the surgeon, able to do any part of the job, but is less experienced. His main function is to share in the design as a thinker, discussant, and evaluator. The surgeon tries ideas on him, but is not bound by his advice. The copilot often represents his team in discussions of function and interface with other teams. He knows all the code intimately. He researches alternative design strategies. He obviously serves as insurance against disaster to the surgeon. He may even write code, but he is not responsible for any part of the code.

The administrator. The surgeon is boss, and he must have the last word on personnel, raises, space, and so on, but he must spend almost none of his time on these matters. Thus he needs a professional administrator who handles money, people, space, and machines, and who interfaces with the administrative machinery of the rest of the organization. Baker suggests that the administrator has a full-time job only if the project has substantial legal, contractual, reporting, or financial requirements because of the user-producer relationship. Otherwise, one administrator can serve two teams.

The editor. The surgeon is responsible for generating the documentation — for maximum clarity he must write it. This is true of both external and internal descriptions. The editor, however, takes the draft or dictated manuscript produced by the surgeon and criticizes it, reworks it, provides it with references and bibliography, nurses it through several versions, and oversees the mechanics of production.

Two secretaries. The administrator and the editor will each need a secretary; the administrator's secretary will handle project correspondence and non-product files.

The program clerk. He is responsible for maintaining all the technical records of the team in a programming-product library. The clerk is trained as a secretary and has responsibility for both machine-readable and human-readable files.

All computer input goes to the clerk, who logs and keys it if required. The output listings go back to him to be filed and indexed. The most recent runs of any model are kept in a status notebook; all previous ones are filed in a chronological archive.

Absolutely vital to Mills's concept is the transformation of programming "from private art to public practice" by making all the computer runs visible to all team members and identifying all programs and data as team property, not private property.

The specialized function of the program clerk relieves programmers of clerical chores, systematizes and ensures proper performance of those oft-neglected chores, and enhances the team's most valuable asset — its work-product. Clearly the concept as set forth above assumes batch runs. When interactive terminals are used, particularly those with no hard-copy output, the program clerk's functions do not diminish, but they change. Now he logs all updates of team program copies from private working copies, still handles all batch runs, and uses his own interactive facility to control the integrity and availability of the growing product.

The toolsmith. File-editing, text-editing, and interactive debugging services are now readily available, so that a team will rarely need its own machine and machine-operating crew. But these services must be available with unquestionably satisfactory response and reliability; and the surgeon must be sole judge of the adequacy of the service available to him. He needs a toolsmith, responsible for ensuring this adequacy of the basic service and for constructing, maintaining, and upgrading special tools — mostly interactive computer services — needed by his team. Each team will need its own toolsmith, regardless of the excellence and reliability of any centrally provided service, for his job is to see to the tools needed or wanted by his surgeon, without regard to any other team's needs. The tool-builder will often construct specialized utilities, catalogued procedures, macro libraries.

The tester. The surgeon will need a bank of suitable test cases for testing pieces of his work as he writes it, and then for testing the whole thing. The tester is therefore both an adversary who devises system test cases from the functional specs, and an assistant who devises test data for the day-by-day debugging. He would also plan testing sequences and set up the scaffolding required for component tests.

The language lawyer. By the time Algol came along, people began to recognize that most computer installations have one or two people who delight in mastery of the intricacies of a programming language. And these experts turn out to be very useful and very widely consulted. The talent here is rather different from that of the surgeon, who is primarily a system designer and who thinks representations. The language lawyer can find a neat and efficient way to use the language to do difficult, obscure, or tricky things. Often he will need to do small studies (two or three days) on good technique. One language lawyer can service two or three surgeons.

This, then, is how 10 people might contribute in well-differentiated and specialized roles on a programming team built on the surgical model.


That was back several decades ago and the roles of secretaries and program clerks and even editor have been automated in the form of word processing, spell (and grammar) checking, version management systems, etc.

But the recognition of specialty people (or at least identifable tasks) like Toolsmith, Tester, and Language Lawyer have continued to be valuable concepts in my career.
 

Offline nfmax

  • Super Contributor
  • ***
  • Posts: 1556
  • Country: gb
Re: Software design book recommendations
« Reply #26 on: August 14, 2018, 06:03:38 pm »
Note the tester writes the specifications for the tests based on the Chief Programmer's (edited) documentation. This ensures the documentation is tested too.
 
The following users thanked this post: Richard Crowley


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf