"There should be a Gunnery Sergeant Hartman on your development team who will.. gently.. remind the team that it might be a good idea to fix problems like this before they become institutionalized in all your future code. "

In a previous job I was definatly that person, trying to standardize and as you say 'gently' remind people that these things need to be sorted. The problem is that unless you can get people to switch over to ensuring the standards are followed and checked as part of the routine you soon begin to feel like your constantly nagging, and thats not nice :(

When developers on our team take the time to do these kinds of things properly we call it "Leading by example" And leadership is one of our performance review topics.

"Now, lean over and choke yourself!"

Biggest trick I've found with this sort of leadership in setting up discipline is the requirement of setting an example. "You're going to come help me do this" works a lot better than "Go do this."

I've just been thinking that I need to force myself into a more disciplined coding approach, no matter how quickly the deadline is looming.

Oh, and does anyone else find it amusing that nigger is censored but there's no problem saying wop, kike, or greaser? :P

I wonder what is in that "women" media file on that desktop image...

Can I be the someone who points out that you typo'd on 'someone' where you say, 'or perhaps somone with the right'?

My issue is when I bring these issues up with many programmers, they tell me 'everyone has their own style'. They somehow chalk up deficiencies as their own special brand.

My other issue are programmers who never seem to stop and think, 'there has to be a better way to do this'. They just write what comes to their head. And then I'm considered an elitist when I replace their 27 line subroutines with 1 line.

Discipline? I always thought laziness is a virtue for programmers. Maybe the two aren't mutually exclusive, but we like to think they are. Hmmmm... Can one be lazy and disciplined?

david h: I'd suggest being disciplined would actually help you be lazy.

Disciplined code results in easier to manage, less likely to break, less work to understand later code.

So writing disciplined code means less work later managing it. A lazy person's dream!

Many years ago, I was running a code review for some software on a major DoD project we were testing. Now, remember, this was MANY years ago: our two languages were Fortran and Assembly. Just from the constructs available in the higher-order language (that'd be Fortran for those of you without a history course under your belt :) ), you'd think the Fortran modules would be better-coded than the Assembly. Well, you'd be wrong. The Assembly code was FAR more structured and maintainable than the Fortran code. Someone at NASA (the originators of that Assembly code) definitely had the discipline to force those programmers to produce highly maintainable (heck, it was practically elegant) code. The contractor for the Fortran code, using the very same standards, didn't force the issue and ended up with merely adequate code.

Discipline is an absolute requirement for good code. If management won't do what they're paid for (manage and control the software development process), then programmers will have to do it themselves.

@dnm (and Jeff)

dnm, I feel your pain... I think those are extremely cogent points.

What the programmers who don't think 'there has to be a better way' aren't doing and should be doing is this -- (and this is a good idea for a post, Jeff) --

Great programmers talk about programming.

It's that simple. That's what we're doing here and I'd bet that's what you do with (at least one of) your teammates. You get better at what you do by talking about how to do it better.

That's why your routines are better, dnm!

g

I think that for establishing discipline it should be mandatory for all developers to establish and maintain some assembly code (something in the range of 1000 lines), anyone who doesn't have discipline will be pulling the flippin' hair out after a week. This will also help with documentation (we call them 'comments') when someone has nested functions that are pass by value-reference. I learned more about discipline writing a few hundred lines of SPARC ASM this semester than all of my C++ for the last 5 years. If my macros for registers didn't make sense, I'd know after about 100 lines.

"And my orders are to weed out all non-hackers..." WOW the corps was building hackers way back then!...sweet.

BTW: why was nigger censored but not kikes, wops or greasers?

PS: I liked the article very much.

This will certainly date me (okay I admit it - I'm old) but back in "the day" colleges used to offer computer logic classes. The class was not writing code, it was writing flow charts - the logical set up of a program. Naturally, as it was college, these were single programs doing one task, but learning to structure a program first makes everything else so much easier.

I haven't seen a class like that listed anywhere for years. The shame of it is, once I took that class, every type of code writing became a matter of simply learning the syntax - the rest of it falls right into place. If you extrapolate, the logic can easily be extended to work projects that include multiple files in a tree structure.

I guess it was deemed "too boring" by the CS departments because it never involved any of the latest and greatest cool code and seems to have disappeared from the scene.

I am sure this is one of the biggest reasons that so many projects are in such disarray.

There's also the issue that there's a large number of people who genuinely have no place in this field at all. They just think there's money to be had. Sadly, there is money to be had, because many hiring managers aren't able to weed out the crappy ones.

You really made me flash back to when I was a newly minted programming graduate. I knew all about recursion, data structures, 3D vector math, database theories of normalization and unix scripting commands. What I didn't know about was project planning, code commenting, variable naming schemes, choosing the right "X" for the "Y" or any of the other functions of the business of being a programmer. I had graduated from a major state university known for technical skills with all of the training to be a script kiddie. That first year getting indoctrinated into the mysteries of producing code to spec on time and in budget was a real eye opener.

Perhaps what we need the last semester (or first semester) of CompSci to be is boot camp. You will learn to write good code, cleanly and clearly with useful comments and well defined outputs and error handling. Or you will drop and give me 20!

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.

In response to Teresa here, I as a recent graduate of an Information Systems program did do flow charts in our introduction to programming course. I think it is something that is still around, but it's been condensed into the beginning programming courses as opposed to being it's own dedicated course.

And yes, I wish I were more disciplined when I code, hopefully with expierience I will learn ;)

Regarding the perceived opposites of being lazy and being disciplined, this is because there are good and bad sides of being lazy, as well as good and bad sides of being disciplined.

Being lazy can mean that you don't bother with following code conventions, testing and sanity checking, documenting or figuring out reasonable names and designs. Being lazy can also mean that you're not making your code or designs more complex than they need to be, not implementing functionality that won't be used, or reinventing the wheel.

Being disciplined can mean that you can stay focused while you're writing thousands of lines of unnecessary convoluted code that will be impossible to maintain and wasn't needed in the first place. But of course it can also mean that you're making sure you're doing a good job.

The right kind of discipline and laziness are essential traits for good developers, I think. Me, I am both lazy and disciplined, although not always in good ways.

You're also making the assumption that developers are given the minimum amount of time and resources to allow discipline to make a difference. The company I currently work for lives by this motto, "Broken functionality today trumps properly designed code tomorrow." The ONLY aspect of software development that matters to them is ship date. Doesn't matter if the product wasn't designed, didn't have enough time for development, no documentation, and that QA time was skimped or eliminated, as long as the artificial ship date is met, all is good.

If your fundamental foundation of software development is flawed, discipline can take you only so far and beyond that you can be the Anal Retentive Chef and it won't make a bit of difference.

In response to Teresa, I'm about to graduate with a Infomation Systems degree and my University only teaches object-oriented languages. I believe flow charts are more important in procedural languages.

However, all of our professors did stress the value of clean, maintainable code.

Remember what happened to Gunnery Sergeant Hartman? Good luck, enforcers.

Is that Scott Hanselman's desktop? :P

I like this quote, which apparently was said by Confucius:

"By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest."

Perhaps substitution of "software development discipline" for "wisdom" works as well.

Being held accountable for low-quality work and having to spend late nights and weekends to fix it is definitely "bitter" and will either make one straighten up and fly right or fly the coop in my experience. Of course, having to do that fixing someone else's work will also motivate you to elevate the level of discipline expected on a team.

Having a good mentor to learn from and a good set of software practices and accountability measures in place can definitely make the development more disciplined. Being naturally well disciplined is somewhat of a rare situation, I think. I think we all benefit from having an environment where excellence is expected and measures are in place to get you there.

The lure of good paying salaries and benefits in an air conditioned work environment, driving a desk is unfortunately a motivator for many who couldn't give a flip about developing quality software. I've worked with too many of these types over the years and it can drag you down if you actually care about producing quality. But that is a different matter.

Published coding standards, and then code reviews.

Jeff, I've been reading you for months, but this is the first time I've forwarded your post to every developer at my company.

Outstanding post, soldier.

I understand the need for coding standards. I follow some myself that I've been "brain washed" into following from companies I've worked with before. But while you're trying to "brain wash" your group of programmers to follow a particular coding standard, don't end up like Gunnery Sergeant Hartman. :)

"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.

Teresa: I'm working on my Computer Science undergraduate degree right now, and fortunately for me, my university does have a class which is almost exactly as you describe; it's called Software Modeling and Design. It is required for every Computer Science and Software Engineering major, and covers the use of UML to design software systems. I'm actually starting this class tomorrow ;-)

Take heart, not every university is afraid of being "too boring." There are still those who care about real education!

Keng: I think the good serjeant was using it in the sense of being able to cut the mustard - as in, if you can handle it, you can hack it, and thus you are a hacker. If you follow me.

Great Post -- Liked it almost as much as the Glengarry/Glen Ross post.

You left out one big word: Authority. The drill sergeant has authority over his "pukes". But who in management has delegated the authority to enforce discipline on developers? In my experience, one of the biggest and realest problems that companies face is that they don't have development leads who are given both the time and authority to enforce discipline.

I fluctuate back and forth on this issue. Sometimes I think we need *less* discipline, not more.

One thing engineers need to accept is that there are *very* few instances in which there is *one* right way to do things. And under the right circumstances, the wrong way can be the right way or at best, inconsequential. Exhibit: A - Linus developing Linux with tarballs and patch files for 10 years.

Another thing engineers need to learn - your desires for engineering "cleanliness" is subservient to the needs of the business. Too many software guys think we code inside a white castle where money magically appears in our bank accounts. You could probably make an interesting blog entry on this topic (assuming you understand it yourself of course :) ).

I find myself being that person now, even though I am not technically a supervisor, I have to frequently remind the other developer that I use conventions when writing my code, and he should do the same.

I have to wonder how disciplined Microsoft developers are. Clearly there are no set conventions among their millions of lines of code. Just imagine how much faster the computer world would move if there were. There would be less bugs and vulnerabilities, fixing the few that exist would be easier, and life as a third-party developer like me would be so much easier. Having delved deeply into the office interop objects in VB.NET, I can tell that office is a core set of objects built long ago with added features just duct-taped on with little regards to the way it was originally designed.

In general, discipline can come from yourself, as well as others. Ideally from both early in one's learning curve.

I am reminded of my humble beginnings in programming, where I was the lone programmer. I don't recall if it was you, but someone I read before mentioned the dangers of programming in isolation, the breeding ground for bad habits.

Luckily, I did recognize this somewhat and consciously attempted to read about and develop good habits. When I switched jobs and joined a real team, much of that stood me in good stead, but I also learned just how much I hadn't managed to learn.

Incidentally, in those years as lone prorgrammer, I had three teammates but they were 200 miles away in a different office (and not exactly models of programming discipline themselves). Sadly, my current job has decayed into much the same environment, and I notice old habits trying to creep in again.

One of the best ways to become excellent at something, is to surround yourself with others who are excellent at that thing.

I actually often quote Full Metal Jacket to newish people on the team. Now I know I am not alone.

Full Metal Jacket, Glengarry Glen Ross. Love the motivational movie references!

I think code reviews also help flush the Sh*t out.....

If you're in the mood for connections between Full Metal Jacket and .net, there's always http://msdn.microsoft.com/archive/en-us/vbtv/Episode004/300k.asx

Now I have to re-watch this movie again. Great movie.

If you want discipline, I highly recommend taking the Personal Software Process: A Discipline for Software Engineering course, or at least reading the book and following the exercises.

http://www.amazon.com/Discipline-Software-Engineering-Watts-Humphrey/dp/0201546108

I know many people think it flies in the face of the popular Agile methods, but I've used it on a project that had as many as 18 people at once, with changing requirements, changing staff, deadlines, etc. It is the only project I've worked on where we met every deadline and had an extremely small number of defects.

PSP feels heavy, especially when you're first learning it. But once you make it a habit (aka become disciplined), the perceived "overhead" is more than compensated for by time that would otherwise be spent testing/debugging.

--dang

@dang - I took the PSP course and also certified to train PSP. I agree what it can work and that it feels heavy. I think the principles that Watts and company encourage are good - it is good to be able to estimate well, it is good to have checklists for reviews, it is good to review design and code, and it is good to do some sort of measurement of your progress. My experience was that without institutional buy-in, PSP (or maybe any methodology for that matter) has little chance of succeeding. The "Executive Summary" book that Watts wrote would likely provide management with information that might get them on board, but getting them to actually read it... that's the first trick.

I still have an early draft of Humphey's "Leading a Development Team", and believe it has a lot of valuable insight. Glad to hear it worked for you.

need more discipline? R. Lee Ermey has a podcast, too (via Scott K):

http://www.rleeermey.com/Podcasts/

Also, you can buy the 12" R. Lee Ermey motivational figure with "x-tra salty" recorded phrases.

http://www.actionheroes.homestead.com/reviewsthirtyfour.html

This topic hit the nail on the head, IMHO. Thanks Jeff! Have the discipline to stop and think, have the discipline to consider the goal you are trying to achieve, have the discipline to make sure the code you are about to write was designed, have the discipline to make sure the design meets the goal you are trying to achieve. Oh yeah, have the discipline to make sure that goal is something in the business requirements or needed to meet the business requirements.

You are paid to build software that meets the business' needs. It is not play time.

In response to Patrick:

Writing programs with good flow also comes up in OOP. When you are on one of those projects that is 500,000 lines of code you will find that at some point you have to solve a problem that requires a procedure. Right there in the middle of your object is a method that has lots of if and switch statements.

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.

I agree with you Dean. Out of all the factors involved in a successful project I think code organization and variable naming standards have a small effect if any. Competency is the REAL issue. One competent dev can easily understand another competent dev's code. period. Organinzation and discipline is helpful for the hacks to understand their own and eachother's work.

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

Scott Koon's post moved to <a href="http://www.lazycoder.com/weblog/2007/08/08/the-number-one-trait-a-successful-developer-needs">http://www.lazycoder.com/weblog/2007/08/08/the-number-one-trait-a-successful-developer-needs</a>.

D'oh. Didn't check the preview. Apologies. Here again with the updated <a href="http://www.lazycoder.com/weblog/2007/08/08/the-number-one-trait-a-successful-developer-needs">link.</a>