I’m surprised by Patricks comments, surely the three structures - sequence, selection and iteration - are still needed in OOP not just “procedural” programming languages.
I’m going to jump on you for censorship. Seriously, why block out “nigger” but not the other potentially offensive words? Why block out any of them? Do you think readers will turn away if you spell out “shit” in all its glory, especially when it’s in a quote? Have you EVER met ANYONE who would prefer to read “s**t”? I haven’t.
Obviously the answer is to have other team members hold the violator down while you beat them with a bar of soap in a sock.
I’ve worked with people who I’m not sure even that would have made a difference. Some people are just lazy hacks (not hackers) who take no pride in their work and are simply collecting a paycheck. It’s a fact of life, at least in larger companies (where each of us is little more than a fungible cog).
I’m going to have to cast the one dissenting vote on this opinion piece. In my experience as a developer so far, I’ve come to the conclusion that project success is for all practical purposes an exercise in pragmatism. Initial project success has little to do with discipline, code documentation, software development processes, metrics, version control (as long as it is at least there!), etc.
Instead, in reflecting back at the project success and failures in my past, it seems to me the defining factors were a reasonable scope tied to a reasonable deadline, coupled with a competent “problem solving” team of programmers, architects and QA.
In short, all the most well-disciplined code in the world won’t help your project if your team is lacks the competency to adequately problem solve for issues that arise during the development cycle. More importantly, absolutely no development cycle rewards unique problem solving or innovation.
WoW, Dean hit the nail squarely on the head! I have been programming for 16 years - done Agile, XP, ISO, CMM, Scrum, you name it, including Watt’s PSP (which is CMM for the individual, now CMMI), including, “Pyle I will give you 3 seconds, 3 f@cking seconds…”
My experience is that it is all worthless if you don’t have competent “problem solving” team. All the discipline in the world won’t save your project if you don’t what problem you are trying to solve and being pragmatic about solving it. After burning a good percentage of night time hours solving the wrong problems for many a year, I figured there must be a better way – there is and it’s got nothing to do with discipline.
Discipline and competence don’t have to be mutually exclusive. In fact, if you are are a competent programmer, chances are you are disciplined and organized too.
Somebody wrote a nice article about the relation between programming and abstraction. If you can’t abstract a problem into simpler and simpler levels, all the world’s discipline won’t get you anywhere. Abstraction is what got us from Punch cards to Assembly to OOP. Without it, we’d still be hacking away and coming up with Design Patterns in Assembly Language.
But discipline is still important unless you love your paychecks. This is why:
http://www.thc.org/root/phun/unmaintain.html
Discipline one level up will avoid a lot more issues:
- Think about the solution
- Think about the solution
- Think about the solution
- Think about the solution
- Write code for the solution
No mistakes in repeating to Think! If more time goes into thinking than writing code, there will be very clean code.
In this world, most of the developers start writing code and then think, then break, become possessive of already written code, try to ‘fix’ the code, circumvent solutions, patch it and repeat this process many times. In the end the code written is not fully functional, too bulky to throw away and rewrite, less possibility of re-factoring and due to time pressure moves to production/relese. Then starts the maintenance part of it, repeating the same story!
If every developer starts to think about the solution first (not code), things can improve to a great extent.
Hey Jeff, Great article. Exactly what i was looking for these days. 
We’re going to start the senior project for the bachelors course in CS. We see a lot of “techie-researcho” projects going on all the time whose sole purpose is to create a project (atleast pretend to), get a grade and scrap the work.
We dont want to do that. Our proposal is something different. Something on the lines of tackling the root problem to stop this one. We really need desciplined developers and programmers. (and by programmer i mean a much larger term than the usual conception is). So, we setup to develop a platform for students, a complete computerized system that they can/will use as an academic tool to learn discipline in their course of time at the university. This includes open-source tools like version controlling, bug-tracking, wiki, knowledge base management and searching, feedback and mail. All these tools are available yet most of the undergrads have no idea they exist. They can hardly work together in a team. One guy usually just spends nights after nights to complete a project supposed to be complted by 5 in a team.
Is there anyway i can get some time from you to discuss this project in detail? Probably by email or any other way? I expect to have a hard time convincing my supervisors and faculty on this one. Ill be pleased if you can provide me some time :). Thankx.
Forgive me but wasn’t Gunnery Sergeant Hartman gunned down by one of
the “maggots”?
The crux to me seems to be is the matter of attitude. If I want to develop and manage my code in a better/easy manner, i’ll make sure i follow convention and if not at least learn from my mistake to follow it in my next coding horror
Why censor one racial slur and not the others? As a fellow hacker, I expected less adherence to hypocritical social dogma 
Other than that, a relevant, well written article which I completely agree with.
A programmer is a person who passes as an exacting expert on the basis of being able to turn out, after innumerable punching, an infinite series of incomprehensive answers calculated with micrometric precisions from vague assumptions based on debatable figures taken from inconclusive documents and carried out on instruments of problematical accuracy by persons of dubious reliability and questionable mentality for the avowed purpose of annoying and confounding a hopelessly defenseless department that was unfortunate enough to ask for the information in the first place. If i were lucky to have a gunnery sergeant to look over my shoulder that would take the stress out of having to actually figure out what the heck the l-users actually want and concentrate on my code. But since i’m my only metric, that option is out of the window.
cheers,
Andy
I always thought that a good programming excersize would be to have each person in a class write a function to do something simple, like shuffle an array. Then everyone passes their code one seat to the right and then you have to take someone elses function and use it to sort your deck of cards in your data structure. Then you pass it to the right again and use that code to deal out 4 hands of cards. Then pass to the right again and use that code to determine the winning poker hand. Keep passing code until you have a full poker application. Let people see how much fun it is to inherit bad code from someone else and they won’t be so fast to write it in the future.
My experience in Public Management and Programming (including software and system architecture for the public sector) is similar to that mentioned by several of you. The time constraints ARE a problem, because deadlines are often set without developers and architects having a complete grasp of what will be required to solve the problems at hand, not to mention the likelihood of adding on a time buffer for unexpected problems in a project. However, discipline and competence are definitely important issues.
Firstly, that’s what separates the hacker from the engineer in many cases (though not all). We are supposed to have a serious knowledge base to quickly draw upon… or at least to be able to QUICKLY acquire the knowledge we realise we are lacking and need to solve a particular problem (this is BTW what academics in ANY field are supposed to have gained from their university studies).
Secondly, discipline is not just getting things done on time. It is also the ability to receive, process and benefit from CONSTRUCTIVE criticism from our peers. It is also the ability to second-guess our solutions to, say, a memory management or optimization problem, asking (hasn’t this been done before, somewhere and better?) on the one hand, without becoming completely paralyzed to the point of not being able to draw the line and make a final solution.
I guess having TWO areas of expertise (Public Management) and software engineering/architecture has been beneficial in my case, because on is forced to see things from different perspective. BTW Theresa, we had flow charts in our first FORTRAN course when I attended Texas Tech University in the 1980’s. That was one of the few items that stuck with me during the years.
Jeff,
Of all your posts this is the one that I find myself revisiting again and again. I’m constantly trying to emphasize the importance of discipline to my team. Thank you for making my job easier.
-Jamie
“Private Pyle, is that a jelly donut in your locker?!”
One or more Private Pyles on your project and look out for trouble. Get and stay organized, especially on larger projects.
Excellent reference to Full Metal Jacket in your article.
Full Metal Jacket, Glengarry Glen Ross. Love the motivational movie references!