Fog Creek Software
Discussion Board




Coding != Software Development


A lot of threads here are lamenting the current state of the industry and wailing about how "good" developers are going without jobs.

Now, it's not always explicit, but most of the time you can tell that "good" means a good coder. As one poster put it, some people keep their jobs "who couldn't write code to tie up his own shoelaces". I'm getting a little tired of this.

Programmers concentrating on coding is like civil engineers concentrating on concrete. Sure it's important, but all the concrete in the world isn't going to keep that bridge from collapsing if the design is flawed. Neither is concrete going to make sure the bridge gets finished on time and on budget.

I'm also getting a little tired of developers who complain about unrealistic schedules and yet:

1) Always have something better to do when the schedule is being created.

2) Go "cubicle" for days at a time and never bother to let anyone know they might be late on delivering their piece of the puzzle.

To me, all this smacks of a group that refuses to take responsibility for it's own actions. To hear some programmers, they're merely innocent bystanders on some projects. Who needs that?

To actually do software development, as opposed to coding, you must:

- Be able to work with groups of people, some of whom you may not like.
- Gather, or at least assist in gathering, requirements.
- Translate, or assist in translating, those requirements into a design.
- Scale the design to the time and monetary constraints of the sponsor.
- Code
- Test, or at least assist in testing (how many coders do this?) the product.
- Package, or at least assist in packaging, the final deliverable.

Add to that scouting new technologies and methodologies.

To me, the only requirement for a developer is: YOU MUST BE ABLE TO USE YOUR BRAIN. And that is why you see many otherwise "good" developers on the streets. Where I work, the only developers you see let go are the ones that refuse to use their brains.

Some of them were good coders.

Herein endeth the rant.

Bruce Rennie
Tuesday, December 17, 2002

Amen.

Matt Christensen
Tuesday, December 17, 2002

I'll second that.  It's always the "messy details" that seperate the good ones from the bad ones.

b2
Tuesday, December 17, 2002

Great post, Bruce.  One of the skills I find sorely lacking in developers is cost-benefit analysis. 

Costs are often underestimated.  What is the cost in usability for that new feature?  How often will the code need to be maintained?  How much time will the docs person need to spend?  How does the feature impact other code that needs to be written?  What about QA?  I've seen too many times where a developer figures a week to code something and said developer mentally translates this into a cost of one week's salary.  Big mistake.

The ability to "see things coming" is another critical skill.  A good developer looks at the number of permutations a given change creates and asks himself "can I manage all these?".  Dropping another table into the database is easy.  Knowing what you're getting into with propogated deletes, disparate statuses, sync concerns, etc. is a definate learned skill.

I've always worked in situations where the developer was intimately involved with the business problem to be solved.  Can a database be designed separately from assessing the needs of the client?  Can the UI be designed separately from the database?  It's critical to have a core team of developers who see all angles.

Programming, at its core, is the translating of time into money, not time into code.  Good developers will read the preceding sentence and say "well, duh".  It's an almost insurmountable change in mind set for some people, though.

I know this is a sensitive subject, but I generally find a positive coorelation between how "good" a developer is and how they apply cost-benefit analysis outside of work.  Do they understand risk/reward in their personal investments?  Have they planned ahead?  Do they have balance in their life?  Can they understand other people and see their viewpoints? (not dissimilar to relating to prospective users)  Do they "get it"?

This is a male-dominated, competitive profession.  We require quantitative measurement of competance.  You can measure code and arcane language and API knowledge, but you can't measure if someone "gets it".

Thoughts?

Bill Carlson
Tuesday, December 17, 2002

Most unemployment is in businesses where the developer doesn't get anywhere near where decisions are made.

If HP or IBM decide to lay off tens of thousands of workers are you seriously suggesting this is the fault of the individual programmer who couldn't get his ideas across to Carly or Lou.

It wasn't the programmers who went for the dot com bubble (to the best of my knowledge everybody with any degree of technical knowledge thought the thing was a joke) nor was it the programmers who went off and threw away billions of pounds on British and German 3G licenses, yet the dot com crash, and the huge debts of telcos as a result of the money they gave away for the licienses are among the main causes of unemployment.

Stephen Jones
Tuesday, December 17, 2002

"Programming, at its core, is the translating of time into money, not time into code."

I would question the intelligence/motivation of someone who recognized the truth of that statement, but chose to become a programmer. Programming is a highly inefficient way to translate time into money. If you really want high time to money ratio, you are better off with a high-finance related job, such as negotiating mergers, or trading options, or even simply "sales."

p135
Tuesday, December 17, 2002

Come on, when the person above said "software is about turning time into money" it was not their personal finances as much as ROI for the business sponsoring the project.

In other words, by automating tasks you expect to save more money than you invest in a given project - otherwise, continue to do what you have been doing. The goal is *NOT* to write code, its to solve business problems.

Ilan
Tuesday, December 17, 2002

While I agree with so much of what is said, let me disagree just to be disagreeable (my natural state):

1) Always have something better to do when the schedule is being created.

Schedules require up-front work.  There are core peices of the puzzle that each developer will contribute to.  Their strengths are often well known.  Therefore, before a scheduling meeting be held, rough requirements should be fleshed out and developers be allowed to scope out their work.  Ahead of any meeting.

One thing I cannot stand is to listen to dvelopers, managers, anyone else, jawbone about "yeah, that might work..." without any forethought about their topic.  Don't waste my time, or I'll leave.

Other counter-rants:  If I don't like you, I've probably got good reason for it.  Laws of physics don't change just because a marketing plan thinks they might. Regardless of my personal feelings, I'll work with you for the good of the project.  Its easy for engineers to do so, because they know its not about them, its about the product.  Also, don't feel insulted when I contradict you in public.  Its not about you, its about the company and the product.

Gather or assist in gathering requirements:  Of course!  f I have to write the spec, I might as well code it.  Nothing new here...

The rest is all good.  Engineering is not only coding.  Hearty agreement on that count.  I wouldn't trust someone who couldn't/wouldn't write a functional spec to write the code.

Nat Ersoz
Tuesday, December 17, 2002

Prostitution is also a more effective way of turning time into money than is programming.  Most of us know this and still have yet to hang up our hats.

I agree with the poster who theorized that "problems solved" is hard to measure.  We tend to choose our favorite measures such that it's easy to whip 'em out, and such that we are above average.

Business problems solved is also a harsh thing to strive for.  Most of us are passionate about what we do every day, and the art of programming or the craft of programming is somehow more lovable than the business of it.

After time I've learned to love the business of programming above the art of it.  I'll never expect to be followed here.  And I still have to interact with people, coders who think they get software development, who won't respect me unless I can beat them on their own chosen coding turf every time.

I would have to say the best thing about being a true software developer is the non-coders.  All the poor non-coding managers and testers and users and domain experts who are so delighted to finally meet someone they can really collaborate with, someone who can both write code *and* respect their skills.

Mikayla
Tuesday, December 17, 2002

Other rants _against_ developers (schitzo, yes?)

I'm sworn to kill the next person that utters the words "it works fine over here".  A bug is a bug no matter where it is found.  Because something works in your cube is meaningless.  Get off your ass and debug the problem.

Test all known cases, and don't claim its done until all known cases are tested.  Feature complete?  Sure.  Complete?  No way.

Nat Ersoz
Tuesday, December 17, 2002

I really don't think "it works for me" means "The bug doesn't exist." It means "it works for me," let's find out why it doesn't work for you.

If the people you work with are that stupid, you should stop working with them.

Zero C00l
Tuesday, December 17, 2002

No.  When the buttocks stay in the chair and the finger points at the screen/monitor/device under test it doesn't mean "let's investigate".

That sort of crap happened in the past.  I haven't killed anyone recently.

Nat Ersoz
Tuesday, December 17, 2002

"Come on, when the person above said "software is about turning time into money" it was not their personal finances as much as ROI for the business sponsoring the project.

In other words, by automating tasks you expect to save more money than you invest in a given project - otherwise, continue to do what you have been doing. The goal is *NOT* to write code, its to solve business problems. "

This might be true if you are a consultant. What I'm saying is that many programmers don't think that way, they just like to program, and feel like they are doing something "cool" *. Compound this with the fact that most programmers do _not_ have a significant stake in the business they work for, and I would guess that "your job is not to code, but to save the business money" is not a particularly motivating mantra.

"Thanks Jim, your bugfixes just saved AON insurance company $70 million dollars. Here's your $5000 for the month." How is that anything other than depressing?

It is not really the job of programmers to "solve business problems," it is the job of _business people_ to solve business problems. Now, if the business problem can be solved through software, the business person needs to either be able to write/buy the software herself, or be able to motivate some programmers to write the software.I'm saying that passing the "save the mothership money" motto on down to most programmers, won't work as a motivator.

In my experience, I was saving a lot of people a lot of money for about three years, then decided I didn't really give a fuck about their business problems. The only thing that motivated me to program for them was the money, and it got to the point where no amount of money was really enough to continue on.

So now I'm working on some non-business problems, more related to science than figuring out  how business XYZ can replace a clerk or two with a database and some web forms, and am much happier. I'm making relatively good money doing so.

I realize this attitude is probably opposed to the majority of managerial-oriented software engineers on this forum, so I'll probably not post any more on the topic. I just wanted to beam a ray of hope to the not so "bottom line" oriented developers on the thread : "there is an alternative world to streamlining backoffice procedures, don't despair!" ;-)

(*caveat: a lot of programmers today seem to have gotten into the "biz" because they just like to sit in front of a computer all day, which is a different story altoghether...)

p135
Tuesday, December 17, 2002

Management != person.asking('When will it be ready ?');

SYMPTOMS :

- lack of interest in the details of a project by the managers/leads.

- lack of detailed design specs passed down to developers.

- no precise user requirements information.

- no clear instruction from manager/leads of whom should be doing what in a project.

- consistent talking down of the client or other related organisations.

- Managers in customer organisation think the solution is fantastic, managers in the Provider organisation think the solution is fantastic.  The Users and Developers of the system think it is crap. 

Communication pathway

  1:Customer Managers ----------------  1Provider Managers
          |                                                            |
          |                                                            |
  3:System Users .............................. 2:System developers


-- : communication pathway
... : communcation pathway that isn't allowed for strange, political reasons.
1,2,3 : rating of competance in judging the quality of the system.  3 being most competant, 1 being least.


PROBLEM :

- There is reward to the provider managers and client managers for completing a project. 

There is no reward based on the quality of the project.  All the talk and reward for the quality of the solution and it's new found features was milked before the project even began. 

Now it's getting it finished that counts.

SOLUTION :

- Work on PRODUCTS not PROJECTS.  Where there is no single customer, you decide the deadlines, and it's the quality of your software out in the marketplace that decides it's success.

- Work for Joel.

- Work for yourself.

- Work for me (when i get around to working for me). 

braid_ged
Tuesday, December 17, 2002

Whenever I've refered to "coding" in my writing the design aspect was always implied. There is no coding without design. Just as "hacking" implies the same to me. We design and create software. A very simple statement, but not as simple in practice.

But I see what you've implied, that it doesn't end at the code and I agree. Unless all of the pieces to the puzzle come together correctly it will be a waste of time.

Ian Stallings
Tuesday, December 17, 2002

Actually, when the person above said "software is about turning time into money" they were merely mimicking Joel as many other hero-worshiping sycophants do on these boards.

Jeremy
Tuesday, December 17, 2002

Good developers have the ability to relate and empithize with a wide variety of personality types.  Why is this important?  It's important because the job of a developer is not only to create a great product, it's to sell others in the company on why it's great and why compromises were made.

If you don't like or respect someone, that's fine.  I'd argue though, that playing favorites or openly disregarding someone else's contributions and ideas doesn't make for good process.  There are people who I don't respect personally or as a developers, but I let them have their space and yes, sometime fake respect.  Doesn't mean I take what they say to heart.  "I see what you mean about A, but we're going with B for the following reasons" makes for better process than "You Application Engineer II's make me sick with your childish incompetance.  Maybe when you're a Application Engineer III like moi, you'll have your shit together".

QA attracts a different person than marketing.  Sales is different than project management.  Can you give each of the groups the information they need?  Can you communicate with them in a way that both shows and demands respect?  People respect different things.  Give 'em what they want.  If someone values stability and compliance, show this to them.  If it's risk taking and abstract thought, let them see you in this light.

Sitting in your cube playing with code while singing "I got da skillz, baby" isn't being a developer.  The difference between now and ten years ago is that many upper level managers know the difference.

I too, value craftsmanship in software development.  I love the look and feel of a $5,000 handcrafted cherry wood desk.  However, I don't love it $5,000 worth.  Thinking that you'll get the $5,000 desk down to the $200 people want to pay isn't realistic.

Bill Carlson
Tuesday, December 17, 2002

Bruce, you have confused several issues in your post.

First, the references to quality are not about coding at all; they're about development. Much of your following argument is built on that invalid premise, and thus is also poorly based.

Second, complaints about foolish scheduling generally describe situations where management lacks expertise to schedule well and does not consult developers.

The situation you describe suggests you, probably as a project manager(?), are not skilled in facilitating discussion and your developers have learned not to trust you or participate in your planning meetings.


Tuesday, December 17, 2002

Nat -

**I** certainly understand your pain...

as you could well imagine, I suppose, given my job.

Though I have to give credit--developers in my current shop are quite good to follow up with me in the lab if they haven't been able to duplicate a bug in their local environments.

But I have seen to one degree or another, in this shop up to a couple of years ago, and other ones previous to that:

- developer is on own local environment different than that stated in defect report,

- on different build than qa lab,

- often pointing at different instance of db or different db server than qa lab, different data in dev than qa db,

- different, different, etc.

qa assigns defect to developer including full details of environment / conditions / data / steps to reproduce, etc., of course based on observations in the **controlled environment** of the qa lab (you know, it's that big room with all the machines in it the company spent all that money on?).

Oh, and my rule for entering defects in the QA shops I run is: if you can't describe what happened and how you made it happen and reproduce it yourself, don't expect other people to do your work for you. I expect my people to note anomalies and do the analysis, experimentation, and 'detective work' to identify the specific triggering conditions and events. If we don't at least do that when we're testing, then as far as I'm concerned, qa isn't pulling it's weight--we're dumping our crap back onto the developers and they don't have time for it.

So if qa put the bug into the defect tracking system, it's occurred once, and been reproduced at least once (probably more, given the experimentation needed to isolate specific triggering factors) already. Once, again, of course -- in the lab (big room, lots of machines... remember?).

The developer marks the defect in the defect tracking system 'cannot reproduce' and reassigns to qa. And never once during this process has their shadow darkened the lab doorway, nor have they asked qa a single question.

So, you can't reproduce the bug on your local environment there, eh, sport? Well gee, no shit.

Now, IMO, a silent reassignment and classification as 'cannot reproduce' is at least as eloquent (and unambiguous) a message as the buttocks not leaving the chair saying 'gee, works here'.

I certainly agree with you, Nat.

Cheers,

anonQAguy
Tuesday, December 17, 2002

Strange as it may sound, I can respect P135 when he says he "didn't really give a fuck about business problems".  Why should he?  If your company pays for process rather than paying for results, what can you do?  Maximize your entertainment if you're going to get paid the same either way.  Learn new stuff, etc.

I would argue, though, that successful business units are those which reward contribution to results, not necessarily the results themselves.  For example, some projects are just a slam dunk.  3 idiots and a copy of VB5 gets something done which saves millions.  Fame and fortune for the 3 idiots?  No way.  Maybe for the person who proposed the project.  You don't want to reward being at "the right place at the right time".  Similarly, many projects are truly research.  Someone may be richly deserving of reward even though the project didn't pan.

A successful software project is ideally one where a 3rd party looks at the code and says "wow, this is so simple; what took so long?".  Many compensation policies reward quantity, complexity and hours, when these are often negative coorelations to business value.

Bill Carlson
Tuesday, December 17, 2002

"Bruce, you have confused several issues in your post.

First, the references to quality are not about coding at all; they're about development. Much of your following argument is built on that invalid premise, and thus is also poorly based.

Second, complaints about foolish scheduling generally describe situations where management lacks expertise to schedule well and does not consult developers.

The situation you describe suggests you, probably as a project manager(?), are not skilled in facilitating discussion and your developers have learned not to trust you or participate in your planning meetings."


Heh, I knew someone would try to kill the messenger.

Not that I require any defense but... I run a XP project in which the developers who will actually be doing the work provide the estimates. It took a little while to develop a sense of trust between management and the developers but now I don't believe management would try to schedule any other way.

I sense that your reference to "project manager" was a slur. That's not what they call me, but if so, I would wear the title with pride.

Bruce Rennie
Wednesday, December 18, 2002

Don't worry Bruce. It appears that this nameless ignoramus is poluting discussion on other topics as well. It seems to be inable to grasp concepts and instead picks on words instead of on ideas.

Bruce Bruce
Wednesday, December 18, 2002

Bill C.,

Basically, this is a rant thread - it began with Bruce saying "I'm tired of..."  - so its with some exageration of degree (not substance) that I rant against both the worst side of management and developers.  I coulda used all caps...

if a company's product stream is built on software development then its the responsibility of all members of the organization to grasp the technology as best possible. 

Of course, there are some technical people who work for companies whose main product is not software - perhaps its insurance or banking.  Or perhaps the core technology is large scale manufacturing and software is only a small peice of the puzzle.  In this case its the software engineer's responsibility to grasp the larger picture and not hide in the cubicle behind a screen of code.

In either case, there is no excuse for each employee to have the best interest of the end product at heart, and they must seek that end.

In my case, our core product is embedded software.  Hence, I am at liberty, yea verily obligated, to rip 'em a new one when its obvious that a manager is ignorant of the details - yet blathers on.

Thanks for the rant time...  Does someone actually read this?

Nat Ersoz
Wednesday, December 18, 2002

An idea is not a design
.A design is not code
..A code is not a demo
...A demo is not a program
....A program is not a product
.....A product is not a business
......A business is not profits
.......And even profits are not happiness.
-- Michael Sellers, on rec.games.design

(Thank you, Bruce; excellent post.)

Brent P. Newhall
Wednesday, December 18, 2002

Bruce, no wonder you have problems managing your projects. You should learn to listen to people instead of attacking those who disagree with you.

Must be a manager
Wednesday, December 18, 2002

Nat,

Read your post. Thought it rang true. I couldn't agree more. Thank you very much.

Walter Rumsby
Wednesday, December 18, 2002

[[ As one poster put it, some people keep their jobs "who couldn't write code to tie up his own shoelaces". I'm getting a little tired of this ]]

And I'm getting tired of people who separate "coding and design" or "coding and team-work" or coding and hundreds of other issues. All those issues together you talked about above were always "software development", the mere fact of typing letters in the editor was never "just coding" for me, it's still only typing.

That's why I hate when people call my profession "programmer" - it's a wrong word causing them to think I can only type and others to think that their superior abilities in design put them high above me. The original poster is absolutely right calling us "software developers" but I see no reason in explaining this to us.

There's no difference between "coding" and "development", whatever you call it - it still means the same: building the product.

Those who can only type the code and can't make any correct decision by their own - aren't coders for me either. They're just people doing the wrong thing for their living.

Evgeny Goldin
Thursday, December 19, 2002

"And I'm getting tired of people who separate "coding and design" or "coding and team-work" or coding and hundreds of other issues."

I know why I do it and why I rant about it.  It's because so many people who code divide the world into "person is capable of coding, codes well, and therefore is worthy" and "person does not code, no further analysis necessary."  And I'm not talking about evaluating their worthiness for a job as a programmer, I'm talking about evaluating their intrinsic value as a human being.  Even people I like otherwise seem to do this -- one explained/justified it as "I think of people that are technically skilled as good coders that just haven't learned to code yet. So I see them as coders, whether they are or not."  Still not hitting the point, that code is not a bad thing by any means but it ISN'T the ONLY thing.

We code "and something" because there are people who purely code, and think we're idiots or at least lesser men for wasting our time with the something, like the programming lead in the "Documentation" thread who doesn't write design docs.  There are others who see coding and the various associated somethings as inseparable, necessary parts of a successful whole.  We who rant are not ranting at you I can assure you; we're much like you, just currently more frustrated.  Rarely are we ranting at any of the regular posters here, really, we're just sharing common frustration caused by how many people start out with a copy of VB6 and a "for Dummies" book and somehow don't develop a bookmark to the JoS forums for years.

Mikayla
Thursday, December 19, 2002

*  Recent Topics

*  Fog Creek Home