Structured Programming Environment

Question

A frequent question I get during an interview is whether I'm a lone programmer who shoots from the hip or whether I like a structured work environment. I think I'd prefer a structured work environment, but my jobs thus far have been under a non-technical boss who gives me a vague requirement and modifies the project ad hoc. So I guess I'm wondering, what does a truly structured programming environment look like? Things I'm interested in is how frequently does code review occur, how detailed is the technical specs, what's the optimal distribution of labor, something like this.

Answer 1

Unfortunately, the answer is:

It depends.

Nobody really knows what a structured environment is because everybody has their own definition. There are lots of competing processes, each with their own specification of how to do X (or how to avoid doing it, in some processes).

Answer 2

For the most part I don't work in a structured environment, but some of the things that people talk about that sound like "structure" to me include:

• formal code review
• formally enforced code formatting and naming conventions
• multi-stage procedures for checking in code
• use of VCS locking to insure that only one person is working on a particular file at a time
• formal methods for correctness
• lots of meeting
• waterfall design strategy
• a set of training exercises to be completed before you ever get access to the real code to insure that new programmers know The System
• a mentoring arrangement for the first N months of your time with the team during which your mentor has veto power over your proposed patches
• ...

Answer 3

I will interpret your question as "how do I respond to this interview question?", which makes it on-topic for SO.

Structured means rules are in place. Rules are put in place to achieve certain goals. It's not the rules that matter, it's the goals. In interviews, what I hope to hear from candidates is that they have a 10.000 ft view of software development at all times. By that I mean to be mindful during their work of why they're doing things. When people don't think about the "why", they're just a code monkey rehashing somebody else's rules.

I would suggest turning the table on the interviewer and talking to them about what you think goals of a software development process should be, and what sort of structure is necessary to achieve that. Talk about the reasons why you need a VCS, why you need code review, why you need team meetings, how the goals of a spec sheet can affect team structure and development process, ... They will appreciate your thoughts, even if they don't quite agree.

Of course, some interviewers just want to hear you're a "yes man". Stay clear of these places. You won't like them unless you don't actually like software development.