Interview
in [Java Help]
|
From: Dave Searles on 4 Oct 2009 16:17 Arne Vajhøj wrote: > Arved Sandstrom wrote: >> In all of these cases there were nuances as well. In the first case >> the vendor officially supported over three-quarters of our installed >> software. If we had replaced the small piece that was flawed with an >> open-source implementation, the argument was that the vendor would >> have refused to deal with any problems related to the entire stack. >> Not inconceivable. That's political, but it's also a decent argument. > > If if the vendor had agreed to support their stuff in the mixed > environment then the time to troubleshoot increases with the > number of vendors. The solution to this is fault isolation: be able to determine what inputs went into which modules when a failure occurred, be able to determine which module got correct inputs but produced a wrong output, and then be able to show that module's vendor the recipe for reproducing the error. The vendors of other components become irrelevant if you can do that. If vendors supply components with a verbose setting or whatever that logs the inputs and outputs, it becomes easy for them to have their customers do this. It becomes easy for everyone to tell if a particular vendor's component did not DTRT, and hard for a vendor to weasel out of it if their component indubitably failed.
From: Dave Searles on 4 Oct 2009 16:22 Arved Sandstrom wrote: > Dave Searles wrote: >> Patricia Shanahan wrote: >>> Dave Searles wrote: >>>> Patricia Shanahan wrote: >>>>> In order for a manager-developer coalition to work well, each has to >>>>> believe the the other has valuable skills and knowledge, and that both >>>>> will do better work, and get more pay increases etc., if they listen >>>>> respectfully to each other and use each other's knowledge. >>>> >>>> This is certainly true. It's a shame that many managers apparently >>>> don't realize this, and hire technical people and then expect them >>>> to just grind away in a dark room somewhere while being kept in the >>>> dark and fed bullshit, their own input on technical matters either >>>> ignored or even actively discouraged/avoided. >>> >>> I've seen it go wrong the other way round just as often. The developer >>> does not listen when the manager says, before the meeting "I believe you >>> when you say option A is technically best, but it is not on the table >>> because of business issues X, Y, and Z." The developer goes on trying to >>> push A, wasting everyone's time and the developer's credibility. >> >> Is it a waste of time? Perhaps the developer is convinced that issues >> X, Y, and Z are outweighed by how much better A is than B. What is he >> supposed to do then, NOT give his honest opinion? THAT would undermine >> his credibility. Lying would undermine his credibility. > > In the current example, the developer has done his best by giving their > honest opinion to that manager. That's how he keeps his credibility. > Nobody is asking him to say that A is the best *technical* solution - > it's not. You're changing the hypothesis now; the original hypothesis was that A WAS the best solution based solely on the technical merits. The developer should basically just be able to say A is way better than B and B is better than C, and using C will probably destroy the project, all based solely on the technical merits, and then let the suits sort things out. > But the developer will absolutely lose respect and credibility if he > keeps on pushing A. That seems wrong: a developer's credibility should be damaged if he pushes something technically inferior to A over A. It sounds like you're talking about some sort of political credibility, rather than the developer's credibility ON TECHNICAL MATTERS. Only the latter should matter, because a developer is hired for the latter expertise, more or less by definition. >>> An effective manager-developer coalition depends on each participant >>> respecting and learning from the other's judgment in their areas of >>> expertise, not just the manager listening to the developer. >> >> When it comes to a technical decision, though, the area of expertise >> in question is the developer's. Managers have no business deciding >> whether to use mergesort or a hybrid insertion sort for the >> edge-sorting in the polygon engine. > > Let me give you another example. You are tasked with fixing a defect in > an application, and investigation reveals that while you could apply a > bandaid in just one area, and a shaky bandaid at that, the technically > superior solution is to fix a core class. A bunch of other areas in the > application use this core class, and while those other areas have not > yet exhibited the defect, they could. > > Here's the rub: doing the bandaid requires no further approval. It's > what you were specifically tasked to do. Testing and deploying the fix > is no big deal. But if you go with the technically superior approach, QA > is going to have to arrange for several days of testing involving a > number of people diverted from other tasks. If you don't seek managerial > approval, and do this technically superior fix under the radar, fur will > fly. Especially if it sneaks into a production build. This should be entirely within the development team's discretion. They are the ones tasked with building and testing something. Anyone who decides that QA for core API should be separate from the developers ought to be shot. QA for user interaction perhaps, but not for internal APIs.
From: Dave Searles on 4 Oct 2009 16:23 Arne Vajhøj wrote: > Dave Searles wrote: >> Patricia Shanahan wrote: >>> An effective manager-developer coalition depends on each participant >>> respecting and learning from the other's judgment in their areas of >>> expertise, not just the manager listening to the developer. >> >> When it comes to a technical decision, though, the area of expertise >> in question is the developer's. Managers have no business deciding >> whether to use mergesort or a hybrid insertion sort for the >> edge-sorting in the polygon engine. > > Don't worry - managers will not tell you what sort algorithm to > use or what indentation to use. > > But they may tell you programming language, platform, external > interfaces, deadline and that the requirements is complete. Platform, what external interfaces can be relied on the be available (part of platform), deadline, and requirements fits in their bailiwick. But the technical people should be able to select the best tools for the job. Managerial approval required only for tools that cost money and aren't already available (so, not for open source tools in particular).
From: Arved Sandstrom on 4 Oct 2009 17:07 Dave Searles wrote: > Arved Sandstrom wrote: >> Dave Searles wrote: >>> Patricia Shanahan wrote: >>>> Dave Searles wrote: >>>>> Patricia Shanahan wrote: >>>>>> In order for a manager-developer coalition to work well, each has to >>>>>> believe the the other has valuable skills and knowledge, and that >>>>>> both >>>>>> will do better work, and get more pay increases etc., if they listen >>>>>> respectfully to each other and use each other's knowledge. >>>>> >>>>> This is certainly true. It's a shame that many managers apparently >>>>> don't realize this, and hire technical people and then expect them >>>>> to just grind away in a dark room somewhere while being kept in the >>>>> dark and fed bullshit, their own input on technical matters either >>>>> ignored or even actively discouraged/avoided. >>>> >>>> I've seen it go wrong the other way round just as often. The developer >>>> does not listen when the manager says, before the meeting "I believe >>>> you >>>> when you say option A is technically best, but it is not on the table >>>> because of business issues X, Y, and Z." The developer goes on >>>> trying to >>>> push A, wasting everyone's time and the developer's credibility. >>> >>> Is it a waste of time? Perhaps the developer is convinced that issues >>> X, Y, and Z are outweighed by how much better A is than B. What is he >>> supposed to do then, NOT give his honest opinion? THAT would >>> undermine his credibility. Lying would undermine his credibility. >> >> In the current example, the developer has done his best by giving >> their honest opinion to that manager. That's how he keeps his >> credibility. Nobody is asking him to say that A is the best >> *technical* solution - it's not. > > You're changing the hypothesis now; the original hypothesis was that A > WAS the best solution based solely on the technical merits. > > The developer should basically just be able to say A is way better than > B and B is better than C, and using C will probably destroy the project, > all based solely on the technical merits, and then let the suits sort > things out. [ SNIP ] My typo - A is still the best technical solution; it's just not the best solution. AHS
From: Arne Vajhøj on 4 Oct 2009 21:21
Arved Sandstrom wrote: > Arne Vajh�j wrote: >> Arved Sandstrom wrote: >>> It's not that the managers themselves - as people - are defective. >>> It's the system that's defective. Next time you get a chance look at >>> your organization or one that you have dealings with. If the >>> structure is one of top-level non-technical managers supervising >>> intermediate-level non-technical managers, who in turn supervise >>> bottom-level non-technical managers, who in turn supervise technical >>> people, you've got a problem. >> >> Manager may not know about writing code, but they should know about >> managing. >> >> Since their job is to manage not to write code. >> >> First level management actually do benefit a lot from >> understanding what the work is all about. >> >> But higher up the food chain it is all budgets, ressource >> planning, strategy etc.. > > Budgets and resource planning, sure - that's pretty interchangeable > managerial stuff. But strategy, at any level of an IT organization, > requires technical savvy. It doesn't mean that a manager four or five > levels up needs to know how to write code, but they'd best be able to > listen to a technical architect without getting a glazed look in their > eyes. And IT managers two or three levels up had best be able to talk to > a senior developer, when the occasion demands, and have half a clue as > to what the developer is telling them. > > Managers in other industries don't get these free passes like IT > managers seem to do. A manager in most other sectors actually has to > know a fair bit about the nuts and bolts of the job. But in IT it's > seemingly OK for a manager at intermediate and senior levels to know > extremely little about technology. I don't think that's acceptable. If the manager has the skill to hire the right people and to make those people explain the technical matter in plain English, then they can do quite fine. It is like programmers using cryptography. Very few really understands all the math behind it but chose to base decisions on summaries from trustworthy sources. And I don't think IT is that much different from other businesses regarding whether management has a past doing what the company actually do. I very much doubt that the managers in car companies can assemble a car, managers in airlines can fly a plan, managers in oil companies can drill etc.. Arne |