Fog Creek Software
Discussion Board




The Brickie Programmer

-----------------------------------------------------------------------
Well, imagine some dumb programmer you have known. Now imagine them making design decisions.

That's why we have architects, designers.

Its like having a brickie decide how to build a house, as they go along.

-------- http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp

Is anybody else fed up with the way that programmers are considered 'Brickies.'

I see it all the time.  Designers with no real grasp of either the business or technical domain, churning out half arsed specs.

They think they are creating detailed schematics, an illusion reinforced further after a 2 day course in UML. They think  that their design is complete. 

In reality, they have scrawled a childish picture of a house, in crayon.  Above the house is a yellow sun with a big cheesy smile.  The stick men (twice the size of the front door) have even bigger smiles.

They become annoyed when the dumb programmer takes so long, and has so much difficulty, when all they have to do is turn the completed design into code.  Only the programmer is capable of seeing the design for what it is.
    
Sometimes I think that the majority of things that go wrong in the software is down to these people desperately trying to maintain their illusion.

Of course, their are good architects out their.  These individuals really are worth their wheight in gold, because they are so rare. 

The situation is made worse because it is so hard to recognise the good from the bad unless you really know what you are doing.  To the outsider anybody who can crowbar several TLAs into every sentance appears fully qualified.

For me, the whole appeal of Extreme Programming is that it cuts these timewasters out of the picture.  Progammers deal directly with users and deal with reality.

I can also see why it make Exteme Progamming so difficult to get adopted.  Within the company hierarchy, the 'architect' designers are given much more status (and salary) than the brickie programmers.

Ged Byrne
Wednesday, October 23, 2002

"Only the programmer is capable of seeing the design for what it is."

"For me, the whole appeal of Extreme Programming is that it cuts these timewasters out of the picture. Progammers deal directly with users and deal with reality."

"I can also see why it make Exteme Progamming so difficult to get adopted. Within the company hierarchy, the 'architect' designers are given much more status (and salary) than the brickie programmers."

I understand your pain :-)

Yes, there are numerous 'architects' drawing your crayon drawings.
And yes, programmers are very well suited to tell a crayon drawing from a proper one.
And yes, company hierarchy is probably a large factor of the inertia.

But merely getting timewasters out of the picture is hardly a solution. It is a start, I might agree, but not an end.
Programmers have many capabilities very much needed for technical design and realisation of the product. But you need addition capabilities to design a product to fit who is going to be using it. And software products mostly have to fit the minds of people, much like hand tools have to fit the hands of humans.
Someone who is a programmer might very well have these capabilities, or acquire them, but when you are programming, you need a different mindset, and it is in direct conflict with the mindset you need when designing something for human interaction.

So get the timewaster out of the way, replace them by proper designers and leave programmers continue to do what they're good at. And recognise that the activities are different, but crucial. And learn to appreciate people for their capabilities, not their position in the development lifecycle. So a programmer should not be appreciated less merely because programming follows design. Find a better excuse if you think there is one.

Erik
Wednesday, October 23, 2002

--------------------------------------------------------------------------
recognise that the activities are different, but crucial
------------------------------------------------------------------ Erik

The problem, as I see it, is that within the corporate hierarchy the programmer's activities are not seen as crucial.  Programmers are seen as dumb brickies.

Ged Byrne
Wednesday, October 23, 2002

"The problem, as I see it, is that within the corporate hierarchy the programmer's activities are not seen as crucial.  Programmers are seen as dumb brickies."

I see, that is silly (or plain stupid, really).
I understand that brickies do not earn as much money as an architect does. But that should not be based on lack of respect. Different jobs carry different responsibilities and different capabilities, hence different pay. But never different respect.

So why do these people think brickies are not crucial?

Erik
Wednesday, October 23, 2002

Lets face it, if we were a productive, efficient, fully utilised workforce 80% of us would be unemployed.

See your job for what it is, middle class unemployment benefits.

Simple Truth
Wednesday, October 23, 2002

Allow me to illustrate.

At a previous company the management embarked on a ridiculous project.  Every programmer knew it was ridiculous.

The company wanted to move their 20 year old mainframe system from an ICL system to a Unix system.  The old system used an hierarchial database, they wanted it to be converted to a Relational.

Whats more, it had to be done in 9 months flat, otherwise the company would have to renew a 3 year contract with the hardware vendor.

Every programmer and administrator knew that it was technically impossible.  However, inspiring consultants came in, spent a couple of days looking at the system and said they could do in 8 months.

Management held some open table discussions with the technical staff, and we made our opinion known.

However, as programmers and administrators our status is low.  Our technical knowledge is not valued.  We were ignored.

9 months passed, system wasn't even half done (although this wasn't discovered until month 8.)  Hardware contract was renewed, but project continued anyway.

Project went millions over budget.  Cuts were necessary.

Guess whos jobs were cut?  Low status jobs are always the first to go.

Personally, I'm doing more than just griping about it.  I'm study for my masters and I'm aiming to get a job in design, higher up the ladder.  I'm learning that, as a programmer, there is a lot I don't know about design and project management.  So much I didn't understand.

I'm also discovering that most of the people doing the job alread don't understand these things either.

Ged Byrne
Wednesday, October 23, 2002

"I'm also discovering that most of the people doing the job already don't understand these things either. "

That is very true, in my opinion, writing the code is harder than the project management, I have 13 years coding experience and about 7 years project management. I currently work in a PM role, and because of my coding experience, I only hire good coders, viola, my job just got made ten times easier.

When I want to brush up my skills, I just dust off, Steve McConnells Project Survival guide or one of the many excellant books I have on project management. Any reading I do can usually be done in less than an hour. I sometimes have a laugh with my younger brother who is a lowly coder, he is currently "brushing" up on the .NET architecture, the other day for amusement we counted his reference texts, in all 11, adding up to 7000 pages covering ASP/C#/VB/ADO/XML/Framework .NET.

I earn $US42 an hour more than him in the same industry, which is really funny, because I think my little bro's a pretty smart cookie.

Brickie turned Builder
Wednesday, October 23, 2002

To make myself clear, without the layers of bitterness.

I agree with you that both jobs are crucial.  My problem is that they way the roles are perceived within the hierarchy prevents the jobs from being done properly.

I'm sure you would agree that the most important element within producing a successful product is the feedback loop.  Software engineering recognises that feedback is necessary, most methodologies include interative development.

However, the corporate structure does not encourage feedback.  It sees the approach as 'waterfall' - down only. 

Everything is fine as long as you have good people at all levels.  However if you get a bad designer/architect their position is protected by the company structure.  They ruin everything but all of the blame is shifted downwards to the programmer.

Because the programmer is low status, there is nothing they can do about it.  They are unskilled, easily replaceable.

The situation can only get worse from here.  All of the authority lies with the designer - including recruitment.  Decay has set in.

I'm not criticising the role of developer or programmer.  It is the improper way that they fit within the corporate structure, and the problems this causes.

Ged Byrne
Wednesday, October 23, 2002

BTB,

I hope to emulate your success :)

Ged Byrne
Wednesday, October 23, 2002

"Personally, I'm doing more than just griping about it. I'm study for my masters and I'm aiming to get a job in design, higher up the ladder."

Which is really the only viable thing to do. Trying to change corporate culture hardly ever is.

"I'm learning that, as a programmer, there is a lot I don't know about design and project management. So much I didn't understand."

And vice versa, I am sure. That's why it makes sense to have different people for such different jobs.

"Everything is fine as long as you have good people at all levels."

Always true. Although from high up it might be easier to spot and correct mistakes down below. Companies that fail are the ones that lack a high up capable of spotting and correcting. So all there's left is down below able to feel the pain, but unable to do anything about it.

"Because the programmer is low status, there is nothing they can do about it. They are unskilled, easily replaceable."

And that is the mistake often made. They are not unskilled, but different skilled. The are not easily replaceable, it only seems that way. Maybe because usually there are more, so it is easier to let go thinking you lose only a small percentage of what you had. But you are not letting go of a statistical percentage, you are letting go of a real person with real knowledge and experience that is specific to your company. The generic knowledge is always replaceable of course, but not the specifics. A replacement has to relearn everything you just sent away.

"I'm not criticising the role of developer or programmer. It is the improper way that they fit within the corporate structure, and the problems this causes."

It is the abuse incompetents make of corporate structure, not the structure itself. Of course that doesn't help you much.
I am no expert on corporate structure. I can imagine there are many advantages, and many disadvantages to any structure. But even with only advantages and no disadvantages, nothing can prevent abuse. People are as creative at that as they are at anything else.

Erik
Wednesday, October 23, 2002

"I'm sure you would agree that the most important element within producing a successful product is the feedback loop.  Software engineering recognises that feedback is necessary, most methodologies include interative development.
... [snip] ...
"However, the corporate structure does not encourage feedback"

Wow.  This is one of the most eloquent descriptions of the problem I have EVER heard.  (And I have done a good bit of research into military command/staff theory and what went wrong in the trenches in WWI, when command had NO IDEA of what things were like at the front.)

Sadly, I'm afraid that poster that said that changing corporate cultures was nigh impossible was pretty much right on.  BTW, I too am a master's candidate at night ... :-)

Matt H.
Wednesday, October 23, 2002

What is a brickie?

Ian Stallings
Wednesday, October 23, 2002

Matt H wrote:

"Sadly, I'm afraid that poster that said that changing corporate cultures was nigh impossible "


Unfortunately, I think you are right. I still cling to the hope that over time the culture will change, but for today, if you hope to change the culture so that it produces a better development process then you are likely headed for some serious frustration.

I fought and fought and fought some more to change the way that management views programmers and the development process. Being a development manager as well as project manager at the time, I was at least able to be heard. Unfortunately, I was promptly ignored because my message didn't fit in to what they wanted to hear.

I don't believe in everything that XP proposes, but I do believe in the underlying theme of XP which is the culture won't change. You have to change your development process to be effective with the existing culture. There is some wisdom in there.

For example, requirements docs are great. Having them all mapped out in the beginning is wonderful. But what is going to happen when management dicates a change? Oh, I know...You're going to have a Change Control Committee review and approve it, right? Yeah, whatever.... Sure you will... What will really happen is the change will be forced upon you and you will be denied any additional time to implement the change. Suddenly, your pretty list of requirements doesn't list half of the features the software needs and nobody has had time to maintain that list. Over time, the list is ignored and you're back to the "Cowboy Coding" techniques.

Adapt to your culture first. Then try to change the culture.

Mark Hoffman
Wednesday, October 23, 2002

Ged, what are you studying?

david
Wednesday, October 23, 2002

There's a bad pattern, called "Architects Don't Code". See the description at http://www.c2.com/cgi/wiki?ArchitectsDontCode

Igor K.
Wednesday, October 23, 2002

In response to "What is a brickie?"

A "brickie" is a bricklayer, one who constructs buildings, walls, homes, chimneys, etc out of bricks and mortar - a time-honored profession/craft dating back to the Romans or earlier. Bricklayers work with carpenters, plumbers, etc, and architects (or designers).

I think the analogy was that you wouldn't have a bricklayer design the building as it was being built, no matter how good the bricklayer is.

Philip Dickerson
Wednesday, October 23, 2002

Don't let an architect build your house.  They aren't good for much more than a floor plan.  Your lucky if one has really given enough though about where the pipes will go.  And what happens when he has to indicate on the plans how big the floor joists are, and how often they should be placed?  He calls a structural engineer, or looks it up in a book, because he has no clue.

A brick-layer could probably build your facade just fine, but he will probably put doors and windows whever he thinks they look good, if someone doesn't tell him where they need to go.

If I had a plan drawn up by an architect, I'd immediately have my contractor and sub contractors look over it and tell me if they think anything is wrong with it.  A good architect probably has a whole rolidex full of contractor types that he asks these kind of questions himself.

The fact is you need some people who can think big picture, and some people minding the details, and some people who have experience getting their hands dirty in the matter, and they all need to talk to each other.

Keith Wright
Wednesday, October 23, 2002

Good topic and good discussion.

A Bricklayer vs. a Software Developer
A Building Architect vs. a System Architect

Imo, these analogies only make sense under very specific conditions.  Blue collar construction workers (sheet metal worker, plumber, carpenter, landscaper, electrician, etc.) tend to have very well-defined work roles that are consistent throughout the construction industry.  That is, whomever, Bob the master electrician winds up working for he knows that he will not be asked to do the work of a plumber unless he has received the proper training, etc.  I believe the same thing can be said of Kevin the Building Architect as well.  I don't believe Kevin the Building Architect would be allowed to perform the same type of work that Bob the master electrician does no matter how badly he wanted to do it.

Like many other types of IT workers, some programmers simply don't have any say in the matter when it comes to the type of work that they are asked to perform for an organization. 

Note: This is one reason why during certain times in my past, I have found it extremely difficult to explain to my friends and family what I currently do for a living.  It all depends on the situation I find myself in at the time.

one programmer's opinion
Wednesday, October 23, 2002

Jed, you have highlighted a big issue and a big problem, and the correct response is just to stay away from dumb companies with dumb processes.

It is obvious that experience in and knowledge of software development is important for designing software. Experienced programmers make much better architects and project managers than those without that experience.

The situation that currently prevails in IT is like surgical teams being led by accountants or sports coaches ( since the sports coaches know how the patient should perform after the operation.)

I think that, as the industry becomes more mature, there will be better recognition of these things.

Just Do It
Wednesday, October 23, 2002

I have never bought into the whole software is construction metaphor anyway.

An architect is useful when you need standardized plans for plopping down cookie-cutter tract homes using semi-skilled labor. The plans are critical so that the construction of each house is consistent and of fair quality.

This advantage is irrelevant to software -- all copies made of software are the same and are mechanically duplicated at zero cost. There is no semi-skilled labor producing the Cds.

The most awesome houses I have seen are the ones in which the home owner, not knowing he is unqualified and insufficiently educated, keeps adding on and improvising and having fun until the house is 'something else'. My next door neighbor is one of these people -- his house is built out of raw barnwood and features caves, trellises, indoor gardens, trap doors, secret passageways, rooms in which the floors are suspended by cables, etc.

Another friend who is a mathematician built his 4500 sq.ft. home with no plans and only a pregnant wife as a helper. It features vast rooms, pillars, alcoves, arches, cubby-holes, and exotic ceiling designs.  He gives concerts in his home to large groups of visitors including world-renowned celebrities. One of these celebrities hired him to design his own home and he did a great oncore. He has no training at all in architecture or carpentry and his tow designs, both largely improvised, are among the most beautful and elegant homes I have ever seen.

What happens when an architect improvises from day-to-day? Well, you have the Emprie State Building. The plans for floor n+1 were continuously being drawn up as floor n was actually being built. This also works against the argument that it's OK to improvise on small projects but not big ones.

Or look at the work of renowned architect James Hubbell. His designs look like something out of Lord of the Rings and are improvised.

It's only necessary to create a design in advance if you are going to be executing (building) that design many many many times, as with our tract home example. If you are only going to build it once, as is the case with software, improvising as you go along provides the best designs. But you have to be good to do this. You have to have that creative spark and that ability to create structures out of nothing.

X. J. Scott
Wednesday, October 23, 2002

X. J. Scott wrote:

"The most awesome houses I have seen are the ones in which the home owner, not knowing he is unqualified and insufficiently educated, keeps adding on and improvising and having fun until the house is 'something else'. My next door neighbor is one of these people -- his house is built out of raw barnwood and features caves, trellises, indoor gardens, trap doors, secret passageways, rooms in which the floors are suspended by cables, etc."

Most of these houses are only awesome if you don't have to live in them. If you do, you have to be the owner/builder to appreciate it. Not because of style, BTW, because that differs from person to person regardless of the designer.

I own a house built by the type of person you describe.

- It had two doors to the toilet, because he thought it was convenient. I don't. In fact, most people don't because now you have to lock two doors if you have guests.
- Some doors swing the wrong way (compared to where the light switch is, or other doors).
- Some windows open the wrong way.
- Electric outlets are placed at inconvenient locations.
- The roof of the second floor was to low (for us).
- There were too little or too small windows so parts of the house were too dark.

There are many more things. We fixed most of them. Most of them would never have needed fixing if they were properly designed. That requires specialist knowledge or at least experience, some of which is provided by an architect, some by an electrician, some by a plumber. Sometimes explicitly, sometimes implicitly, if you happen to be one. But without it, you are left to chance.

Erik
Thursday, October 24, 2002

"Or look at the work of renowned architect James Hubbell. His designs look like something out of Lord of the Rings and are improvised."

But can you live in them? How long until the novelty wears off and you get tired with the damn walls being so slanted you can't buy regular furniture? Or always needing the lights on in parts where the cuteness did not allow for a window?

How many people would actually want to live in such a house?

Erik
Thursday, October 24, 2002

X. J. Scott,

Please tell me your post was meant to be a joke. 

"An architect is useful when you need standardized plans for plopping down cookie-cutter tract homes using semi-skilled labor."

What you wrote here is true.  This is one instance where an architect is useful and needed.

"The most awesome houses I have seen are the ones..."

Most people who have the money and decide to build a custom built home don't even think twice about hiring a building architect.  To them not doing so would be a very foolish decision.  Oh, and those semi-skilled laborers you mentioned in your post would be building this custom built home as well.  Many of them would be doing so at a very nice hourly rate.

"This advantage is irrelevant to software -- all copies made of software are the same and are mechanically duplicated at zero cost."

<sarcastic mode>
I see so you are one of those people who believe that the design is always in the code?  Have you ever worked on a medium or large size software project (open source doesn't count) or performed maintenance on an existing one?  What about a decision support application?  Do have the skills to create (from concept to code) such a software application for a small organization all by yourself?  If the answer is yes, how may I ask are you able to accomplish such a feat? 
</sarcastic mode off>

Although you can build a software program/system or a home without a blueprint that doesn't mean you should.

one programmer's opinion
Thursday, October 24, 2002

David,

I'm studying for a Post Graduate Diploma in Computing for Commerce and Industry with the Open University - http://www3.open.ac.uk/courses/bin/p12.dll?Q01C02

Afterwards I can do a dissertation to gain a Masters.

I'm thinking this might make a good topic for the dissertation.

Ged Byrne
Thursday, October 24, 2002

>> I see so you are one of those people who believe that the design is always in the code? 

Linus Torvalds thinks this to be true, and has stated exactly this.  But that doesn't mean that a coder doesn't think while coding or that he/she doesn't have a plan.  Architecture via the C language is more valid than any other syntactical model - because it is complete.  The code fully describes the behavior.  If you think better in text mode, so be it.

What is being argued on this thread is not that you don't have a plan, but that a plan by implementors is somehow invalid.  To me, that's bull.  This does not rule out the role of an architect, it merely empowers implementors to architect as well.

A software architect must, IMO, posess a unique skill beyond what is expected of a good implementor.  Encryption/Secruity, multimedia, algortihms, processor architecture,  ... - there must be some aspect which the architect for a particular project must have a unique grasp of the material beyond that of the implemetor for the architect to add value.  If he/she doesn't add value, then they are detracting from it.

Nat Ersoz
Thursday, October 24, 2002

Don't like the company value scheme? Start your own. Let the techies rule, give them all they want, and hire people they like yourself. Works for Microsoft.

Just me (Sir to you)
Thursday, October 24, 2002

The bottom line is that if the developers are complaining about the architect, the architect is bad.

The second bottom line is that any company with a hierarchy in which non-programmers dictate programming ( i.e design ) decisions to the developers is a company in trouble. Look around.

Just Do It
Thursday, October 24, 2002

It does look like natural selection is taking hold.

Companies with a bad attitude to their technical staff are losing good people (they lost me:), and this is making a real difference to their performance.

I see this as a ray of hope.  The optimist in me sees these companies all failing, and a new generation of better companies emerging.

Of course, I learnt to ignore the optimist in me a long time ago.  He's usually wrong.

Ged Byrne
Thursday, October 24, 2002

"Linus Torvalds thinks this to be true, and has stated exactly this. "

So what.  I have heard several notable XPers say the same thing.  That doesn't mean their opinion is right or wrong.  Sometimes, I cannot see the big picture (at least not without a lot time being spent stepping through code) without written documentation.  Of course, this leads to questions such as, "What is useless documentation?  What is essential documentation?" which I won't go into since it is an off topic subject.

"But that doesn't mean that a coder doesn't think while coding or that he/she doesn't have a plan."

I agree. 

"What is being argued on this thread is not that you don't have a plan, but that a plan by implementors is somehow invalid.  To me, that's bull."

Yup.  That is the main argument that is going on. 

"This does not rule out the role of an architect, it merely empowers implementors to architect as well."

I find empowerment to be a tricky concept.  As a raw newbie programmer, I didn't want empowerment.  I just wanted someone to hand me a spec and let me code.  When I worked for a small company, empowerment meant we can't afford to hire someone so this task is now your responsibility.  It seems that empowerment as it being discussed in this thread only applies to corporate software development situations where there is a lot of specialization going on.

one programmer's opinion
Thursday, October 24, 2002

The hard part is not seeing an architecture in your head. It's effectively communicating that architecture to others on a team that is difficult. I believe in using the least amount of documentation possible to convey this message.

I also believe that any architect should be a coder on some level. They must have a very sharp sense for what is possible and what isn't and have the ability to communicate the plan to other developers.

Ian Stallings
Thursday, October 24, 2002

> Suddenly, your pretty list of requirements doesn't list half
> of the features the software needs and nobody has had
> time to maintain that list. Over time, the list is ignored
> and you're back to the "Cowboy Coding" techniques.

And then, onde day you're going through a funtional test session with your users, and they're asking "Why isn't X done yet?", and "I reported this bug weeks ago and it's still here", and "Shouldn't we be able to export thias data? I remember we talked about this feature. Isn't it supposed to be done?"

And you have no idea of what's supposed to be done, and what's scheduled for the current dev phase, and what's scheduled for the next dev phase.

And, beacuse the users (and their bosses) want an answer, you spend about 2 weeks reading lots of docs with change requests (because you've got no process to handle these), and trying to remember when things were decided, and what priority they got, and looking for mails that may give you some kind of clue, etc, etc, etc.

Is the usual dilemma: You can choose between a "lightning-fast process" that doesn't work, or a slower process that can give almost any piece of information you need when you need it. Unfortunately, we're usually forced to choose the former, in order to bring our piece of beta crap... er, I mean "finished software" to market ASAP (these days, the meaning of this FLA is "before it's done").

Anyway, we've been having such great results with this method, why should we want to change it? ;)

Suravye ninto manshima taishite ("Peace favor your sword")

Paulo Caetano
Friday, October 25, 2002

I'm not an XP advocate myself, but the more you look into the more it make sense.  Like the post above, I prefer to be pragmattic, not extreme.

-----------------------------------------------------------------------
I find empowerment to be a tricky concept.  As a raw newbie programmer, I didn't want empowerment.  I just wanted someone to hand me a spec and let me code. 
------------------------------------- One Programmer's Opinion
XP addresses this with Pair programming.  Empowerment is taught rather than dumped.


-----------------------------------------------------------------------
The hard part is not seeing an architecture in your head. It's effectively communicating that architecture to others on a team that is difficult
----------------------------------------------------------- Ian Stallings
XP uses a system Metaphor for this.  This is quite effective, since a useful metaphor is also good for the user and will usually lead to an accessible user interface.

My main distrust of extreme is that it is lay out in the form of commands that must be obeyed.  I prefer to understand the principles involved, with the XP zealots don't always explain so well.

Ged Byrne
Friday, October 25, 2002

-----------------------------------------------
Suddenly, your pretty list of requirements doesn't list half of the features the software needs and nobody has had time to maintain that list. Over time, the list is ignored and you're back to the "Cowboy Coding" techniques.
------------------------------ Mark Hoffman

In Code Complete, Steve McDonnel advocate's 'Self Documenting Code.'  However, this seems to be much more difficult than it sounds.

You can use comments, certainly, but thats just as difficult to maintain as the Word documents.

The ideal, of having the code so well constructed that the documentation really is in the code, seems to be elusive.

Has anybody had any success with this?

Is the XP approach, of having the requirements coded in the form of unit tests, more obtainable?

Ged Byrne
Friday, October 25, 2002

Most of the comments I have seen sofar address the problem from the programmers point of view. Of course you are never going to find any reasons to do anything beyond commenting code. A programmer doesn't need much more. The design is transient until it is written in code. Once done, the programmer does not need the design.

But programmers are not the entire universe. In fact, like it or not, coding is not that interesting to anyone else but a programmer. Do you think a user cares about coding? Do you think a client does?

The point is, no product is defined by the mechanics that produce it, not should it be. There are many other ways to create useful products or systems that do not involve any coding whatsoever. There have been for millenia.
People have always been creating artifacts to assist our minds and bodies. Software systems are just the latest feat.

Creating artifacts that assist our minds or bodies, or by extension, our society, is about defining, communicating, adapting, designing, and finally, producing.
You have to know which problem you have to solve before you can solve it. You have to know about potential solutions and there merits, before you can choose one. You have to know about the solution, before you can producte it. It is nothing special to software, it is universal and just plain common sense.
There are always circumstances when all of this can be done on the fly, without much though, communication and thus documentation. But whenever something outgrows merely the trivial, you have to know some things in advance, and not just in your head.
Others will have to do other things based on what you are going to produce. Others might have to continue what you started. Others might have to improve what you created.

In fact, it baffles me how anyone can be so narrow minded to think that no-one needs to know about what you are doing until it is done. And that others should have to accept that the only way to do anything but the trivial to the product afterwards, is to reverse engineer it.

Only because writing tons of documents that shoot way past their goal is stupid too?

Erik
Friday, October 25, 2002

> But programmers are not the entire universe. In fact, like
> it or not, coding is not that interesting to anyone else but
> a programmer. Do you think a user cares about coding?
> Do you think a client does?

You're right. Most clients just care about "I want a product with this functionality set ready by this deadline". And, most of the time, the vendor doesn't object to anything, and signs up for the impossible, knowing that, otherwise, some other vendor will do it (ah, the benefits of competition). I won't describe the rest of the process, since Steve McConnell has already done it.

> There are many other ways to create useful products or
> systems that do not involve any coding whatsoever.
> There have been for millenia.

Yes, but how many of these products or systems have been perceived as "low cost to change"? How many have had to acommodate for fundamental changes during their production, while being required to maintain deadlines? How many have began production without a clear definition and scope?

> You have to know which problem you have to solve
> before you can solve it. You have to know about
> potential solutions and there merits, before you can
> choose one. You have to know about the solution, before
> you can producte it. It is nothing special to software, it is
> universal and just plain common sense.

You have to convince your client that the time you spend in these activities is an investment, and not a waste. And plain common sense is a rather non-universal concept.

Suravye ninto manshima taishite ("Peace favor your sword")

Paulo Caetano
Friday, October 25, 2002

"You have to convince your client that the time you spend in these activities is an investment, and not a waste."

That is only true as long as you have to compete with others who leave that investment out of their calculation to get the project. The customer will pay for it in the end. It's a sign of an immature market and it is to be expected due to the infancy software development is still in.
But things won't change as long as no-one get's smart. People are already getting tired of projects going over budget (in time and money).

In a mature market you do not have to convince your client of costs for preparation. In fact, they are not even made explicit, but accepted implicitly as common sense.

No-one expects a builder to start building your house without preparation. You would expect to see plans before they start.

Besides, none of this is an issue if you build consumer products, because there is no such client you have to convince.

In the end though, the cost is always all yours. Because you have to deliver to the agreed price when it took a lot more than you initially guessed. Or because you loose the next project on account of the failings of the previous.
Maybe you'd have been better of not getting the project in the first place because you were 'too expensive' buy giving a reasonable calculation, as opposed to a guess based on cowboy practices.

Erik
Friday, October 25, 2002

Erik, you don't understand software development.

In your comments, you discuss the process of programming as if that is the sole representation of the programmer's expertise. For example, you say that programmers' idea of design is to document the code. That's not correct.

Those of us advocating the importance of software development expertise in design are saying that the design tasks will be performed better by programmer designers than by business executives or others without software expertise.

That is, the design will work better, be cheaper to build, be easier to maintain, and be better for the customers too.

You also refer to programmers as the "mechanics" of the design. No. We are the designers, Erik.

Just as the architects of buildings must understand about buildings, space, materials and living, so software architects must understand about functionality, extensibility, robustness, scheduling, perormance, users and design. The people who understand this are people with software expertise, being programmers.

Must be a manager
Friday, October 25, 2002

The computer is the brickie.  And programmers often like treating them like slaves.  (Occasionally they riot.)

I'd guess the definition of a programmer is someone who can automate things.  Via machine.

Tj
Friday, October 25, 2002

"You also refer to programmers as the "mechanics" of the design. No. We are the designers"

This is exactly the point.  No one is advocating the elimination of design, documentation, process or structure.  All that is being argued is that software engineers (previously refered to as programmers) are the architects.  What needs eliminated is the culture which attempts to limits engineers' talents to "keyboard jockey".

Again, IMO, the only need for specialized architects occurs when dealing with specific areas which require specific expertise - and often an advanced degree or years of industry experience:  processor architecture, crypto, communcation theory, algorithms, ...

And... "If you aren't smarter than our engineering team, get the hell out of the way."  That should be the culture of any company which produces technology driven products.

Nat Ersoz
Friday, October 25, 2002

Must be a programmer wrote:

"Erik, you don't understand software development. "

Of course I don't.

"In your comments, you discuss the process of programming as if that is the sole representation of the programmer's expertise. For example, you say that programmers' idea of design is to document the code. That's not correct."

I did not say that. I said that those who think that documenting only in code is good practice, are not appreciating the other disciplines involved in product development.

"Those of us advocating the importance of software development expertise in design are saying that the design tasks will be performed better by programmer designers than by business executives or others without software expertise."

That is only true as far as technical design is concerned. Product development does not start with technical design. Product development starts with assessing the purpose of the product and the context in which it is being used.
The first activity to follow that is to craft a solution that fits the purpose and the context. Technology is not involved in that other than to serve as a constraint on the possible solutions.

Once the solution is acceptable, technical design and coding - for as much as software is involved - get started.

Programming expertise, nor business expertise is sufficient to design a product that fits it purpose. Although programmers at least have the tools to build something that might resemble the purpose, those who get close do so because they have explicit or implicit appreciation for non-technical design.

To use our analogy, architects need appreciation for space, light, accessability, style. Engineers design the structural properties to make the architects design buildable. The architect needs to have sufficient knowledge, or support, to avoid designing structures that can't be built.
Software engineers (programmers, architects) usually think of desing as creating structures to support the product's function, but who designs the product's function?

Erik
Friday, October 25, 2002

"Is anybody else fed up with the way that programmers are considered 'Brickies.'"

Ged Byrne,

I think your post can be summed up with the following words -- Where is the RESPECT?

Personally, I don't see how going back to school to get your masters is going to change the lack of respect problem you seem to be encountering. 

What type of corporate IT position are you seeking to obtain with your newly minted degree?

I believe one of the reasons Joel Spolsky decided to start his own company was to get away from the corporate idiocy that so many IT workers have encountered in their career.

Have you ever read this book, "The Career Programmer - Guerilla Tactics for an Imperfect World"?  The book was written by a corporate contractor.  I enjoyed reading this book, however, the only thing I got out it is that corporate IT departments are screwed up everywhere so deal with it or do something else for a living.

Charles Kiley
Friday, October 25, 2002

----------------------------------------------------------------
Personally, I don't see how going back to school to get your masters is going to change the lack of respect problem you seem to be encountering. 
-----------------------------------------------  Charles Kiley

I'd like to refer you to  Brickie turned Builder's post of Wednesday, October 23, 2002.

The main way to get away from the 'lack of respect problem' is to stop being a programmer.

Then I can get a job that will pay enough for me to start saving for the day I can go it alone.

To be honest, I returned to studying with a rather cynical attitude.  Expecting to obtain nothing more than a piece of paper that was needed to open doors.  I've been pleasently surprised by how much I've actually learnt.

Ged Byrne
Friday, October 25, 2002

Erik, when I talk about design, I am not constraining that to the items you identify as "technical design." This is the nub of our difference.

You have a mental model that says programmers just do the final bits after someone else has done the design. I say to you that, in serious software development at any rate, that design will be conducted by experienced and good software designers ( programmers, software engineers.)

Erik, I think your experience is probably in a small web studio or multimedia outfit doing CD's with Director. Something like that.

In the professional software space, software experts are the ones with the "appreciation for space, light, accessability, style." You keep attempting to map titles across from the building industry, but do so inaccurately.

Must be a manager
Friday, October 25, 2002

A good example of the importance of programmers in software design is provided by the experiences of the big advertising agencies during the dot com times, when they were setting up interactive / new media divisions.

Ad agencies have strict hierarchies where writers and art directors create ideas and then production departments implement them. Most ad agencies initially tried to treat interactive as just another production department, expected to implement the "ideas" generated by the creative teams.

They quickly found that those ideas were boring in the new media, and often didn't work well either, and usually took no account of the things that software and the web are all about. Also, they had trouble hiring good programmers, especially because production was meant to be a subordinate department where the staff earned much less than the "creatives."

Pretty soon, the "creatives" would ask the programmers for ideas, while still taking credit for the ideas.

Eventually, the big agencies mostly failed in creating interactive divisions, and instead went out and bought successful software houses and web studios, which had a much better grasp of how to develop interactive media.

The moral is: apply inappropriate business models at your own peril.

Must be a manager
Friday, October 25, 2002

Hi Ged,

Well, I am not sure what your major is or the type of position you are looking for, but I wish you the best of luck.

I can't believe that ITT Tech or some other bogus technical college hasn't created a TV ad already for Software Architect training.  I can just picture the pitch going something like this:

You too can become a great software architect..... 
You will learn to define architectures that leverage today's best design patterns......
Upon graduation, you will be able to lead technical organizations to successful implementation!
......
Call now.

Charles Kiley
Friday, October 25, 2002

"You have a mental model that says programmers just do the final bits after someone else has done the design."

Your words, not mine.

"I say to you that, in serious software development at any rate, that design will be conducted by experienced and good software designers ( programmers, software engineers.)"

Product design is done by people who appreciate the user's perspective. Who know how to link activities and tasks to goals. Who know how people process information and perform the job that the tool is supposed to support.

As I said before, neither commercial or marketing expertise, nor engineering expertise gives you that capability. Marketing concentrates on demographics, buying decisions, budgets. Engineering concentrates on performance, scalability, and other technology aspects. This is not a bad thing. It does not make the one inferior to the other. But neither qualifies you to design the interaction between the user and the product.

"Erik, I think your experience is probably in a small web studio or multimedia outfit doing CD's with Director. Something like that."

You should stop concluding things, because you appear to be missing the mark with great excelence.


"In the professional software space, software experts are the ones with the "appreciation for space, light, accessability, style."

Of course they are. Which explains why so many people have so much fun and ease using the software these experts build.

Try to understand this; a software expert might very well have this appreciation, just as a plumber might also have learnt to be a good carpenter. But learning to be a plumber does not prepare you for carpenting. They require different knowledge, different interests.

So too with software design. To be a good designer you need to know about data structures, algorithms, scheduling, anything that maps to computer technology.
People are not computers, so they need different treatment. That is why good software has several models of which one is the user's model of the problems being solved.

"You keep attempting to map titles across from the building industry, but do so inaccurately."

Whatever. Proof by repeated assertion.

Erik
Saturday, October 26, 2002

The problem I have with the architect and designer layers is that there is no standard product like the blue prints used in construction.

It appears to me that blueprints are checked and refined to the point that a "brickie" will have little problem doing the work.

The blueprints can be reviewed and evaluated by independent parties and could be used to determine the quality of the design.  It may even be the case that developing the blueprint will point out problems in the design. 

In my experience none of that happens in software design, if the spec is vague the programmer still has to make it work.  I can't say I implemented the design and call it a day.

The feedback loop for software architects and designers is almost non existent.

John McQuilling
Saturday, October 26, 2002

Somebody once said that if you get a house built by a plumber the whole design will hinge around the pipes.

You have an architect to design a house because he is the customer's representative; he is there to ensure that the house is butil according to the customers needs in all respects and not according to the agenda of the particular specialist. He also has to make a practical design out of the clustomer's desires, and work out the trade-offs to stay within budget.

XP gets rid of the customers representative (the architect) by actually having a real customer rerpesentative on site throughout the process. I suppose the real motivation is that most Project Managers/Software Archtitects are so hopeless, that you're actually better off with a customer representative who knows they haven't a clue to strart with.

However the fact that a job is often badly done does not mean that it is rubbish. Rather the opposite; if Gedd looks carefully  at his claim that software archtects have a real cushy number, and the fact that he's never found one who is capable of dioing the job proves it, he'll realize the fatousness of it. To claim that it is pointless having managers respionsible for the overall design because the job is impossibly difficult would be more logical at least.

Just take something as simple as a database for a college or university. Hardly rocket science, but you need first of all to find out the data that is going to be stored, then check out everybody's work flow to see that you haven't missed anything  (and if like the programmer at our college you tell me there is no problem there because you got all of the chairmen to sign a form saying this is what was required then you're living in cloud cuckoo land), then try and see if there are things not asked for which the system will make possible and which should be antiicipated now.

Then you need to work out the basic table structure, work out the queries needed, and then work out the user interface and the glue that will allow the user to move. And of course the seciurity model must be though of, and a prototype worked out to make sure there are no disasters caused by too strict a model, or too much data validation.

Then the thing has got to be written by the programmers. And of course you will probably find that you will want the programmers split into those  develloping the back end (who will need to be SQL experts among other things) and those doing the front end (who will probably be using VB for most of the work).

A good SQL programmer, or a good VB or C programmer does not per se have this training. He may have, but the person who normally ends up with the design job is a little bit of a jack of all trades; he or she needs to understand the implementation considerations but does not need to be a guru coder.

Stephen Jones
Saturday, October 26, 2002

Erik,

While "must be a manger" guessed "Art Studio Director" or something akin to that, I'm guessing merely that at one point in your career you were an Andersen Consultant.  Perhaps even now.

Only a consultant could carry such a narrow view of people as to try to herd them like cattle.  You fit the bill - and as you know and have learned over the years, yes incompetents can be herded.

I'm only glad its you that lives in that world.

Nat Ersoz
Sunday, October 27, 2002

---------------------------------------------------------------------------
If Gedd looks carefully  at his claim that software archtects have a real cushy number, and the fact that he's never found one who is capable of dioing the job proves it, he'll realize the fatousness of it. To claim that it is pointless having managers respionsible for the overall design because the job is impossibly difficult would be more logical at least.
------------------------------------------------------- Stephen Jones

Stephen,

I did say 'their are good architects out there.  These individuals really are worth their weight in gold, because they are so rare.  ' (I've corrected a few typos :)

Good architects have a real hard time, and when I've worked with them I've really appreciated what they do.

It is the faking architect who has a cushy number.  Spouting the type of technical mumbo jumbo normally reserved for cosmetic commercials, they are usually loved by the non technical types.

It is almost impossible for the non technical people to tell the good architect from the fake.  Not until it is too late, that is.  Even after the project has failed, they can dodge responsibility.

The only people who can really make this vital distinction is the programmers.  They can tell one from the other easily.

However, because the programmer has such a low status, their recognition is not recognised.

Ged Byrne
Sunday, October 27, 2002

There are fakes everywhere. However you do have a  point that in IT fakery is carried to extremes. After all IT is the only known field in the whole of economic history that has not bought about even a 0.1% in productivity for all the money thrown into it (the figures cover 1945 - 1998 pprox). And considering hpw much of the corporate world swallowed the dot.com black tulip bloom (remember when every single Dixons and PCWorld High Street Store was not worth a dime because FreeServe which was wholly owned by Dixons was actually worth more than its holding company), then we'll have to resign ourselves to the idea that hot air rises.

The problem however lies with the guy he's reporting to. If he can't see through bullshit then everybody below him is scuppered.

I doubt if the contempt for the programmer is as common as you make it out to be

Stephen Jones
Sunday, October 27, 2002

"While "must be a manger" guessed "Art Studio Director" or something akin to that, I'm guessing merely that at one point in your career you were an Andersen Consultant.  Perhaps even now."

Guessing does not get you anywhere. I just hope you two do not guess as much about the people for whom you create your products.

"Only a consultant could carry such a narrow view of people as to try to herd them like cattle.  You fit the bill - and as you know and have learned over the years, yes incompetents can be herded."

You have a nice attitude towards people. Keep up the good work.

Erik
Sunday, October 27, 2002

Hi Erik, what software tools do you use to design your CD's? Who do you think designed those software tools?

And if Stephen Jones really believes that IT delivered less than 0.1 percent productivity growth, please type out your next post and send it via registered mail to Fog Creek, NY.

Must be a manager
Sunday, October 27, 2002

Sounds like I struck a nerve.  Consultant it is.

Nat Ersoz
Sunday, October 27, 2002

Nat and Would Be Manager. You can carry this dialog without my contribution. It appears you can both find out so much about a person without so much of a hint of information, what would you need me for.
I have no need to continue this because I can find no evidence that either of you have read anything I have written, let alone understand it. Even when I consider that my English may not be well enough and that I may have expressed myself rather clumsily.
You have no idea how far off the mark you are and I see no point in countering your arguments, if you both continue to assign properties or statements to me that I neither have nor aspire. I find no satisfaction in name-calling.

If you consider this your victory, please go ahead and bask in the glory.

Erik
Monday, October 28, 2002

Your english is excellent. 

Nat Ersoz
Monday, October 28, 2002

Dear "Must be a manager",
The fact that fifty years investment in IT has not yet (unless things have changed very recently) produced an increase in productivity is a well known economic fact, and has always puzzled those who haven't just brushed it under the carpet.

The fact that my emaiiling a letter will be more "productive" than sending it by registered mail. proves nothing. There would only be an overall improvement in productivity if the time saved was greater than that lost by reading spam, having an IT department to handle the network, learning how to operate the computers and a few other things. And as we are talking about an overall increase in productivity even if this were true in my case it wiould still have compensate for the other people/companies where this was not true.

However your reference to paper mail does touch on one of the reasons why there is no increase in productivity. The ubiquity of computers has actually resulted in an increase in the amount of mail sent. Ask your father or grandfather how often they got letters from the bank, telephone company or power company fifty years ago. When an email system is introduced in a company the consumption of paper goes UP by 50%.

What happens is that computers do not replace the old way of doing things but for a considerable amount of time we see both running parallel. Eventually the old way dies but then there is a new wave of investment and this eats up the profits that were starting to be made from the old one.

Stephen Jones
Thursday, October 31, 2002

*  Recent Topics

*  Fog Creek Home