Hacker News Reader

Comment by osrec | Hacker News Reader

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.

View on HN

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

"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"

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.

>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.

That's overstated. You don't have to be a full-blown accountant; you just have to have enough accounting knowledge to do your job. I worked at a funds company for a few years and I didn't know anything about the business when they hired me. But the amount of domain knowledge I had to learn to be effective in my little area wasn't that difficult to pick up.

>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.

Nobody is going to thank you for producing software that would have been great if only it worked the way you intended.

> That's overstated. You don't have to be a full-blown accountant

Nope, ideally, you should be better than your average "full-blown" accountant.

> Nobody is going to thank you for producing software that would have been great if only it worked the way you intended.

Look there are minimum levels of competency for a lot of things before you can do anything. In similar fashion, you also need to be able to walk, or at least get around, have some modicum of how to run a business (even if you're just a TL), ... and so on and so forth.

This says that the most successful people in the the business-software space are people who have domain knowledge and software skills, and write software in their domain. And those people do quite well, dominating their various industries (Lexis-Nexis for law, for example)

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.

> 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.

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.

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?

Couldn't agree more. This does seem to be a relatively rare perspective right now, though.

(Somewhat seriously) are you hiring?

When the mantra among developers is "the only way to get a raise is to change jobs", and people are moving on a bi-yearly basis - yeah, you need to plan for cogs.

No amount of ownership is going to cover for an otherwise brilliant developer who jumps ship once the project has shipped its MVP. And if that brilliant developer wrote that project in, say, Haskell (because they wanted to learn it), that project is probably doomed from a financial point of view - a quality Haskell developer willing to do maintenance on an existing project will likely cost more than the project is worth in the first place.

The root of this problem does lie in management, but it's a self fulfilling prophecy at this point: employees have taken the lesson to heart. Even companies which do give fantastic benefits are going to still see high turnover, and need to account for that.

The idea of interchangeable cogs is completely unattainable if a non technical manager is the one hiring, replacing, etc the cogs. If you think about it it makes sense that the only type of person who could ever theoretically pull this off would be a master programmer who understands the project at such a deep level that tasks can be broken down into pieces consistently. I'm not saying it's possible but it's definitely impossible for any non technical manager to do.

There's a big spectrum between "interchangeable cogs" and "nobody even writes in the same language or architecture" and I don't think either of those extremes would be a good development environment.

Ownership (by devs) doesn't have to mean a hyper-personalized idiosyncratic creation. Part of the pride of ownership can be making something understandable and modifiable by other people.

The bigger problem is that many companies do not reward that, they reward doing it quickly and not asking too many questions.

> One view of management is that it's about making sure the cogs of the machine are completely interchangeable.

That's not what I was talking about. Employees are neither bricks nor cogs. But having said that, if you run any long-term project, you should expect people to come and go, it's part of the game. Thinking that this will not happen in your project is simply negligent.

> This is actually an extremely inefficient and demoralizing environment for those involved.

It doesn't have to be. Working with common conventions and tools doesn't have to be demoralizing. Conventions should be set for a good reason, after an open discussion, and possibly even a vote ("Do you think that it's worth bringing in this library?", "Should we all use the same IDE?"). Also, conventions aren't set in stone, they can change over time.

This gives the team ownership of their project. It makes passing knowledge between team members easier, it makes it easy for team members to help each other when they've run into an issue, not to mention that it makes code reviews and various technical discussions a lot easier.

If Bob is writing using a different language or a set of libraries than the rest of us, who can review Bob's code? Who can help him out when he's stuck on some bug? Who can help him flesh out his design ideas for some feature he's writing?

Without team cohesion, you're creating not a team of developers, but a bunch of individuals who happen to work on related stuff. I don't know about you, but to me that sounds a lot more demoralizing. To me, one of the great benefits of working on a team is that we all get to learn from each other, plus we get to share a common goal. Agreeing to some common conventions seems like a small price to pay for that.

Team cohesion is definitely not about using the same IDE.

I worked at a place that essentially standardized on Vim. They emphasised pair programming so IDE standardization helped with that. If you already use Vim, sounds great. If not, probably sounds terrible. So what looked like team cohesion was homogeneity. They subtly turned away a lot of people who didn't fit the mold in what should be a minor detail.

I've worked at two companies that basically banned Redis. Having a conversation with an SRE who had a bad experience, trying to convince him it's worth having this tool available, is one of my worst professional memories. Consensus driven technical decisions suck. It's better to give people authority and responsibility. I would have happily admined it myself.

Nobody's going to review Bob's code, not really. If they're not working directly with him on the project and it's doing anything reasonably complex, then they don't have the context to say anything useful beyond catching typos. Things get rewritten every few years anyway.

A manager is not a developer, only developers can set good technical standards. A manager's job is to make sure there is a lead developer with clear authority to set technical standards.

A technical manager can certainly be a developer. I'm not talking about business people setting technical standards, I'm talking about tech leads/lead developers.

Conventions set collaboratively by the team as a whole gain better traction than those dictated by a leader.

Common ownership does not end up with a random patchwork of technologies. Teams make collective decisions on them.

I might like to write CGI programs in Prolog with a MarkLogic db, I'm not going to unilaterally decide to write my bit of a team application like that when everyone else writes WSGI Python applications with Postgres.

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".

Good analogy

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.

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.

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.

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.

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.

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).

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...

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.

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.

>"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.

Yes, when I started in this business developers were expected to work hand in hand with the business to understand how the business worked and why a feature was warranted and the find an elegant solution in software, and even suggest new solutions to fine tune the business processes encapsulated in software.

That still happens, but it seems the "cogging" of developers has largely made that a rarity as cheap offshore developers aren't expected to do that sort of thing anymore.

As an aside Spolsky should be required reading for any person who oversees any department that interacts with developers in any way. Most people think of development as a scientific endeavor, but it's largely artistic with mathematical tools.

I think ten years ago everyone was reading along with Spolsky. I haven't found a good equivalent nowadays.

I'm sure it is possible to have an artistic layer of software management that reduce everything to "write me a function that passes this test", which you could outsource to wherever. But having reduced all of the code to that level you have done all of the hard work in writing it anyway, haven't you? By involving the all of the junior devs in that reduction process, you are also teaching them how to do it, so they can be he next 'architect'.

An interesting and sort of related aside: I do some work with a company that makes old fashioned 'Enterprise software'. Their process seems to be that the back end dev gods write functionality that is convenient for the database, and then the front end people make that accessible to humans in the most convenient way for them. So instead of working the way humans do, the humans have to work the way the database does! When you talk to their back end devs, they talk down to you like you are an idiot for not following the way they work! Their db implementation is actually pretty good, the application is only really usable to people that can write SQL, however! If their API didn't also suck it would be tempting to re-skin the whole app.

>> 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!

The first job of a dev is to define the requirements with the clients. But most dev don't know or don't want to do that.

> and deadline

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

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.

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.

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.

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.

Of course you can work uncertainty into time estimates.

That aside, the incentive is high to keep the amount of work planned below the amount of work that can be done before the deadline. It doesn't matter how many abstract units or concepts you use, that's what you want to know if you have a deadline.

Working uncertainty into time estimates still just gives you two sets of times to consider, with no way of knowing why you missed the low one and just if you will hit the high one. (Unless you do really wide bars on your estimates, in which case, the high bar is going to be worthless.)

That is, if you give me a high confidence and a low confidence estimate, how do I know why you missed it when the time passes? More, how "close" to making it were you? If you got half of the work you estimated done by that time, I'd know you were about halfway there. If the date just passed, all I know is that you didn't make it.

And I used "I" up there. But it is really even more personal. All you know is that you didn't make it. You literally don't have anything to learn there.

Contrasted with any work you do. Look back and quantify what you did. Not how long it took to do it.

> If you got half of the work you estimated done by that time, I'd know you were about halfway there

And only 90% of the work remaining!

It sounds like you are imagining an estimate as a standalone number that isn't revisited or given more detail. If that's how you do it then of course you can't learn from it. It's supposed to be an ongoing process - if you said '3-6 months' when we started then after 2 months I'd expect a different answer. I'd also expect the initial estimate to be accompanied by an explanation that talks about the work to be done and which areas are causing uncertainty.

> to help them learn how to do it

If you know of anything to read, watch, or work through to learn to estimate tasks, I would be extremely grateful if you could link or describe it here.

As it stands, I’ve only ever been able to estimate tasks if I’ve done similar ones a few times before. If asked about a new type of task or one with a new toolset, I would currently have to refuse an estimate more fine-grained than a week—-the stress and shame of lying to you would be too much otherwise

Consider how you would estimate anything else. Say you want to retile a kitchen. Would you expect someone to just say, I could do this in a weekend? Because, that is what shows typically seem to need?

Or would you feel more comfortable asking how much they will have to actually do? For example, they would have to disconnect the fridge and move it out of the way, disconnect the oven and move it out of the way, then buy enough tile and mortar for the space, which would be X boxes, and then clean and do the work.

Benefit of this way is when you come back, if none of those tasks has been done on day two, you know it isn't likely to get done on day two.

So, try and use the same approach for programming. Don't just say "it will take 2 weeks." Instead, say, it requires updating X component, modifying Y tests, incorporating Z new dependencies, etc...

As a team, you can try and portion size estimates on each of these. But don't spend too much time on that. Experience is the secret, not perfect estimates. (That is, the more things the team has done, the better they will estimate what they can do.)

Right, my current approach, which works fairly well, is to spend some time writing out a couple approaches and splitting them it out into coherent delegatable tasks. This results in a 2-3 page doc that I can check with other engineers and business stakeholders to be sure it does what we really want it to. It also means we notice if an assumption we made is untrue and we need to re-think the scope or approach of the project.

I’m just worried that at some point, somebody will come along and ask for an estimate and I’ll say I cannot give one and that this means I am not really a professional.

Just be sure to do retrospectives on these documents and I'd wager that you are beyond any skill that I can lay claim to. Honestly, sounds like you are already beyond my skill levels.

Can't say if that helps strengthen your claim to professional, but that practice certainly sounds professional to me.

There's nothing wrong with making imprecise estimates - the lack of precision is part of the information.

So for time-based estimates, I've been given the advice to take what I think it will be and multiply by a factor of 4.

If it can be that far off (or more), what is the business value? And how do I know that the person I'm talking to will realize when I say "this will be done by the 20th" that I am thinking "I have no clue."?

Also, I think I figured out what I don't like about this answer - I don't want a dev to have outlined every task and designed the data structures to be used before they can figure out whether a feature will take closer to 6 or 18 months.

I get the impression we are talking past each other. I certainly don't want every task outlined. Indeed, I don't necessarily want to know new data structures. I would expect an idea of what has to be modified. And if that isn't known, then I'd expect any estimate to be bad.

That said, my main point is that time estimates lead to bad negotiations. If someone says it will take six months and you need it in five, what is on the negotiation table? Just a month? This is how our industry often finds itself in crunch time, making up for time estimates gone awry.

Whereas if there is a list of things that can be negotiated, you can order the construction such that things are natural cuts.

We do seem to be miscommunicating. If the estimate is six months and the deadline is five, then you ask what can be cut to make that work, and you talk in terms of reducing scope or quality of the work. And it doesn't work to just do things in order of importance - maybe if I need this feature this month it can be done, but if you give me three months then I can implement it in a more resilient/scalable/maintainable way that will also solve problems y and z. My point is probably that a lack of time estimates lead to bad planning.

My guess to where we are talking past each other is that I am asserting you can go from the work to the time. So, you should ask for that. You cannot go from the time to the work. (Again, both are assertions.) You seem to be saying you should just ask for the time, and only dig on the work if you aren't satisfied with the time.

If you are able to turn every estimation session into a series of back and forths where it is "how long?" followed by "why?" if you aren't satisfied, then I feel we are essentially agreeing. Whether you are asking for it or not, you want them to estimate the work required and to summarize it into a time.

And to be perfectly clear, going two people removed from the work, this is required. Similarly, getting 3 people removed from the work, the relevant question will not be "how long" but "how many dollars?"

Similarly, it would be nice to think everyone will eventually need the skill of estimating the value of a feature or product. Because, at the end of the day, that is what is most important.

However, I'm assuming anyone asking someone specifically for an estimate is one of their managers. And they should have more familiarity with what they are asking their colleagues to estimate. And I'm also asserting each of these skills is not trivial. And that they build on each other.

And this is where I'm confused: where does a dev learn the skill of figuring out how long a feature will take before figuring out the user flows and data structures.

I've never worked on a project where I was estimating something at a scale of 6 months. But if you ask me whether something will take 1 week or 4 weeks, before I've broken the task down, my intuition is going to scream "I don't know the answer to that."

If I told you "Somewhere around 1 week to 2.5 months", would you accept that answer? Or would you think I was trolling you and we should have a conversation about my performance and place at the company?

If I instead told you "2 weeks", how would that be anything other than a lie?

New methodology unlocked: Software Feudalism

Reply on news.ycombinator.com