ack! The greatest Linux tool you've never heard of.

If you've done any development on a Linux system, you're probably familiar with grep. Grep is a wonderful tool for searching through files to find a text pattern. Grep is invaluable for finding where certain variables and functions are used throughout code. However, as you may have quickly found out -- you need to tame grep with few command line options. Also, if you're using version control, or have compiled the project, or generated any documentation, you'll want to use find to weed out all the generated files (which also contain the text string you are searching for) and pipe that output into grep.

Fear not! There is a tool that does all this for you, and it's called ack! Ack was designed for programmers, so it only looks through source files and has most of the options you want enabled by default -- greatly reducing the number of keystrokes required for your search. Ack is available on OS X and many Linux distributions, including Ubuntu. Check out the installation instructions from their website. For OS X you will first need the "Homebrew" package manager. Debian based systems (such as Ubuntu) can just use apt-get. Due to legacy issues, ack is called ack-grep on Debian systems. Thus, I would recommend the follow-up modification to change the name to 'ack' on your machine.

OS X Install (Using Homebrew)

Ubuntu (Debian) Install

$ sudo apt-get install ack-grep

Ubuntu (Debian) name change

$ sudo dpkg-divert --local --divert /usr/bin/ack --rename --add /usr/bin/ack-grep
$ sudo cp /usr/share/man/man1/ack-grep.1p.gz /usr/share/man/man1/ack.1p.gz

What are you waiting for?! Go check out the website!

I happened to find this today:  http://www.eschertech.com/articles/index.php

The article that first caught my eye: Can C++ Be Made As Safe As Spark.pdf

Seems rather academic – but it is work in the right direction.  YMMV.

I would like to recommend few tools that we found useful for our documentation.

1) http://www.mcternan.me.uk/mscgen/
2) http://blockdiag.com/en/blockdiag/demo.html
3) http://blockdiag.com/en/seqdiag/demo.html

Tools 1 to 3 are being used along with Doxygen to provide some sequence diagrams or flowchart.

Tool 4 and 5 is used to provide some quick block diagrams or simple schematics - particularly in low layer files.

Hope this might be helpful to few.

Software is by far the most complicated stuff in existence. On top of that it is invisible and defies all intuition except for very few people. Complex programming needs extremely high intelligence and ability to do right.

There are degrees of complexity in any engineering field. Consider short rail bridges over a 20ft streams vs the long multi-lane suspension bridges. The same occurs in software: a simple control task (eg. 8-bit timer in a toaster) vs avionics.

When you take a bridge engineer who is only capable of designing 20ft rail bridges and ask him to design a vehicle bridge over a wide body of water you get Galloping Gerty.

When you take a toaster software engineer and ask him to design a complex system you get Apollo 11 LEM software (which crashed 3 times during the landing sequence), F35 (software still delayed...) or other nightmares.

There are always pressures to pack in more features or shorten deadlines. Since nobody can see software duct tape there's always pressure to take short cuts or gloss over problems rather than fix them immediately. While most people have sufficient understanding of mechanical systems to not use duct tape instead of bolts to hold a bridge together, very few people understand the same with software.

Very, very few people understand software well enough to design it properly. Even fewer people understand software well enough to make the trade offs and compromising needed in all engineering exercises.

It might seem witty do dump on the software engineers, but the reality is that often it would be better to inject software engineers into other areas (mechanical, electrical or O-rings) where engineers are floundering trying to make a solution. I don't suggest that because software engineers have the specific knowledge, but more because software engineers are generally far better at asking probing questions.

I would alter the phrase to read: "Software [design/architecture] is too important to be left to programmers."

I think Jim Berry's comment nails it. Having been in (and out) of the software development community since the late 1950's I've watched the evolution. The juncture that disturbed me most was when (for cost cutting I presume) the position of Systems Analyst was eliminated and that task was relegated to the job title of "Programmer-Analyst." Instead of having subject-matter experts specifying/defining/architecting new software products and supplying their documentation to programmers (coders), companies instead advertise and hopefully hire coders who just happen to also be subject-matter experts in _________ (fill in the blank). Rarely will you find the perfect individual who is a guru in both skills. And, even if you do, there is a built-in conflict of interest. Human nature says that if I'm the guy who has to eventually write the code, that fact is going to greatly influence my (unbiased) ability to specify a really good product that might be much harder to code.

Paul Bennett wrote "This will raise the question why we still have software that is buggy. A lot of it is the current attitudes pervading society. The need for the quick fix, want it now mentality that has been growing more prevalent."

Also the cost to fix a bug. When I was designing logic ICs for IBM in 1975-84, code (and even character generators) were in mask ROM, soldered to the PCB. The cost and turnaround time to fix a bug were huge--more than wiping out the entire profit on a product.

Was the code simulated and thoroughly tested in the lab? You bet it was, just as thoroughly as the logic chips. Very rare for a bug to escape. Now, of course, with flash memory and USB ports, as soon as it barely works, it's shipped. The consumer is expected to visit the internet to get and install the fixed code. (Can your grandmother do that?)

(As an aside, I do remember two character generator bugs. In one case the programmer was doing a German character generator. He was told to place "Double-S" at particular address. He inserted the section symbol, §, but it was supposed to have been the German glyph "ß" that replaces two sequential "s" characters. Fortunately it was caught in test although delay getting the correct mask ROMs held up shipment. How's your Yiddish? I have a Bißel.)

Jim Berry wrote "The unique characteristic of software engineering is that we are able to build our own designs through programming without the necessity of representing the design in a human-readable fashion to be handed off to a separate person for fabrication. That is a mixed blessing."

He's describing a flawed process. It IBM we distinguished "Software Architects" from "Coders." Jim may be talking about small shops or small projects (we had those too), but if you don't have design before implementation, no one knows what he is supposed to do. Since we're doing analogies here, do you think Bush or Obama writes his own speeches? No way. He discusses or sketches an outline of points to make, and maybe a preferred order and hands off to a speech-writer. You're in Boston, right? How about this: Seven books on speechwriters - The Boston Globe

This example of lots of indirection is a silly one (though technically valid) for multiple reasons:
- the names are meaningless, unless this is a summary of a soap opera, in which case it's still mostly meaningless
- no apparent reason for the indirection, particularly the multiple levels.

I just put something together in which there's a linked list of Active Device Blocks (one path of indirection), each of which points to (among other things) a Device Descriptor Block for the type of device it is (could be multiple active devices of the same type) and two different pools of buffers. The Device Descriptor blocks, in turn, point to three different types of attribute-description records (all consts) that can have variable numbers per device.

One could complain about the indirection, and duplicate more RAM (instead of ROM), copy things around that should always be the same (but now you have to worry about whether they really ARE the same, and remain the same), make unique copies of things that should be abstracted instances, and generally waste resources. Or you can have a system that SOUNDS complex in the abstract but is really no more complex than the average laundromat: "OK, we have 10 washers, 5 of this type and 3 of that type and 2 extra-large, and we have a single copy of the manual for each type in the drawer, and all of the coin mechanisms are the same type and one copy of THAT manual is in the drawer too . . . "

Maybe the problem is the perennial HW/SW divide. Hardware designers need to instantiate things; software designers are taught to abstract and commoditize things. Hardware designers think that separate ports need all separate registers with all separate names; software designers think that the separate ports should all be INSTANCES of a common STRUCTURE. Of course, an older generation of hardware designers that designed and used external UART and DMA chips thought that way too, because they were instantiating instances of a common structure; but the new generation has forgotten again, as if being on-chip confuses the issue.