The following links were published in the March 2011 ACM SIGSOFT Software Engineering Notes in the "Surfing the Net for Software Engineering Notes" by Mark Doernhoefer. This issues topic was interfaces.
Software Engineering Gap - lots of work on platforms and compilers, lots of work on apps. Middle (build systems, etc.) is often ignored (reach good enough and then move on)
Common Build System Issues - Incorrect, Slow, Cumbersome, Under-maintained
Why Build Systems Matter - Engineer Productivity, All about feedback
The Challenge At Google - 6000 engineers and one code base, everything built from source, development on mainline, extensive automated testing
Rough Developer Workflow (flow chart)
Better Build System Needed - optimized and tuned build languages, dependency analysis and scheduling, leverage infrastructure. Must be correct AND fast.
Inputs, Outputs and Actions - Content addressable storage (by digest of content), use relative paths, eliminate global state
Scaling Source Code Access - FUSE based file system. Most code needed for read only, on-demand syncing and caching, all source in the cloud, content digests as metadata
Making Builds Fast - Distributed builds in the cloud - built in arbitrary location
Scalable Distributed Builds - Caching key to scalable build. If inputs (from digest) and actions are same as previous, return prior result.
Scaling Build Outputs - FUSE based file systems, all output in the cloud, shared across builds and users
System View - builds appear local but are in the cloud
Platform for Automated Testing - Executing a test is just another build action.
Results - 20+ code changes per minute, 65K builds per day, 10000 CPUs, 50 TB memory, ~1PB output every 7 days, 94% cache hit rate.
Estimating build tool savings 2008 to 2009: Saving ~600 person years
Conclusion: build system is a core component of software engineering
I was reading an article when I saw a reference to how NASA’s Jet Propulsion Laboratory (JPL) was using 10 simple coding guideline to develop safe code. The article referenced the following URL: http://spinroot.com/p10/. Going to this site, you will discover that the work was originally published in the June 2006 issue of IEEE Computer in The Power of Ten – Rules for Developing Safety Critical Code by Gerard J. Holzmann.
The paper and site describes 10 rules:
Restrict to simple control flow constructs.
Give all loops a fixed upper-bound.
Do not use dynamic memory allocation after initialization.
Limit functions to no more than 60 lines of text.
Use minimally two assertions per function on average.
Declare data objects at the smallest possible level of scope.
Check the return value of non-void functions, and check the validity of function parameters.
Limit the use of the preprocessor to file inclusion and simple macros.
Limit the use of pointers. Use no more than two levels of dereferencing per expression.
Compile with all warnings enabled, and use one or more source code analyzers.
The following links were published in the November 2010 ACM SIGSOFT Software Engineering Notes in the "Surfing the Net for Software Engineering Notes" by Mark Doernhoefer. This issues topic was software estimation.
The following links were published in the September 2010 ACM SIGSOFT Software Engineering Notes in the "Surfing the Net for Software Engineering Notes" by Mark Doernhoefer. This issues topic was mobile devices.
The following links were published in the July 2010 ACM SIGSOFT Software Engineering Notes in the "Surfing the Net for Software Engineering Notes" by Mark Doernhoefer. This issues topic was Multicore and Multithreaded Programming.
This post is meant to capture Robert Martin’s S.O.L.I.D. principles (see The Principles of OOD for one of Martin’s original presentation of these items) and some related links. S.O.L.I.D. is an acronym of design principles for object oriented development.
Jason Baker wrote Myths About Code Comments. I like posts like this - they get me thinking about the assumptions I make in my day to day work.
In short, Jason says the following are myths:
Comments are free
Comments make code more readable
You should comment every function, method, class, and module
Code must always be "self documenting"
In particular, I think the first and second points are intimately related. Anything that goes into a product - documentation, code, comments, tests, etc. - is never free. Anything that goes into a product incurs not only the cost of initially creating but also the ongoing cost to keep up to date. If you avoid the ongoing cost by not keeping all items up to date, the result is that the code and the supplementary material diverge - which leads to the myth that comments make code more readable.
One of the things I love is being able to see presentations from conferences I was unable to attend. A coworker passed on a link to this video (55 minutes) from the Business of Software conference. In the talk, Jason Fried of 37Signals, makes of Ruby on Rails and Basecamp, speaks on many aspects of running a software company and keeping teams working effectively.
Here are some of the slide titles, topics and items Jason discussed:
Planning is vastly overrated - no roadmaps, specifications, projections. Get rid of distractions. Functional specification does not reflect reality and leads to an illusion of agreement.
Decisions are temporary - optimize for now
Red flag words - need, can’t, easy, everybody, nobody. These are the words that cause projects to be late
Interruption is the enemy of productivity - the closer the team is physically, the less you get done. Interruption is not collaboration. A fragmented day is not a productive day.
Underdoing - target non-consumption
Find the right size - imagine the software as a physical item
Follow the chefs - what is your cookbook?
Always be questioning - Why are we doing this? What problem are we solving? Is this actually useful? Are we adding value? Will this change behavior? Is there an easier way?
Give up on hard problems - there is an abundance of easy problems
You’re an editor - Curate your product. Say no to more things than you say yes.
Work Less
Q&A - Starts 28 minutes into the video
An enjoyable video, especially the first half before the Q&A session.