Programmers and the "Big Picture"?

FirmWarez asks: "I'm an embedded systems engineer. I've designed and programmed industrial, medical, consumer, and aerospace gear. I was engineering manager at a contract design house for a while. The recent thread regarding the probable encryption box of the Columbia brought to mind a long standing question. Do Slashdot readers think that the theories used to teach (and learn) programming lead to programmers that tend to approach problems with a 'black box', or 'virtual machine' mentality without considering the entire system? That, in and of itself, would explain a lot of security issues, as well as things as simple as user interface nightmares. Comments?"

"Back working on my undergrad (computer engineering) I remember getting frustrated at the comp-sci profs that insisted machines were simply 'black boxes' and the underlying hardware need not be a concern of the programmer.

Of course in embedded systems that's not the case. When developing code for a medical device, you've got to understand how the hardware responds to a software crash, etc. A number of Slashdot readers dogmatically responded with "security through obscurity" quotes about the shuttle's missing secret box. While that may have some validity, it does not respect the needs of the entire system, in this case the difficulty of maintaining keys and equipment across a huge network of military equipment, personnel, installations."

Re:Sometimes It's Impossible

[aziegler]

It's not just management. I'm on a contract right now where I've advised that the client do things in particular ways, and the management itself is reasonably amenable to the concept, but the programmer to whom I report is, well, set in her ways.

Developers should know what the big picture is so that they can have a sense of direction in the development process. They don't need to worry abuot it, perhaps, but they should know what it is nonetheless.

-austin

Law of Leaky Abstractions

[Anonymous Coward]

Joel Spolsky says it best in his Law of Leaky Abstractions [joelonsoftware.com]. In other words, no box is totally black.

Hard Software Engineering

[PhaserBlast]

What you are talking about has been a serious concern for a number of researchers. In particular David L. Parnas has been working on this problem for many years now. The basic problem is that software specification often lacks in precision required to make appropriate decisions when writing the software. This is compounded by the lack of precise specification of the OS itself.

Take a look at the CRL, SERG and SQRL reserach documents at

http://www.cas.mcmaster.ca/serg/serg.publications. html

In particular read the CRL Report 241 - "Predicate Logic for Software Engineering" - it covers some of the fundamentals. Then read up on CRL Report 259 "Formal Documentation of Well-structured Programs". There is tons of other interesting reports there that address some aspects of this very issue.

top-down-bottom-up teaching

[Diphthong]

In the lovely concrete blob where I went to college, I think they more or less got it right.

First they teach the basics of programming (variables, environments, scoping, addition, subtraaction, subroutines, etc.) and all of that happy stuff.

Then they teach you how to build a NAND gate using transistors.

Then they teach you how to build a CPU using NAND gates.

Then they teach you how to call subroutines using RAM and registers and pointers and that CPU you just built.

Then they go back to the basics of programming, now that you have a full appreciation for everything that happens when you add two numbers together, and proceed from there into the nether regions of algorithmia.

To me it seems to be a good approach -- it gives you the basic destination first, then it gives you the foundations to get there, and then it goes onwards. It means you've been exposed to every level of what you're working with (to a point -- we never doped silicon to build NAND gates!), so you know what's down there, and you also see the importance of ignoring what's down there when it doesn't matter.

Re:The "Big Picture" is TOO big for most people

[pmz]

When everyone on the project tries to orient their work to what they each perceive as the big picture, you end up with enough different perceptions that people work against each other. Breaking down the system into smaller, more defined, chunks combats that tendency.

This is why good managers are worth their weight in gold. Bad managers are worse than worthless.

Re:Probably (levels)

[oconnorcjo]

Programming Levels:

# Microsoft Frontpage
# Raw HTML
# CGI/PHP/etc.
# Servlets/Mod-perl/etc.
# Object-Oriented black boxes
# Documented API's
# Public Documented API's
# Performance
# "The Big Picture" - Architects

Another elitest post without a real clue. A good programmer knows how to get a job done and should ALWAYS have a big picture view of how things work around them. It does not matter whether they are working on a web site or writing a backend database app or a game engine for the latest and greatest game. Somebody writing good PHP code could probably write good backend C++ code. You are associating the tasks people do with how capable they are. Languages and programs are TOOLS and a programmer should be able to quickly learn to use new tools whether it is a new language, interacting with a new API or using a performance profiler. A good programmer really should not care HOW they get things done- ONLY that they DO get them done.