Fog Creek Software
Discussion Board




Beyond coding?

In a separate tread Sherlock Joda touched on the position of non-coders in the software construction process.
You see, being more "senior" to put it politely (that can mean anything over 25 I guess), I am beyond the point where I can afford to spend time on every project involving myself in everything down to the coding level. Still, I try at least for one project every year to take part in the actual implementation process. Although I find it intellectually stimulating and general fun to do this, that is not the sole reason.
Before I got into this habit, I tried to keep up-to-date about new technologies through reading. While this gives you a good broad picture, I noticed I tended to slip up more and more when it came down to estimates of how much work would really be involved in something. Sometimes I underestimated because technology X was described as making project Y extremely easy, whereas in reality anything beyond the constraints of the small demo required Herculean needle in a haystack type configuration and low-level extensions. Sometimes I overestimated because I had not noticed that what once would have required a major development effort was now part of the base platform. A second thing I had noticed before was that most of the people climbing through the ranks actually became dangerous liabilities to a lot of projects. This happened because as they became more and more remote from the technological aspects, there tech skills soon entered that twilight zone where they still knew just enough to be dangerous. A lethal weapon when combined with increased confidence and authority.
So now every year, I take the implementation of a part of one project on myself. I of course tend to choose things with the newest and sexiest stuff (hey, one of the perks ...)., things I want to know more about. Over the last few years this has been Java, XML, PHP, .NET, C# etc.
Although this is not always easy, since there are a lot of other things calling for attention, and the infrequency and selection of topics makes that I am always in "learning mode", I feel it still is the only way to not "loose it".
Anyone with a better idea?

Just me (Sir to you)
Tuesday, July 30, 2002

I think the best thing you can do is to let go.

No matter how hard you try, your never going to understand the new technologies as well as somebody who deals with them day in day out.

Instead of learning how the new technologies work, instead conentate on learning:

1 )  How to design and communicate at the level of intent.

2 )  How to listen to the people who do userstand the technologies.

My Dad once said that he always preferred an upper class boss who had never seen a days work, because that type knew how to stay out of the way.  You may have to be British (with all our class tie ups) to understand.

Ged Byrne
Tuesday, July 30, 2002

Ged, I hope you don't really believe yourself.

What new technologies are you talking about that are hard to grasp? There isn't anything new about Java, XML, Aspect Oriented Programming, .NET,  and just about any other buzzword.

The details are new. They always are, and it is in their nature to change. And for some projects, (e.g., writing a device driver), you need to know the details good enough that it has to be your speciality.

But in general, it's only as new as you believe it to be. Master Lisp, virtual machines and basic data structures and algorithms, and you're set for the next 20 years. (But when I say master, I mean master - e.g., be able to implement each from scratch).

Ori Berger
Tuesday, July 30, 2002

Joe AA is quite against the term "architect".

Me? I'm merely suspicious.  Here is why:  why don't we have the software title "Debugger" or "Bug Finder"?  Because its grunt work.  But what is worse is fixing bugs someone else created.  Worse than that is working within a framework which is *busted* that someone else came up with.

OTOH:  I have worked some really good "non-coders".  We have a small group of people we sent to ISO commitee meetings: who never wrote a line of code, but helped define the standards.  It turns out that this was a unique experience - it has never been replicated iagain in my work history.  These guys were very good communicators, worked welll with customers and partners, and technical experts in their subjects (PhD in video compression for example).  Recently, I met a rep from one of our partners who emulated this perfect mold of "expert architect" (also a PhD in his field).

Anyhow, I think that architect should be limited to these areas of expertise which most mortals never acheive:  specific areas of expertise not graspable by the above average engineer or programmer.  They would include: encryption and/or security, audio/video compression, communication theory, ... 

I personally have never seen the need for, nor ever worked with, a software architect who did not write code.

Nat Ersoz
Tuesday, July 30, 2002

If you don't want to "get in the way" of the project by coding something others are dependent on and then not having time to finish it, try building unrelated tools to help your company. Task management tools, customer support tools, sales tools, etc. Software is so versatile that you can use it to do many things to help your company, learn something else along the way, and avoid causing trouble to your team's "core" project.

Humbug
Wednesday, July 31, 2002

Ori,

Its the details I'm talking about.  As you say, the logical elements do not chage, but the implementation details do.  When the manager leaves coding they are best if they stick to the logical elements and learn to use these real well, leaving the ever shifting implementation details to those that deal with them.

You speak of data structures, but do you believe that a spec should state that the customer should be implemented in a linked list indexed by Membership number, with a binary tree index to the post code?  Surely a spec should state that customer has a Name, Address, PostCode and Membership number and leave the actual implemenation to the implementors.  Few projects now implement data structures, they use a relational database.  What indexes to use is best devised based on what reports are needed and detailed profiling.

I do, however, fully agree that every body involved should know how to implement both a linked list and a binary tree.  I've invested a lot of time to it myself.

To give an example, on one project I once had a manager who prided himself on understanding the implementation detail, and answering all of our questions in his specs.

On one spec, for example, we had a database that would import data from two different sources.  Source X and Source Y.  Both source contained fields A, B and C in common.  Sometimes A, B, or C would be both, X and Y, sometimes just X or just Y

While we programmers would have normalised the data, and create a relational database from the data, our tech savy manager had better ideas.

The spec included not only the exact design of the single flat file that would contain all data, but also exact details of what 'Filler' values would be used when field were missing.

Because the spec was all signed off, we had to follow it exactly.  The manager in question was horrified at our lack of appreciation when he had 'done our job for us,' and wouldn't even consider that there might be a better way.

Ged Byrne
Wednesday, July 31, 2002

Ori Berger wrote:

"But in general, it's only as new as you believe it to be. Master Lisp, virtual machines and basic data structures and algorithms, and you're set for the next 20 years. (But when I say master, I mean master - e.g., be able to implement each from scratch). "

But this is exactly what I could do without digging into the new tech. That stuff is peanuts (Btw: your example of writing a Lisp interpreter is really beginners stuff, as is a simple VM and basic data structures). It is not the general big picture I'm after. I am quite confident I got that nailed down pretty well. What I am looking for is which devils lurk in the details of a new technology. Given today’s tools, how fast can we implement our distributed framework on top of Web Services? What is the reality of the I in WSI? This prevents me from blurting out things like "Hey, I ran your Java code on my iBook last night. Seems like you have a lot of work left".

Just me (Sir to you)
Wednesday, July 31, 2002

Ged Byrne writes:

"No matter how hard you try, your never going to understand the new technologies as well as somebody who deals with them day in day out."

Depends. I feel that in my dives I get to grips with the tech better than some, worse than others. See also below.

"Instead of learning how the new technologies work, instead concentrate on learning:
1 ) How to design and communicate at the level of intent.
2 ) How to listen to the people who do understand the technologies."

(1) Assumes that you are in control of teams of all excellent coders. Sadly this is not the case, and will not be the case in the foreseeable future. The challenge is generally not to get the best result given an all-star team, but to get the best result out of the team that is on hand.
(2) Assumes you have access to trusted independent experts. Should I become more trusting? Maybe, but I'm not ready for that. Experience teaches me there are not many "experts" that are trustworthy.

Just me (Sir to you)
Wednesday, July 31, 2002

-------------------------------------------------------------------------
Experience teaches me there are not many "experts" that are trustworthy.
------------------------------------------------- Just me (Sir to you)

It seems, then, that knowing your people is more important than knowing the tech.  Isn't this what management is supposed to be about, getting the best from your people?

Ged Byrne
Wednesday, July 31, 2002

Heres an example.  Take a look at the Java Puzzlers.  They are questions that demonstrate quirks in the Java language.  (You might need to register.)

http://servlet.java.sun.com/javaone/sf2002/conf/sessions/display-2500.en.jsp

To successfully implement a java project, I think you need somebody who understands the language at this level.

However, does the manager need to understand?

When it comes to the decisions of fine detail, who should make the decision - the manager or the expert?

Ged Byrne
Wednesday, July 31, 2002

"When it comes to the decisions of fine detail, who should make the decision - the manager or the expert? "

In the end, it will depend on the attitude and capability of the people that you have working for you.  If they are truly an expert and you disagree with them, a few leading questions should hopefully be able to resolve the conflict.  If they are an 'expert' without expertise, you have a much tougher problem to work with.

Programming is an intensely ego-oriented profession, and overriding someone else's decisions can have long lasting impacts on your working relationship - especially if you are doing it from a management role.

I have run into this problem before and there aren't a lot of efficient solutions.  One tact is to let them fall on their face and see if they learn from the experience.  While this is often effective, it normally isn't realistic from a project or schedule point of view.  In a way, this is too bad because people often learn far more from failure than success.

A different tact is to sit down and discuss the problem with them from the point of view where you know 'nothing'.  Ask pointed questions about the consequence of the implementation detail to see if they have actually explored the impact of their decision.

At the end of the day, you might still disagree about the approach, but you should know if the approach will work or not.  From there, it just becomes a question of whether or not you want to drive the project your way or if you will allow the designers some leeway for the sake of team dynamics.  As the manager, it is your responsibility to deliver product but it is also your responsibility to maintain and develop team interactions.  Compromise will be required.

The only times that a manager should consider overriding detail is when the detail is clearly wrong or schedule/personnel/budget constraints prohibit you from doing it that way.

!
Wednesday, July 31, 2002

You said it better than I could have ! .

Just me (Sir to you)
Wednesday, July 31, 2002

Wednesday,

Thanks for your excellent appraisal.  As I said, I see the primary issues of management to be about dealing with the people, but too many managers lack these skills.

I think the biggest problem is when managers concentrate on the technical issues, try to make every decision and micro manage every process. 

The problem seems particularly acute in IT because a lot of poorly structured companies have no technical progress paths.  This means that if you want to rise above a certain level  you need to enter management. 

This means that they have a lot of frustrated techies stuck in management jobs.  Techies may complain about the PHB, but you really miss the manager when nobody is playing the roll.

I'm glad to hear that you value and understand the people skills.  I can see efforts to keep up to scratch on the implementation side a bonus.

Ged Byrne
Thursday, August 01, 2002

Just Me - You sound like the least productive member of your team.

I bet the other guys think you're a wanker.

Alberto
Thursday, August 01, 2002

every senior manager needs to read the dialogues of Plato.

Nevermind listening and communicating. What you need is enough knowledge to ask the right questions.

You can listen to the people who understand the technologies, but unless you are asking them the right questions, you have no way of validating their claims.

There was a joke (african) about some kid, in the rural areas, who was in boarding school, and asked his folks for money. A one off sum for osmosis, and a weekely payment for photosynthesis. Suitably dazzled by the big words, and unable to even begin to ask, the folks paid up.

tapiwa
Thursday, August 01, 2002

No Nat... I am not against the term "architect" (laughing).  If I am against something related to architect, then it would have to be "blind title worship"... which goes for any title you would care to name.

In fact, I like the "operating team" approach mentioned by Brooks in the Mythical Man Month.  Conceptual Integrity, the way a system holds together is something that is created by one mind.  Without the one mind approach, then you get a trash dump result as normally created by committee approaches, and "standards" won't help either.

There hasn't been a lot of innovation in software engineering or computer science.  Most of the tech stuff is buzzword driven based upon the tenants of assembler/compilers, structured and modular programming.  Syntax can always be looked up, and the trick is knowing what syntax to look up. 

If you think about it generally, all languages support the same constructs.  A fancy new name doesn't change what it really is...

Joe AA
Saturday, August 03, 2002

*  Recent Topics

*  Fog Creek Home