8 ms·

For me, the real issue is ownership. I come from a finance background and have seen "business people" often run technology into the ground because they simply c

by osrec 9y ago

For me, the real issue is ownership. I come from a finance background and have seen "business people" often run technology into the ground because they simply can't let go of ownership or control. They want to define too much and leave little in the hands of the developer. Development managers can be just as bad with their overarching methodologies. Really bad ones can stifle the creativity of their developers by micromanaging and just end up making people miserable. I personally don't follow any particular methodology, but instead, I agree with each team member a well defined deliverable and deadline, and just let them get on with it (with whichever methodology they prefer). The only thing we stipulate as a firm is the version control system and test procedures. The whole team has an informal chat once a week or so to make sure things fit together properly - no daily stand up rubbish. It's not complicated or even that structured, but it works and my colleagues seem happy. Basically our philosophy is, hire good people, make them responsible for something, and let them find the best way to deliver. And definitely don't tie them up in stupid admin tasks as stipulated by the latest fad.

thinkersilver 9y ago
That's a pretty big 'if', though. Hiring good people is difficult. Having bad people is more common and that may be the justification for methodologies. They don't exist to make good people more productive but to make mediocre hires marginally productive.
- shandor 9y ago
  I feel like this actually explains a surprising amount of things that look silly at face value. Another example I've talked a lot with my colleagues is company wide coding style definitions. They usually have stuff like "never ever use goto", but then you have Linux kernel code using goto, and it seems all weird. But here too the coding convention that feels "stupid" to the rockstar coder is in place to make the code of the summer intern even remotely usable after they are gone.
  - Clubber 9y ago
    Goto is often used in assembler and low level C code that essentially mocks assembler, but spaghetti for procedural and OOP styles. I actually found a goto in a C# project I took over this year and one of the first things I did was change it to a while loop with a break.
    - IWeldMelons 9y ago
      goto is used in pure c code as a substitute to exceptions, to prevent unnecessary repetition of the resource deallocation code. Even in C++ code, it is often way faster than exceptions. Goto is not scary.
      - stochastic_monk 9y ago
        The point is that exceptions should be used for exceptional cases only. Most situations (e.g., early returns) for which resource management would be handled by a goto are already addressed by RAII.
  - cakes 9y ago
    Not that it is implied but it isn't just the "summer intern" that needs some coding convention guidance sometimes. It can be as useful as coming onto a project and at least you have some chance at (mentally) parsing the code/project without a huge melting pot of styles across all parts of the project (you'll obviously still get some but with convention you at least start from a slightly better place).
- osrec 9y ago
  That is a very astute observation and I do agree with it. I would argue though, that a lot of mediocre people are actually very smart, but have been trapped under micromanagement all their lives. As a result, they constantly expect to be told what to do. They have the ability to think cogently, but believe it imprudent to do so. I've hired a couple of "non-performers" in my firm from corporates, and once they've been thrown in the deep end a couple of times, they're actually pretty productive. To be honest, my own senses were numbed by being a yes-man at a corporate job. My job title made it sound like I ran the world, but much of the work I was made to do was simply idiotic. And I was very happy to toe the line because it was easy, you could always spread blame and I didn't have to think much. Then I realised I have a limited amount of time on this planet and decided to do something more useful with my time...
maltalex 9y ago
Ownership is good, but only up to a point. In this approach, developers end up being independent contractors on a payroll. If you focus only on deliverables and deadlines, you'll end up with developers using a mix of different approaches, libraries and even languages. It hurts team cohesion and makes the logistics of project management much harder since Joe can't take over Tom's code now that Tom has the flu. As I see it, one of the main tasks of a technical manager is to set conventions so everyone would feel at least semi-comfortable with everyone else's code. That's not micro-management, that's management.
- sloxy 9y ago
  > one of the main tasks of a technical manager is to set conventions I'd be more inclined to say one of the main roles any manager is facilitation more than anything else. Any manager that "sets convention" is somebody who wants the easy part of technology without the corresponding hard part. Talking about technical solutions is easy. Implementing it is much harder. I've come across multiple "technical managers" who were hands on with code greater than x years ago and they always end up talking out of their arse. And that's not to mention the numerous wrong choices they've committed to/spoke about at a high level meeting with zero notion.
  - maltalex 9y ago
    I think that we're talking about two different types of managers. I was talking about a technical manager, as in a tech lead/lead engineer/lead developer/whatever you want to call it - someone who has to manage and coordinate the day to day of people doing technical work (on top of taking part in the said work). I think you're talking about someone more business-oriented.
- bluesnowmonkey 9y ago
  One view of management is that it's about making sure the cogs of the machine are completely interchangeable. Everything is uniform, orderly, perfect. Everyone is replaceable. No one's contribution can be distinguished from that of any other. Everything must be measurable and measured. See how the graphs in our status updates always show progress! This is actually an extremely inefficient and demoralizing environment for those involved. Yeah, it's easy to take over when someone leaves, because they were so hamstrung by the environment that they never built anything interesting. And you're going to be doing a lot of this taking over, because people are always leaving, because they were hamstrung. So this idea that we can't trust individuals to stick around and do a good job, and we have to make sure they never have enough power to do damage when they make a mistake, it's a self fulfilling prophecy. It makes them untrustworthy and drives them away. It really is about ownership. Programmers who are achieving at a high level move much faster and do much greater things. It's worth letting them make mistakes to retain the best people and get their best work. The only catch is figuring out how to keep them accountable for their decisions. OK, you want to use this new tech or try this new architecture. How do we tie your compensation and career progress to the success of those decisions?
mentos 9y ago
Steve Job's view on management shares similarities to what you have described and I think from my experience I agree with this outlook https://www.youtube.com/watch?v=rQKis2Cfpeo https://www.youtube.com/watch?v=rQKis2Cfpeo "The greatest people are self managing, they don't need to be managed. Once they know what to do they will figure out how to do it. What they need is a common vision, and that's what leadership is. Leadership is having a vision, being able to articulate that, so the people around you can understand it, getting a consensus on a common vision." "We were in stage where we went out and thought, Oh! We are going to be a big company, so let's hire professional management. We went and hired a bunch of professional management but it didn't work out all well. Most of them were bozos, they knew how to manage but they didn't how to do anything!" "If you are a great person, why would you want to work with someone you can't learn anything from? You know what's interesting? You know who the best managers are? They are the great individual contributors who never ever want to be a manager but decide they have to be a manager because no one else is gonna do a job as good as them"
- candiodari 9y ago
  Well that's the big secret that's mostly secret because nobody wants to know it: Programmers/developers are only effective if either the developer himself or enough people in the team have sufficiently deep domain knowledge. That means you can only write accounting software if you are an accountant, in addition to a developer. You can replace "accounting" with anything else you want. Software developers don't want to hear this because it means that being a developer is near useless : it allows them to express themselves in code but ... they have nothing to express. Accountants don't want to hear this because it means no generic software developer (or firm) can deliver on the software they want. The real bad news for software devs is this : you'll do a lot better as a bad developer with expert domain knowledge than vice versa. This is why Excel sheets and VBA macros can run for decades when great and easily maintained software cannot : the knowledge they were written with is what makes the difference. Of course both situations are what you constantly see in the real world. Software developers just making software that doesn't support the function it was written for, and really, really badly written pieces of crap software that work amazingly well.
snarf21 9y ago
Very true. I've found at every company that I've worked at that a "bad" process followed consistently by everyone always outperforms the "perfect" process followed haphazardly. This reminds me of the recent threads about people using Excel instead of "real" software. At the end of the day, you are trying to add value. As long as you aren't adding technical debt or other risks, the how matters much less.
- seanmcdirmid 9y ago
  Taking on technical debt isn’t necessarily a problem, zero debt methodologies are the worst! The ones that acknowledge debt as necessary and so deal with it are much better.
jimnotgym 9y ago
>"business people" often run technology into the ground because they simply can't let go of ownership or control Maybe I am one of those people? The first time I hired a developer (contract, and senior contract at that) I had written a prototype of the software I wanted with the core features working but it was clunky. It was to interface a modern piece if software to a legacy system with a poor API. I gave him the code and said that I wanted that same thing, but written in a professional and maintainable way. I asked him to let me know anything he was not sure about, and I would document it further. 'Let's be Agile about it, we don't need to write heaps of documentation', he said. Apart from having to make him recover from various flights of fancy about new features I hadn't asked for, he kept blundering on with things he hadn't understood properly or he lacked the specific domain knowledge for. I had those things, and many were working in my prototype. Several times the project stalled due to a problem he couldn't fix and I recovered it with my limited (at the time very limited) coding knowledge. In the end we went live with his solution which never quite achieved its aims, but when the business found new requirements I couldn't face this again and wrote the whole thing from scratch. One bad dev? Well he was a lot like many of the ones I met subsequently tbh. Far to eager to find the one vague thing in what you asked for and interpret it the wrong way. Far to quick to think that users should bend to fit the software and far too willing to plow on with code, when they should have been looking at a flow chart. The great development managers I have met are the ones that have spent considerable time exploring the domain they are working in, know how to talk to business people, and stop and ask when something is ambiguous. Sometimes you need to get out of the tech stack and think more in terms of processes. My methodology is now something like this. 1) I write in plain English what I want (thanks Joel Spolsky) 2) I bullet point my definite requirements 3) I explain a process in simple flow chart blocks 4) I send this to my devs in good time 5) I sit down with them and explain it again, drawing charts as I go if necessary. 6) I invite and expect questions/challenges and note them down 7) I amend my docs and reissue it 8) I let someone else translate whatever I wrote into 'user stories' or whatever else they want to do 9) I test them against the requirements I first wrote, now I know that I have conveyed my meaning correctly 10) I meet with them regularly and take plenty of time to just talk through where we are. I like to have a mix of business people and engineering in the room, because it makes the devs talk in different levels. 11) I get into UAT with the least tech savvy people, who have no understanding of the project as soon as there is something to show them. Secretaries, clerks, call centre operators all find different faults than the tech people who don't do their jobs every day. They ask all the straightforward questions that you never thought of. Sounds obvious, but I meet with a lot of third party agencies and developers who look like they have never seen anything like requirements from a client! I have had them say things like 'but we use Agile, we will collect our own user story' How dumb it that, 'we are the smart ones, we will cut out the people with domain knowledge and guess'! I tell them they can do what they like, but I will test their finished article against my original requirements when I am deciding if I am going to pay for what they did! The main thread of this is to force as much human interaction between the developers and the business as possible, all the way through the project.
afarrell 9y ago
> and deadline What do you do if someone says they don’t know how to estimate a particular task?
- newfoundglory 9y ago
  Set a deadline for coming back with better information. If after, say, a week or two they still can't narrow down a timeline (to something like "1-10 weeks" or "6-18 months") then either simplify or abandon the task.
  - taeric 9y ago
    I would advise not asking for timelines at all, actually. Instead, ask roughly what all they will have to do. How many tasks will it need. Do they need new datastructures, or is it modifying an existing one? Same for logical components. Modification, or addition? In either case, what are they modifying and what are they adding to? If as the manager, you don't know enough about the codebase to get a sense of "last X development efforts on component Y took about Z weeks of effort", then it is your job to get to know the components better. Note that doesn't mean building up the expertise to be able to do the changes yourself. Just that it should not be completely greek to you.
    - newfoundglory 9y ago
      I would probably ask for a timeline even if I felt like I could predict it myself, to help them learn how to do it. And as a manager, you can't always be an expert - sometimes you're the new guy, for instance.
      - taeric 9y ago
        But a timeline is of seriously limited value. You can't burn down on time. You can't combine time estimates. You can't work uncertainty into time estimates. The list could keep going. I agree no estimation process is perfect. Nor do I think you should do comprehensive estimates on new work. However, the thing you want to know it's how much work there is. Not necessarily when you'd like to release a year from now. Odds are high you have a deadline. So the incentive is high to keep the estimate below that line.
JustSomeNobody 9y ago
Managers manage and Bosses Boss. A good manager is like a lineman guarding a quarterback. Everyone wants access to the engineers for features that customers want, bug fixes, etc. A good manager won't let anyone near their engineers. They will filter everything. A boss will toss every... single... little(and big)... fire... at the engineers. A boss will then wonder why nothing ever gets done. A manager manages; staying on top of everything every day. A boss reacts and knee-jerks to everything that comes up "unexpectedly".
- fpisfun 9y ago
  Good analogy
muzani 9y ago
New methodology unlocked: Software Feudalism

by osrec 9y ago

thinkersilver 9y ago

That's a pretty big 'if', though. Hiring good people is difficult. Having bad people is more common and that may be the justification for methodologies. They don't exist to make good people more productive but to make mediocre hires marginally productive.

shandor 9y ago
I feel like this actually explains a surprising amount of things that look silly at face value. Another example I've talked a lot with my colleagues is company wide coding style definitions. They usually have stuff like "never ever use goto", but then you have Linux kernel code using goto, and it seems all weird. But here too the coding convention that feels "stupid" to the rockstar coder is in place to make the code of the summer intern even remotely usable after they are gone.
- Clubber 9y ago
  Goto is often used in assembler and low level C code that essentially mocks assembler, but spaghetti for procedural and OOP styles. I actually found a goto in a C# project I took over this year and one of the first things I did was change it to a while loop with a break.
  - IWeldMelons 9y ago
    goto is used in pure c code as a substitute to exceptions, to prevent unnecessary repetition of the resource deallocation code. Even in C++ code, it is often way faster than exceptions. Goto is not scary.
    - stochastic_monk 9y ago
      The point is that exceptions should be used for exceptional cases only. Most situations (e.g., early returns) for which resource management would be handled by a goto are already addressed by RAII.
- cakes 9y ago
  Not that it is implied but it isn't just the "summer intern" that needs some coding convention guidance sometimes. It can be as useful as coming onto a project and at least you have some chance at (mentally) parsing the code/project without a huge melting pot of styles across all parts of the project (you'll obviously still get some but with convention you at least start from a slightly better place).
osrec 9y ago
That is a very astute observation and I do agree with it. I would argue though, that a lot of mediocre people are actually very smart, but have been trapped under micromanagement all their lives. As a result, they constantly expect to be told what to do. They have the ability to think cogently, but believe it imprudent to do so. I've hired a couple of "non-performers" in my firm from corporates, and once they've been thrown in the deep end a couple of times, they're actually pretty productive. To be honest, my own senses were numbed by being a yes-man at a corporate job. My job title made it sound like I ran the world, but much of the work I was made to do was simply idiotic. And I was very happy to toe the line because it was easy, you could always spread blame and I didn't have to think much. Then I realised I have a limited amount of time on this planet and decided to do something more useful with my time...

maltalex 9y ago

Ownership is good, but only up to a point. In this approach, developers end up being independent contractors on a payroll. If you focus only on deliverables and deadlines, you'll end up with developers using a mix of different approaches, libraries and even languages. It hurts team cohesion and makes the logistics of project management much harder since Joe can't take over Tom's code now that Tom has the flu. As I see it, one of the main tasks of a technical manager is to set conventions so everyone would feel at least semi-comfortable with everyone else's code. That's not micro-management, that's management.

sloxy 9y ago
> one of the main tasks of a technical manager is to set conventions I'd be more inclined to say one of the main roles any manager is facilitation more than anything else. Any manager that "sets convention" is somebody who wants the easy part of technology without the corresponding hard part. Talking about technical solutions is easy. Implementing it is much harder. I've come across multiple "technical managers" who were hands on with code greater than x years ago and they always end up talking out of their arse. And that's not to mention the numerous wrong choices they've committed to/spoke about at a high level meeting with zero notion.
- maltalex 9y ago
  I think that we're talking about two different types of managers. I was talking about a technical manager, as in a tech lead/lead engineer/lead developer/whatever you want to call it - someone who has to manage and coordinate the day to day of people doing technical work (on top of taking part in the said work). I think you're talking about someone more business-oriented.
bluesnowmonkey 9y ago
One view of management is that it's about making sure the cogs of the machine are completely interchangeable. Everything is uniform, orderly, perfect. Everyone is replaceable. No one's contribution can be distinguished from that of any other. Everything must be measurable and measured. See how the graphs in our status updates always show progress! This is actually an extremely inefficient and demoralizing environment for those involved. Yeah, it's easy to take over when someone leaves, because they were so hamstrung by the environment that they never built anything interesting. And you're going to be doing a lot of this taking over, because people are always leaving, because they were hamstrung. So this idea that we can't trust individuals to stick around and do a good job, and we have to make sure they never have enough power to do damage when they make a mistake, it's a self fulfilling prophecy. It makes them untrustworthy and drives them away. It really is about ownership. Programmers who are achieving at a high level move much faster and do much greater things. It's worth letting them make mistakes to retain the best people and get their best work. The only catch is figuring out how to keep them accountable for their decisions. OK, you want to use this new tech or try this new architecture. How do we tie your compensation and career progress to the success of those decisions?

mentos 9y ago

Steve Job's view on management shares similarities to what you have described and I think from my experience I agree with this outlook https://www.youtube.com/watch?v=rQKis2Cfpeo https://www.youtube.com/watch?v=rQKis2Cfpeo "The greatest people are self managing, they don't need to be managed. Once they know what to do they will figure out how to do it. What they need is a common vision, and that's what leadership is. Leadership is having a vision, being able to articulate that, so the people around you can understand it, getting a consensus on a common vision." "We were in stage where we went out and thought, Oh! We are going to be a big company, so let's hire professional management. We went and hired a bunch of professional management but it didn't work out all well. Most of them were bozos, they knew how to manage but they didn't how to do anything!" "If you are a great person, why would you want to work with someone you can't learn anything from? You know what's interesting? You know who the best managers are? They are the great individual contributors who never ever want to be a manager but decide they have to be a manager because no one else is gonna do a job as good as them"

candiodari 9y ago
Well that's the big secret that's mostly secret because nobody wants to know it: Programmers/developers are only effective if either the developer himself or enough people in the team have sufficiently deep domain knowledge. That means you can only write accounting software if you are an accountant, in addition to a developer. You can replace "accounting" with anything else you want. Software developers don't want to hear this because it means that being a developer is near useless : it allows them to express themselves in code but ... they have nothing to express. Accountants don't want to hear this because it means no generic software developer (or firm) can deliver on the software they want. The real bad news for software devs is this : you'll do a lot better as a bad developer with expert domain knowledge than vice versa. This is why Excel sheets and VBA macros can run for decades when great and easily maintained software cannot : the knowledge they were written with is what makes the difference. Of course both situations are what you constantly see in the real world. Software developers just making software that doesn't support the function it was written for, and really, really badly written pieces of crap software that work amazingly well.

snarf21 9y ago

Very true. I've found at every company that I've worked at that a "bad" process followed consistently by everyone always outperforms the "perfect" process followed haphazardly. This reminds me of the recent threads about people using Excel instead of "real" software. At the end of the day, you are trying to add value. As long as you aren't adding technical debt or other risks, the how matters much less.

seanmcdirmid 9y ago
Taking on technical debt isn’t necessarily a problem, zero debt methodologies are the worst! The ones that acknowledge debt as necessary and so deal with it are much better.

jimnotgym 9y ago

>"business people" often run technology into the ground because they simply can't let go of ownership or control Maybe I am one of those people? The first time I hired a developer (contract, and senior contract at that) I had written a prototype of the software I wanted with the core features working but it was clunky. It was to interface a modern piece if software to a legacy system with a poor API. I gave him the code and said that I wanted that same thing, but written in a professional and maintainable way. I asked him to let me know anything he was not sure about, and I would document it further. 'Let's be Agile about it, we don't need to write heaps of documentation', he said. Apart from having to make him recover from various flights of fancy about new features I hadn't asked for, he kept blundering on with things he hadn't understood properly or he lacked the specific domain knowledge for. I had those things, and many were working in my prototype. Several times the project stalled due to a problem he couldn't fix and I recovered it with my limited (at the time very limited) coding knowledge. In the end we went live with his solution which never quite achieved its aims, but when the business found new requirements I couldn't face this again and wrote the whole thing from scratch. One bad dev? Well he was a lot like many of the ones I met subsequently tbh. Far to eager to find the one vague thing in what you asked for and interpret it the wrong way. Far to quick to think that users should bend to fit the software and far too willing to plow on with code, when they should have been looking at a flow chart. The great development managers I have met are the ones that have spent considerable time exploring the domain they are working in, know how to talk to business people, and stop and ask when something is ambiguous. Sometimes you need to get out of the tech stack and think more in terms of processes. My methodology is now something like this. 1) I write in plain English what I want (thanks Joel Spolsky) 2) I bullet point my definite requirements 3) I explain a process in simple flow chart blocks 4) I send this to my devs in good time 5) I sit down with them and explain it again, drawing charts as I go if necessary. 6) I invite and expect questions/challenges and note them down 7) I amend my docs and reissue it 8) I let someone else translate whatever I wrote into 'user stories' or whatever else they want to do 9) I test them against the requirements I first wrote, now I know that I have conveyed my meaning correctly 10) I meet with them regularly and take plenty of time to just talk through where we are. I like to have a mix of business people and engineering in the room, because it makes the devs talk in different levels. 11) I get into UAT with the least tech savvy people, who have no understanding of the project as soon as there is something to show them. Secretaries, clerks, call centre operators all find different faults than the tech people who don't do their jobs every day. They ask all the straightforward questions that you never thought of. Sounds obvious, but I meet with a lot of third party agencies and developers who look like they have never seen anything like requirements from a client! I have had them say things like 'but we use Agile, we will collect our own user story' How dumb it that, 'we are the smart ones, we will cut out the people with domain knowledge and guess'! I tell them they can do what they like, but I will test their finished article against my original requirements when I am deciding if I am going to pay for what they did! The main thread of this is to force as much human interaction between the developers and the business as possible, all the way through the project.

afarrell 9y ago

> and deadline What do you do if someone says they don’t know how to estimate a particular task?

newfoundglory 9y ago
Set a deadline for coming back with better information. If after, say, a week or two they still can't narrow down a timeline (to something like "1-10 weeks" or "6-18 months") then either simplify or abandon the task.
- taeric 9y ago
  I would advise not asking for timelines at all, actually. Instead, ask roughly what all they will have to do. How many tasks will it need. Do they need new datastructures, or is it modifying an existing one? Same for logical components. Modification, or addition? In either case, what are they modifying and what are they adding to? If as the manager, you don't know enough about the codebase to get a sense of "last X development efforts on component Y took about Z weeks of effort", then it is your job to get to know the components better. Note that doesn't mean building up the expertise to be able to do the changes yourself. Just that it should not be completely greek to you.
  - newfoundglory 9y ago
    I would probably ask for a timeline even if I felt like I could predict it myself, to help them learn how to do it. And as a manager, you can't always be an expert - sometimes you're the new guy, for instance.
    - taeric 9y ago
      But a timeline is of seriously limited value. You can't burn down on time. You can't combine time estimates. You can't work uncertainty into time estimates. The list could keep going. I agree no estimation process is perfect. Nor do I think you should do comprehensive estimates on new work. However, the thing you want to know it's how much work there is. Not necessarily when you'd like to release a year from now. Odds are high you have a deadline. So the incentive is high to keep the estimate below that line.

JustSomeNobody 9y ago

Managers manage and Bosses Boss. A good manager is like a lineman guarding a quarterback. Everyone wants access to the engineers for features that customers want, bug fixes, etc. A good manager won't let anyone near their engineers. They will filter everything. A boss will toss every... single... little(and big)... fire... at the engineers. A boss will then wonder why nothing ever gets done. A manager manages; staying on top of everything every day. A boss reacts and knee-jerks to everything that comes up "unexpectedly".

fpisfun 9y ago
Good analogy

muzani 9y ago

New methodology unlocked: Software Feudalism