24 ms·

Heisenberg Developers (2014)

315 points by Sidnicious 11y ago

donatj 11y ago
This is exactly where my job is headed. We hired a project manager who frankly knows nothing about tech. Suddenly, we the developers are no longer able to file tickets ourselves and the tickets themselves need to be blessed and have specs the higher ups can approve. One liner for a hot fix that's filling the error logs? Needs a ticket - a ticket we can't file. All pull requests need one or more associated tickets. I've done my best to actively ignore/subvert it, but it's coming up more and more. It's incredibly stifling and frustrating and I'm really peeved. It's hard to leave a job I love and have been at for almost 5 years, but we're on a road to hell. All that said, if anyone needs a Go dev ;)
- partycoder 11y ago
  The problem is not creating tickets. It is the process around them. Creating a ticket takes seconds and you can even build templates around them if you think they're time consuming. If you cannot report tickets your workflow is wrong.
  - twunde 11y ago
    Seconded. You should be able to create tickets or at least file an initial ticket that a PM can flesh out. Tickets (or any type of change control system including git) really serve two purposes. 1) To track what changed 2) To track WHY something changed. A dev should be able to look up your ticket a year from now and be able to untangle the logic in your code changes tied to that ticket. If your ticket only has a title, or the briefest of descriptions you'll find it hard to debug any issues introduced by this (and you'll also be going to dev hell)
    - donatj 11y ago
      git bisect + git blame I find usually more useful than verbose likely partially correct notes.
      - partycoder 11y ago
        That doesn't scale to large or multiple teams.
      - gknoy 11y ago
        That often tells What changed, but rarely does it seem to tell Why. When the logic changes (and tests too) because the sales team now needs Different Things, it's very useful to have a ticket.
    - bb88 11y ago
      That really assumes that 1) Tickets are detailed enough and have been for a long enough period of time. 2) The functionality that's to blame was implemented in one ticket. Unfortunately, that's almost never true anymore for anyone.
- clockwerx 11y ago
  Simple fix: apply inner platform effect to your benefit. Either highlight a 'high level feature management tool' (trello/wrike/etc) different to your development workflow, or abuse the current tool by requesting very generalised tickets like 'standing outage prevention' (maintenance!). No one will reject that because the consequences are lots of revenue.
- seivan 11y ago
  Every time I read something like this (because experiencing is just to traumatic to remember) I tend to share http://algeri-wong.com/yishan/engineering-management.html http://algeri-wong.com/yishan/engineering-management.html One day I hope to find some place small that applies that by the 'book'. My personal anecdote was, that no matter how much I tried to persuade the PM that it's a bad idea to put all the platforms (iOS, Web, Android, etc) stories and bugs into one giant tracker (Pivotal Tracker) we ended up doing that.... until the sudden realisation that it's a bad idea. It's hard to believe that PM had been on software projects before. Found a typo in what is otherwise awesome writing, "loosing".
  - allengeorge 11y ago
    Why is this a problem as long as bugs are separated by component? Sometimes a feature will require work on multiple platforms, and it's nice to go to one place to get a sense of overall progress. And, since the bugs/tasks are separated by component, you can get the granular view you want as well.
    - seivan 11y ago
      You could get overall progress even with separated boards. Overall progress doesn't help us who have to open/close/comment on them. You wouldn't use a single issue tracker for five repos, how is this different? Regardless, they wanted to switch once they realized how cluttered things became for non-devs as well.
- ViViDboarder 11y ago
  As a developer, I love having tickets linked to changes! It makes it trivial to trace a git merge to a review and then the original use case. This allows commit messages to be more succinct and technical. Also, if your company is publicly traded in the US, there are requirements to document changes from SOX.
  - donatj 11y ago
    We're privately owned, but that is an interesting thought I'd never even considered.
hlieberman 11y ago
This is very true. My experience has always been that my team performed better when there were /less/ controls on their time, rather than more. I also found it was important to explain the reasons /why/ a particular thing needed to be done by a certain date, on the occasions that some external pressure needed it to be done. People don't mind pulling out the stops and working extra hard, as long as it's occasional and /necessary/. It's absolutely morale-killing to do so for an arbitrary deadline, however. Nothing burns out a team faster than death-marches to deadlines pulled from thin air.
- jaggederest 11y ago
  And of course, the other key part of that is that you should consider those exceptional cases to be exceptions, in the sense of errors. When production goes down, or the sales team overpromises, don't just fix it, figure out why it happened and do the full root cause analysis.
CryoLogic 11y ago
One issue with how developers are hired these days, is many large companies are hiring largely for classical knowledge (aka, memorizing: Algorithms, DS) and mathematical ability. Try interviewing at MS, big G or Amazon and you will see what I mean. These developers are great as code monkeys, but a lot of them don't have any idea what their code contributes to, or even how their business makes money. I attended a hackathon with a number of Amazon employees, and one of my distinct memories was a Principal Engineer who didn't even know what "publicly traded" meant and was sure that Bezos owned 100% of the company. A potential solution to this issue, is to hire engineers with more diverse skillsets. Deep understanding of mathematics and classical algorithms is fantastic for software performance, and low level details. On the other hand, at a tech company - your software is literally your revenue stream. You are hiring people who don't understand your business - to build and grow your business. Maybe hire some developers with strong business skills, and a good understanding of the economy and your market - and put them on a team with more traditional engineers. In doing so, you get someone with the big picture, and someone with the details working together and might not even need another PM. Just my thoughts.
- TulliusCicero 11y ago
  That sounds like a good idea, until you realize that developers with a strong grasp of coding AND business are rather rare. If you're a growing business, it's hard enough to find enough really good devs as it is, and now you want to add in another, orthogonal skill set? Good luck with that.
  - ilostmykeys 11y ago
    Ask not what your left or right brain can do for you. Ask what both of them combined can do for your company.
- paulus_magnus2 11y ago
  Geeky (single focus) developers are - cheaper - do not get distracted by politics / business - easier to control / manipulate into lower salaries
klochner 11y ago
Many developers prefer to work like Navy Seals or Jazz Musicians. It's objectively more empowering, arguably more fun. Some jobs require an army or a big band, i.e., a lot of coordinated precision - objectively less freedom and autonomy, arguably more tedious. Beyond some threshold of granularity you will crush morale though. Do what makes you happy.
ZigmundFreud 11y ago
I think context is important here. What is the software you are building? Is it highly critical or possibly life threatening, like a stock exchange trading system or a aeroplane control system? Should the developers be given autonomy to speed delivery? Or should more controls be put in place to ensure delivery of the quality, validated product while possibly slowing down the delivery speed.
YZF 11y ago
The story begins with a new feature request that the "business" thinks is needed while the "developers" think is not. It's really hard to pick sides here without knowing more about the specifics. I've seen situations where developers are completely wrong about the business value of something and I've seen it the other way around. If the new feature was indeed critical to the business then the boss finds himself in a situation where one of the best developers spends months trying to build some DSL and comes back with nothing. So we can understand the frustration on the business side of things. This is where things started going the wrong way and there's a loss of trust on the ability of the technical team to deliver. Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do. I think the truth here is there has to be some sort of balance. Developers need to balance architecture and refactoring with delivering new stuff. They need to listen and have a dialog with product management about new features. There has to be trust. When there is trust there are less controls. When trust is lost it's almost an unfixable situation especially when you have a combination of a tech team that isn't delivering anything useful (from the business perspective) with management who doesn't understand software development. Clearly the best situation is trust combined with good management and developers who take ownership and see the big picture. Then useful stuff gets delivered and things like architecture or refactoring get taken care of.
- bb88 11y ago
  > Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do. Everything I have read about agile is that if you do it right, everyone is happy. The customer, the developers, and the managers. Agile itself is supposed to be development-centric. Tonight, I realized that Agile does not handle politics very well. I mean, how can it? It's just a software development methodology.
  - mannykannot 11y ago
    > Everything I have read about agile is that if you do it right, everyone is happy. The customer, the developers, and the managers. So they said about all its predecessors, as well. Pretty soon, they start adding "...of course, you must have exceptionally competent people", and then they define 'doing it right' by 'having a successful outcome'. Problem solved by begging the question.
kasey_junk 11y ago
It turns out that software development is a very immature industry. We simply don't know how to judge successful software projects/developers. In the face of that immaturity we can try all kinds of things. Personally, I do anarchist development and hope for the best. Others try cargo cult project management. Still others move to highly constrained development methodologies.
- gearoidoc 11y ago
  I think its easy to judge if a software project was successful (eg. Did we launch? Did we deploy that feature?). The harder question I suppose is whether it was successful and we've got/maintained a quality codebase.
  - kasey_junk 11y ago
    But compared to what? Most software continues to be bespoke/new work. If a different team/process was used would we have been as successful/spent as much money.
    - majewsky 11y ago
      This touches on the classic question of "is coding engineering or art"? If it were engineering, it would become quantifiable once we have enough empirical data from previous projects to base our theories on. If it were art, that would be impossible since every project is as individual as the last one. It's probably inbetween.
      - bb88 11y ago
        Engineering is just applied science. And other engineering fields experience the same types of failure that software engineering experiences -- cost overruns, undefined requirements, unseen technical hurdles, etc.
  - partycoder 11y ago
    that's the same by saying your kids are successful just because they were born.
vinceguidry 11y ago
This is one of those wishful thinking rants that serves to highlight the rose-colored glasses many developers see the business world through. All good things eventually come to an end, and you need to be ready for the inevitable. The author described two perfectly good responses for this scenario, and managed to paint them both as the cowards path. Leaving the company, and checking out mentally, letting the people with the responsibility hang themselves with their own rope. The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it. It's cold comfort to be right, so just get behind management and try to make the new direction work. I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about. These finer qualities of career enjoyment are nice-to-haves, not necessities. There's always good, solid ground to retreat to in case you get routed. Complaints like this remind me of a rich wanker bitching about the valet not putting his seat back the way he left it. Just adjust it yourself and move on with life. Life's too short to get mad about stuff like that.
- fsloth 11y ago
  The author is simply describing a transformation from a system driven mostly by intrinsic motivation to a system driven by an extrinsic one. Typically complex tasks are solved better in an environment with emphasis on intrinsic motivators. It's not wissful thinking. It's a keen observation. Basically management offloads the responsibility of actually managing to a process of accounting. It's a less skillfull, less productive, but a much more predictable form of management. The problem was not the Jira. It was the new PM who instituted the cultural change. Jira can be used just a well to document work done by intrinsic motivators.
  - skewart 11y ago
    This, 100%. I agree that complex tasks are generally better solved in an environment driven by intrinsic motivation - heck, probably all tasks and not just complex tasks. I'm not sure if Jira and other task tracking tools can be used just as well to document work done by intrinsic motivators though. I mean, yes, they _can_ be, but I don't think they're as good as they could be. In fact, I'd say there's a big gap in the market for a solution that gives non-technical managers some reassurance that progress is being made while also not getting in the way of the ad hoc workflows the post describes.
gearoidoc 11y ago
Some good points but the argument that software teams will be most performant as a result of autonomy really depends on the team in question. I worked on a small team with 2 other developers who were both pretty good devs technically. However they treated the business side with almost-contempt and they would estimate even simple changes to take days. As the most junior member on the team I couldn't really influence them. Interestingly, after about 2/3 months on the job, the business side decided to use me as their initial go-to for dev.
bcjordan 11y ago
This stands as an interesting broad strokes story from a developer's experience at a growing company, but worth keeping in mind it's one specific scenario and one perspective on it. In the generalizations-from-this-instance part of the essay, watch for two false dichotomies—"developers that care about getting things done fast with little technical debt and hate having PMs" vs "mercenary developers who like doing one small thing at a time without architecting things themselves, don't find fast ways to do things and ps like cars and money instead of hacking". And "no PMs or process at all" vs "way too much process causing poor development time investment". The best developers, team leads, PMs, etc know when to introduce new processes and team members and when not to. And, importantly, how to tailor processes to each team member to make them as effective as possible. And they work together collaboratively to solve problems—estimating and discussing features flexibly, not tossing pie in the sky specs and finished products over the fence. In this instance it sounds like they didn't do a great job of working with existing scrappy developers' potential, but instead supplanted a new framework (eng/PM) they had seen work before, and the blunt hammer of that move destroyed a lot of potential the early team had invested in. It sounds like there was a general communication issue that was crippling the team even before a producer and new hires came in. I've seen a few teams now grow from no dev process to combinations of issue trackers, estimates, specs etc. Around 14-20 developers it becomes nearly inevitable for someone to take on a high level production role and someone to take point for engineering reliability, whether those are official job titles or not. Often this period coincides with when early team members move on. It's rad when growing companies find ways to keep those early, scrappy hires with deep historical product knowledge in productive roles as the company grows and shifts priorities from staff-leanness and product-speed to staff-scale and product-predictability. But that's often unfortunately not what happens, and it can be extremely painful for both early team members and those trying to evolve the company. (Growing pains!)
zwegner 11y ago
Great article, this echoes a lot of my frustrations working in the software world. It doesn't help that I've experienced being on a well-managed software team working on interesting problems--it kinda spoiled me for all those other jobs... :) Anybody have any advice for escaping this? I want the freedom to work on interesting things in my own way with a minimum of the politics. Ideally a PM would be someone who pushes back on all this micromanagement crap and does everything they can to make the developers' jobs easier. It seems I'm not self-motivated enough to do freelance work or start a start-up, so what other options are there?
- bcjordan 11y ago
  It sounds like you were at a company you enjoyed before—are they still hiring? :P If not, maybe you can do another job search and try to select for companies that manage their projects how you'd prefer. Try asking team members what the process is like and how they feel about it. Often times those Qs are more illuminating than ones about the software stack.
willvarfar 11y ago
Ah the "lets make the project cooler by adding a DSL so customers can add their own features!" never ever pans out! ;) I spent the 90s working on office automation projects that always seemed to degenerate into report DSLs. Is nothing new? The better I get at coding the more I am attracted to avoiding complicated tooling.
- gearoidoc 11y ago
  There's always a flip side! My current project has a DSL (not written by me) and it functions superbly. It does take about a full work day to wrap your head around though :)
- fidz 11y ago
  > The better I get at coding the more I am attracted to avoiding complicated tooling. Could you tell me your story?
abalone 11y ago
So a project was "months" behind schedule, they implemented an agile process for tracking tasks, and "everything slowed"? Slower than what? Being months behind schedule? I get that some PMs can undervalue refactoring code / minimizing technical debt, and that's super frustrating and shortsighted. But the basic premise of this criticism of agile process is deeply flawed: 1. The claim that features took "longer" to ship is directly contradictory to the admission that the project was months behind schedule. 2. If they were behind schedule, then "inflating" their estimates in response to a detailed tracking process was not, in fact, an inflation. It was a reality check. Estimates are really hard. But the solution is not to just "give autonomy" with zero estimation, because that's how you get into that problem they had in the first place: a guy in a room that doesn't ship for months. That's why agile's approach of breaking things down into tasks with very rough sizing and measuring actual after-the-fact time and shipping small milestones frequently is so helpful. You don't have to have super accurate estimates. You just need to report your time and then it figures out a team "velocity". That helps teams be more predictable, which is what it means to be professional and deliver things to customers on time.
- Joeri 11y ago
  Yet agile implemented top-down without team ownership of what to work on is not agile and not good for the health of the codebase. I have seen it fail repeatedly. Basically, if your team is skilled and capable, the process is not that important, as they will find a way to get things done. If the team is not good, the process won't make them much better. The key to a smoothly performing software dev team is good hiring and good coaching.
  - abalone 11y ago
    So if you're behind schedule, your team just isn't skilled enough? That's kind of a dodge. Every team can improve. Instead of exclusively focusing on finding "good" developers, let's also focus on evolving "good" process. Time tracking, estimates, itemizing tasks.. these are in fact good things.
    - 11y ago
option_greek 11y ago
Sometimes I feel JIRA is the manna (http://marshallbrain.com/manna1.htm http://marshallbrain.com/manna1.htm) for software developers :(
edderly 11y ago
Not 100% convinced by the conclusion. There is good project management which can be relatively fine grained, but it doesn't have to be micromanagement and it doesn't have to be a death march. There are some basic red flags raised: > Our project manager would be displeased when tasks took longer than the estimate and would immediately assign one of the other team members to work with the original developer to hurry it along. Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks > Whenever there was any debate about refactoring the code, or backing out of a problematic feature, the new guys would argue against it, saying it was ‘ivory tower’, and not delivering features. The PM would veto the work... Why does the PM have a veto? No technical lead or management with balls? PM's need to manage the features of a release and changes to the plan. Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management.
- vfc1 11y ago
  > Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks The problem is that if the PM decides to do that, the developer has no authority to refuse that. > Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management. Most PMs are just proxies for business, they manage up and out but not down. They will not risk their jobs by refusing requests from business, in the long term that would put them in an unsustainable position.
  - ViViDboarder 11y ago
    Maybe at some companies. Where I work, Engineering Managers and PMs are totally separate. So Engineers have much more representation. But, even in places where this is not the case, they are willing to hire-- spend money - - to speed the project up. If it's made clear, not just to the PM, that it's going to cost money and have no positive effect, it should be a clear business decision.
pacaro 11y ago
The moral of this story is that "let's create a DSL so that users can encode their business logic" is jumping the shark. I was mildly disappointed that the hero of this tale (the PM) didn't fire the "DSL guy" on day one
- bcjordan 11y ago
  DSLs for stakeholders aren't always bad. DSLs thrown over the fence without early and regular stakeholder testing are usually bad though :)
nostrademons 11y ago
The more projects that I've shipped from conception to completion, the more I'm believing that there are two fundamental phases for each project, and you need radically different management philosophies for each. Phase 1 is "will it work?" You get a vaguely-specified business requirement, maybe some intuition that a market could be better served by software. And your job is to build that software, and figure out exactly what's required for it. In phase 1, you need the creative-genius programmers, and they need to work in small teams with large amounts of autonomy. Because most of what goes on in phase 1 is failure: you are learning about the problem space and all of its corner-cases, you're trying out different approaches, and you're hoping to make that one creative leap that brings everything together. Prototyping is invaluable, refactoring is important, and deadlines and estimates might as well be plucked out of thin air. To successfully run a phase 1 project, you often need to be able to redefine success. When I read the article, my first impulse was to say "Well, the biggest fuckup management made was to not cancel the feature, because they had ample evidence that this feature was not worth the cost." A startup's entire life is spent in phase 1, because once it's exited phase 1 it's called a "high-growth company", and their version of redefining success is the pivot. Phase 2 is "make it work". You start phase 2 with a working prototype that demonstrates the feasibility of what you're hoping to do, but still has a lot of rough edges. And your job is to polish it down to something that the customer wants to use daily. That means fixing bugs, improving usability, adding admin tools & logging, improving performance and reliability, ensuring security, etc. In phase 2, you need a much larger team of disciplined, detail-oriented engineers. Because debugging can be parallelized. You need unit tests, you need formal processes, you need issue trackers, you usually need PMs or management. It helps to break things into user stories so that you know you're always making progress. I see a fair amount of hate for Agile and Scrum on HN, but these are tools, and specifically tools for Phase 2 work. I use them myself, for my own projects, because I find that they help me manage all the little tasks involved in bringing a product to market. The hate comes from people who misapply them: startups who have big-company management who blindly apply what worked at their last employer, or established companies that are trying to do new green-field projects and believe it works the same way improving your 10-year-old product works. But similarly, there are a large number of abandoned startups and open-source projects that never bothered to cross the Ts and dot the Is, and so are largely useless to people.
gyardley 11y ago
Oh, the joy of being a product manager for the particular type of programmer who, by virtue of being a programmer, also knows absolutely everything about absolutely everything. This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month, but if they disagree with a tiny aspect of the feature you've brought them, the deep domain knowledge you were hired for and dozens of customer visits you've done are nothing in the face of the awesome might of their computer science degree. Better get comfortable, because it's going to take you several hours to persuade them that you do in fact know how to do your job and the wild-ass alternative they've just come up with is wanted by the market about as much as syphilis. With these guys (and they're always guys) you've got to process up and micromanage, because the only way to get a little bit of intelligent estimating out of them is to ask for ten times as much, so they can give you what you need while still feeling like they're largely ignoring you. The only silver lining is the process eventually makes them leave, so they can be replaced by people who work well with others. You know, I really don't miss being a product manager. Ranting aside, good developers in larger organizations realize that people have specializations, they and other parts of the company are interdependent, and a little administrative overhead is necessary to keep everybody moving forward together - so they work with people from other parts of the company in good faith, and this makes it possible to keep the administrative crap (which no one likes, it's not just them) as light as possible for as long as possible.
- PhantomGremlin 11y ago
  This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month A comment in the article made a similar point. QFT: I dare say you wouldn't win much work though turning up to pitch to potential customers and declaring that you'll definitely deliver something, but you don't know how long it will take or how much it will cost. Every employee needs to be aware of time, of deadlines, and needs to understand that the money to pay their salaries needs to come from somewhere. Or they need to find a job working for some government agency, or in academia, not in the real world.
  - mobiuscog 11y ago
mikekchar 11y ago
The "Heisenberg Developer" name is really excellent. I recall DeMarco saying in his excellent books (so many years ago): Do not measure anything unless you have a very specific action you want to take based on the data. Why? Because every measurement alters the way programmers work. The author reports that increasing the granularity of the work (and thereby decreasing the time between measurable status updates) led to a lack of refactoring. I have also experienced this one and it led to much head scratching on my part. Which is not to say that one should not measure. I've never actually used Jira, but apart from that, many of the things the author talks about are generally good ideas: reduce story size to a day or so, prioritise every 2 weeks, measure delivery at about the same interval. Don't throw the baby out with the bath water. I can say with some confidence that where they went wrong was that they tried to estimate the stories and then they made the cardinal sin of trying to measure the elapsed time for each story. In the first case, you don't need estimates. Each story is a day or so. It's enough granularity. In the case of measuring, there is no organisational benefit. You can see the average throughput of stories. You can estimate your final delivery (especially if you use a defect growth model to estimate how many requirements you are currently missing before delivery). Measuring the actual time of an individual story adds absolutely nothing to your control of the project. The main argument that I've heard for measuring are two fold. First they feel that measurement will allow people to get better at estimating. Again, it is not needed. If you have a granularity of a day or two in your story sizes (and your throughput is showing that you are achieving that), then you have nothing to improve. If your throughput is not there, then you need to see what the problem is. It will be one of 3 things: your stories are too big, your code is too complicated, your programmers are crap. The first is solved by making your stories smaller, the second is solved by working on technical debt, the third is solved by firing your programmers. I recommend doing everything you can to solve the first, move on to the second, and only then resorting to the third. What measuring will give you is an idea of the variance in the story sizes. This is unimportant. In fact it is critical not to measure this. All you care about is throughput. Variance is where the developers are putting the extra effort in to improve your throughput (by dealing with technical debt, improving tests in critical areas, creating efficient build systems, writing documentation, etc.). If you remove the variance (as described by the author), you destroy the ability for the developers to optimize throughput. The second argument for measuring time is to identify stories that are (or were) in trouble. Again, this is unnecessary. First, if you have a story and you are having a hard enough time that it is taking you longer than a day or two, then you already know about it. Asking for help is what stand up is for (and really, I hate to have to say this, but that's all standup is for). If you are not having trouble, but you are spending a few extra days to refactor something, then you already know about it. Everyone else does too because they can see the code that you refactored. If you are sitting on your ass and wasting your days writing extremely long posts on HN, then you already know about it. And so does everyone else (because you haven't written any code today, and it's not like you asked for help...). I'm just going to write this one time. If your reasons for measuring the amount of time for stories is because you secretly think that your developers are crap and that they don't know what they are doing, no amount of measurement is going to solve the problem. Make a decision. Fire them, or not. You can't make a crap programmer good by pointing out how much time they spent on a story. They already know it.
ArkyBeagle 11y ago
There's no "Heisenberg" here - the company decided to do the moral equivalent of invading Russia in the winter. I quote - "Then came that requirement. The one where you try to replace an expert user’s years of experience and intuition with software." The only problem with "finely grained management" is that it costs too much.
partycoder 11y ago
About processes: You add a process when you want repeatable results. Adding blocking, synchronous steps involving people slows things down. Adding non-blocking, asynchronous, tool assisted steps are less intrusive in people's work. About hierarchies: You add hierarchies in your organization when your quorum involves too many people and things slow down. Hierarchies exist to make consensus building simpler at the cost of representing fewer people and all the associated consequences. Hierarchy must not be abused. People need to be respectful towards others regardless of hierarchy. Each contributor is important. About quality and technical debt: If you are always reacting to defects, you lost control of your product. You can no longer plan because you are too busy reacting to ad-hoc unplanned work. This is unprefessional and unnecessary. Keep things under control by being preventive, proactive and professional. If someone tries to convince you that non-functional requirements cannot be sold, remember that person that person to focus on functional requirements and leave the non-functional requirements to the engineers.
jondubois 11y ago
I've worked for companies like this. What's hilarious is that most of the employees at these companies take the process very seriously (they obviously don't know better). I've worked at both startups and big companies - I find that fine-grained management in big companies is extremely inefficient. In software, the more constraints you add to a project, the slower things will progress. It gives non-technical managers extra visibility at the cost of speed and agility. I can't help but chuckle to myself whenever we have a 'retrospective meeting' - Every single time, it's the same problems that come up over and over again (related to management/communication issues) and these problems never get fixed. What's even funnier is that the closer we get to a deadline, the more meetings we have - And the more it slows us down. There is a fundamental problem with having very fine-grained cards/stories/tasks; often, related tasks are assigned to different people but it would have been much more efficient to assign all these tasks to a single person.
- yetihehe 11y ago
  > It gives non-technical managers extra visibility at the cost of speed and agility. Hmm, just like with tracing. The more finegrained tracing, the more resources are used for communicating what you do and less resources are going into actual doing. Developers understand this, managmenet may not. Management IS about communicating, so they try to "Do Something" and enforce more communication.
- dev360 11y ago
  >>> It gives non-technical managers extra visibility at the cost of speed and agility. Keen observation. Often times these situations are just self-inflicted wounds on the part of devs too. I have worked with many devs that have had a habit of keeping stakeholders and coworkers in the dark just because they feel like they are too important to be bothered/be held accountable. I know what I'm in for if a project management or glass house CIO is all of the sudden needed, so my top priority is always to primarily earn the trust of business stakeholders and to be as honest as possible.
taylodl 11y ago
Ever work with an engineering team? Building new weapons systems? Fighter planes and the like? Just as creative an endeavor if not more so than software development yet they have schedules and budgets to meet too. And yet people's lives depend on the result. Software development can learn a lot from other engineering disciplines.
- seivan 11y ago
  I feel like you might have missed the point. Also you're assuming these engineering teams for weapons systems and fighter planes are successful by default. F-35?
  - taylodl 11y ago
    Not all engineering projects are successful either. What I'm saying is there's a lot of similarities between these disciplines and so there exists a large body of knowledge and experience from which we can cull and learn.
- FLUX-YOU 11y ago
  Software dev isn't driving this, business is. NASA coding practices prove we can do exactly what you're saying, but businesses don't care for (or don't often need) the rigor that NASA requires. I'd bet a lot of people would enjoy participating in NASA-quality projects if only to experience it and feel good about producing rock-solid code even if they only commit 50 lines total, but they are very rare.
vfc1 11y ago
This is one of the best posts on software development I've read in many years. Each sentence rings true and is an amazing read. Its like the author is describing many of the projects I've worked before. Micromanagement and software factories are the death of software development. But then no matter how much I dislike these management methods, I can see why they are put in place. There are certain developers that get to a project and just start rewriting everything with no good reason, introducing new cutting edge tools and frameworks for the fun of it and for pure CV driven development. They introduce huge bugs close to release dates, breaking browser support, refusing to test on IE. Lets face it, loose canons exist on all teams and we've all seen it before. This is OK and necessary in the early development cycle, but when things get to production its different. One day something gets seriously broken, and management comes in putting in JIRA or equivalent, and micromanagement starts. Demotivation of the early developers sets in, the ones who knew how to setup an architecture and make technical decisions. The leave and are replaced by other developers that don't necessarily could take those decisions. The project entered a pure maintenance phase, where business as sort of given up asking too many features, it just costs too much and the results are less than ideal. The project enters the keep it running final phase, where noone knows how certain parts of the system work anymore, all original developers long gone. Here the goal is to touch the code as least as possible and its no longer a development job, its mostly technical analysis and troubleshooting of test environments. Then 5 or 7 years have gone through, and the business decides to replace the system with a new one and the cycle starts again. The only way i've found to deal with this, is to become a contractor and work mostly on early to mid phases of projects. When the project enters pure maintenance I wait for a few months and then look for a new project.
iamthepieman 11y ago
This is similar to an experience I had. Me and the small dev team were being micromanaged. But we were getting lots of new customers for version 2.0 of our main software product and specifically targetting feature relases to snag certain customers, I feel like it worked from a business perspective. We didn't have time to refactor, didn't have time to anticipate how something would be used in the future and build extensibility into it and the number of hacks in the codebase grew daily. most of us on the dev team knew it was going to be a complete disaster at some point. It was going to take a week to fix a simple bug because it's copy-pasted in 7 different places and something derivative now relied on the bugs behavior. But we were releasing fast and getting money because of it. Initially we fought it but eventually I just figured that if I wasn't on another project when it came time to pay the piper then I'd just find another job. I had given my warnings - when I did have time I still tried to do things right and refactor old code. Ultimately though, the business tradeoff decisions weren't mine to make and I wasn't going to lose any sleep over it.
rocky1138 11y ago
This post should be pinned to the top of Hacker News.
draw_down 11y ago
I say it's a mistake to expect to have creative control at all, over something owned by the corporation you work for. Best to accept that it's not your baby you're working on. You don't get the profits or the glory or any of that. Just do your tasks and treat it like what it is: a job. Creative control and passion and all that is for side projects and things you build yourself. I just feel it's setting yourself up for disappointment to think otherwise. Companies are not founded to provide the ideal environment for software development. They are founded to make products and hopefully a profit. You might argue that a smart business person would provide that environment in order to get their product built, and maybe you'd be right, but that also risks building the thing developers want to build as opposed to what could sell. And as soon as you intervene, poof goes the ideal environment. So even if the environment exists at a company, as at the beginning of this story, it's best understood as a happy accident and shouldn't be expected to last.
kolbe 11y ago
Work long enough and with many different companies, and you will inevitably have had an experience much like this one. And it's not just in software. Any profession that relies on some form of engineering knows what this is like. There's a reason why Dilbert is so funny.

315 points by Sidnicious 11y ago

This is exactly where my job is headed. We hired a project manager who frankly knows nothing about tech. Suddenly, we the developers are no longer able to file tickets ourselves and the tickets themselves need to be blessed and have specs the higher ups can approve. One liner for a hot fix that's filling the error logs? Needs a ticket - a ticket we can't file. All pull requests need one or more associated tickets. I've done my best to actively ignore/subvert it, but it's coming up more and more. It's incredibly stifling and frustrating and I'm really peeved. It's hard to leave a job I love and have been at for almost 5 years, but we're on a road to hell. All that said, if anyone needs a Go dev ;)

partycoder 11y ago
The problem is not creating tickets. It is the process around them. Creating a ticket takes seconds and you can even build templates around them if you think they're time consuming. If you cannot report tickets your workflow is wrong.
- twunde 11y ago
  Seconded. You should be able to create tickets or at least file an initial ticket that a PM can flesh out. Tickets (or any type of change control system including git) really serve two purposes. 1) To track what changed 2) To track WHY something changed. A dev should be able to look up your ticket a year from now and be able to untangle the logic in your code changes tied to that ticket. If your ticket only has a title, or the briefest of descriptions you'll find it hard to debug any issues introduced by this (and you'll also be going to dev hell)
  - donatj 11y ago
    git bisect + git blame I find usually more useful than verbose likely partially correct notes.
    - partycoder 11y ago
      That doesn't scale to large or multiple teams.
    - gknoy 11y ago
      That often tells What changed, but rarely does it seem to tell Why. When the logic changes (and tests too) because the sales team now needs Different Things, it's very useful to have a ticket.
  - bb88 11y ago
    That really assumes that 1) Tickets are detailed enough and have been for a long enough period of time. 2) The functionality that's to blame was implemented in one ticket. Unfortunately, that's almost never true anymore for anyone.
clockwerx 11y ago
Simple fix: apply inner platform effect to your benefit. Either highlight a 'high level feature management tool' (trello/wrike/etc) different to your development workflow, or abuse the current tool by requesting very generalised tickets like 'standing outage prevention' (maintenance!). No one will reject that because the consequences are lots of revenue.
seivan 11y ago
Every time I read something like this (because experiencing is just to traumatic to remember) I tend to share http://algeri-wong.com/yishan/engineering-management.html http://algeri-wong.com/yishan/engineering-management.html One day I hope to find some place small that applies that by the 'book'. My personal anecdote was, that no matter how much I tried to persuade the PM that it's a bad idea to put all the platforms (iOS, Web, Android, etc) stories and bugs into one giant tracker (Pivotal Tracker) we ended up doing that.... until the sudden realisation that it's a bad idea. It's hard to believe that PM had been on software projects before. Found a typo in what is otherwise awesome writing, "loosing".
- allengeorge 11y ago
  Why is this a problem as long as bugs are separated by component? Sometimes a feature will require work on multiple platforms, and it's nice to go to one place to get a sense of overall progress. And, since the bugs/tasks are separated by component, you can get the granular view you want as well.
  - seivan 11y ago
    You could get overall progress even with separated boards. Overall progress doesn't help us who have to open/close/comment on them. You wouldn't use a single issue tracker for five repos, how is this different? Regardless, they wanted to switch once they realized how cluttered things became for non-devs as well.
ViViDboarder 11y ago
As a developer, I love having tickets linked to changes! It makes it trivial to trace a git merge to a review and then the original use case. This allows commit messages to be more succinct and technical. Also, if your company is publicly traded in the US, there are requirements to document changes from SOX.
- donatj 11y ago
  We're privately owned, but that is an interesting thought I'd never even considered.

hlieberman 11y ago

This is very true. My experience has always been that my team performed better when there were /less/ controls on their time, rather than more. I also found it was important to explain the reasons /why/ a particular thing needed to be done by a certain date, on the occasions that some external pressure needed it to be done. People don't mind pulling out the stops and working extra hard, as long as it's occasional and /necessary/. It's absolutely morale-killing to do so for an arbitrary deadline, however. Nothing burns out a team faster than death-marches to deadlines pulled from thin air.

jaggederest 11y ago
And of course, the other key part of that is that you should consider those exceptional cases to be exceptions, in the sense of errors. When production goes down, or the sales team overpromises, don't just fix it, figure out why it happened and do the full root cause analysis.

CryoLogic 11y ago

One issue with how developers are hired these days, is many large companies are hiring largely for classical knowledge (aka, memorizing: Algorithms, DS) and mathematical ability. Try interviewing at MS, big G or Amazon and you will see what I mean. These developers are great as code monkeys, but a lot of them don't have any idea what their code contributes to, or even how their business makes money. I attended a hackathon with a number of Amazon employees, and one of my distinct memories was a Principal Engineer who didn't even know what "publicly traded" meant and was sure that Bezos owned 100% of the company. A potential solution to this issue, is to hire engineers with more diverse skillsets. Deep understanding of mathematics and classical algorithms is fantastic for software performance, and low level details. On the other hand, at a tech company - your software is literally your revenue stream. You are hiring people who don't understand your business - to build and grow your business. Maybe hire some developers with strong business skills, and a good understanding of the economy and your market - and put them on a team with more traditional engineers. In doing so, you get someone with the big picture, and someone with the details working together and might not even need another PM. Just my thoughts.

TulliusCicero 11y ago
That sounds like a good idea, until you realize that developers with a strong grasp of coding AND business are rather rare. If you're a growing business, it's hard enough to find enough really good devs as it is, and now you want to add in another, orthogonal skill set? Good luck with that.
- ilostmykeys 11y ago
  Ask not what your left or right brain can do for you. Ask what both of them combined can do for your company.
paulus_magnus2 11y ago
Geeky (single focus) developers are - cheaper - do not get distracted by politics / business - easier to control / manipulate into lower salaries

klochner 11y ago

Many developers prefer to work like Navy Seals or Jazz Musicians. It's objectively more empowering, arguably more fun. Some jobs require an army or a big band, i.e., a lot of coordinated precision - objectively less freedom and autonomy, arguably more tedious. Beyond some threshold of granularity you will crush morale though. Do what makes you happy.

ZigmundFreud 11y ago

I think context is important here. What is the software you are building? Is it highly critical or possibly life threatening, like a stock exchange trading system or a aeroplane control system? Should the developers be given autonomy to speed delivery? Or should more controls be put in place to ensure delivery of the quality, validated product while possibly slowing down the delivery speed.

YZF 11y ago

The story begins with a new feature request that the "business" thinks is needed while the "developers" think is not. It's really hard to pick sides here without knowing more about the specifics. I've seen situations where developers are completely wrong about the business value of something and I've seen it the other way around. If the new feature was indeed critical to the business then the boss finds himself in a situation where one of the best developers spends months trying to build some DSL and comes back with nothing. So we can understand the frustration on the business side of things. This is where things started going the wrong way and there's a loss of trust on the ability of the technical team to deliver. Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do. I think the truth here is there has to be some sort of balance. Developers need to balance architecture and refactoring with delivering new stuff. They need to listen and have a dialog with product management about new features. There has to be trust. When there is trust there are less controls. When trust is lost it's almost an unfixable situation especially when you have a combination of a tech team that isn't delivering anything useful (from the business perspective) with management who doesn't understand software development. Clearly the best situation is trust combined with good management and developers who take ownership and see the big picture. Then useful stuff gets delivered and things like architecture or refactoring get taken care of.

bb88 11y ago
> Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do. Everything I have read about agile is that if you do it right, everyone is happy. The customer, the developers, and the managers. Agile itself is supposed to be development-centric. Tonight, I realized that Agile does not handle politics very well. I mean, how can it? It's just a software development methodology.
- mannykannot 11y ago
  > Everything I have read about agile is that if you do it right, everyone is happy. The customer, the developers, and the managers. So they said about all its predecessors, as well. Pretty soon, they start adding "...of course, you must have exceptionally competent people", and then they define 'doing it right' by 'having a successful outcome'. Problem solved by begging the question.

kasey_junk 11y ago

It turns out that software development is a very immature industry. We simply don't know how to judge successful software projects/developers. In the face of that immaturity we can try all kinds of things. Personally, I do anarchist development and hope for the best. Others try cargo cult project management. Still others move to highly constrained development methodologies.

gearoidoc 11y ago
I think its easy to judge if a software project was successful (eg. Did we launch? Did we deploy that feature?). The harder question I suppose is whether it was successful and we've got/maintained a quality codebase.
- kasey_junk 11y ago
  But compared to what? Most software continues to be bespoke/new work. If a different team/process was used would we have been as successful/spent as much money.
  - majewsky 11y ago
    This touches on the classic question of "is coding engineering or art"? If it were engineering, it would become quantifiable once we have enough empirical data from previous projects to base our theories on. If it were art, that would be impossible since every project is as individual as the last one. It's probably inbetween.
    - bb88 11y ago
      Engineering is just applied science. And other engineering fields experience the same types of failure that software engineering experiences -- cost overruns, undefined requirements, unseen technical hurdles, etc.
- partycoder 11y ago
  that's the same by saying your kids are successful just because they were born.

vinceguidry 11y ago

This is one of those wishful thinking rants that serves to highlight the rose-colored glasses many developers see the business world through. All good things eventually come to an end, and you need to be ready for the inevitable. The author described two perfectly good responses for this scenario, and managed to paint them both as the cowards path. Leaving the company, and checking out mentally, letting the people with the responsibility hang themselves with their own rope. The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it. It's cold comfort to be right, so just get behind management and try to make the new direction work. I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about. These finer qualities of career enjoyment are nice-to-haves, not necessities. There's always good, solid ground to retreat to in case you get routed. Complaints like this remind me of a rich wanker bitching about the valet not putting his seat back the way he left it. Just adjust it yourself and move on with life. Life's too short to get mad about stuff like that.

fsloth 11y ago
The author is simply describing a transformation from a system driven mostly by intrinsic motivation to a system driven by an extrinsic one. Typically complex tasks are solved better in an environment with emphasis on intrinsic motivators. It's not wissful thinking. It's a keen observation. Basically management offloads the responsibility of actually managing to a process of accounting. It's a less skillfull, less productive, but a much more predictable form of management. The problem was not the Jira. It was the new PM who instituted the cultural change. Jira can be used just a well to document work done by intrinsic motivators.
- skewart 11y ago
  This, 100%. I agree that complex tasks are generally better solved in an environment driven by intrinsic motivation - heck, probably all tasks and not just complex tasks. I'm not sure if Jira and other task tracking tools can be used just as well to document work done by intrinsic motivators though. I mean, yes, they _can_ be, but I don't think they're as good as they could be. In fact, I'd say there's a big gap in the market for a solution that gives non-technical managers some reassurance that progress is being made while also not getting in the way of the ad hoc workflows the post describes.

gearoidoc 11y ago

Some good points but the argument that software teams will be most performant as a result of autonomy really depends on the team in question. I worked on a small team with 2 other developers who were both pretty good devs technically. However they treated the business side with almost-contempt and they would estimate even simple changes to take days. As the most junior member on the team I couldn't really influence them. Interestingly, after about 2/3 months on the job, the business side decided to use me as their initial go-to for dev.

bcjordan 11y ago

This stands as an interesting broad strokes story from a developer's experience at a growing company, but worth keeping in mind it's one specific scenario and one perspective on it. In the generalizations-from-this-instance part of the essay, watch for two false dichotomies—"developers that care about getting things done fast with little technical debt and hate having PMs" vs "mercenary developers who like doing one small thing at a time without architecting things themselves, don't find fast ways to do things and ps like cars and money instead of hacking". And "no PMs or process at all" vs "way too much process causing poor development time investment". The best developers, team leads, PMs, etc know when to introduce new processes and team members and when not to. And, importantly, how to tailor processes to each team member to make them as effective as possible. And they work together collaboratively to solve problems—estimating and discussing features flexibly, not tossing pie in the sky specs and finished products over the fence. In this instance it sounds like they didn't do a great job of working with existing scrappy developers' potential, but instead supplanted a new framework (eng/PM) they had seen work before, and the blunt hammer of that move destroyed a lot of potential the early team had invested in. It sounds like there was a general communication issue that was crippling the team even before a producer and new hires came in. I've seen a few teams now grow from no dev process to combinations of issue trackers, estimates, specs etc. Around 14-20 developers it becomes nearly inevitable for someone to take on a high level production role and someone to take point for engineering reliability, whether those are official job titles or not. Often this period coincides with when early team members move on. It's rad when growing companies find ways to keep those early, scrappy hires with deep historical product knowledge in productive roles as the company grows and shifts priorities from staff-leanness and product-speed to staff-scale and product-predictability. But that's often unfortunately not what happens, and it can be extremely painful for both early team members and those trying to evolve the company. (Growing pains!)

zwegner 11y ago

Great article, this echoes a lot of my frustrations working in the software world. It doesn't help that I've experienced being on a well-managed software team working on interesting problems--it kinda spoiled me for all those other jobs... :) Anybody have any advice for escaping this? I want the freedom to work on interesting things in my own way with a minimum of the politics. Ideally a PM would be someone who pushes back on all this micromanagement crap and does everything they can to make the developers' jobs easier. It seems I'm not self-motivated enough to do freelance work or start a start-up, so what other options are there?

bcjordan 11y ago
It sounds like you were at a company you enjoyed before—are they still hiring? :P If not, maybe you can do another job search and try to select for companies that manage their projects how you'd prefer. Try asking team members what the process is like and how they feel about it. Often times those Qs are more illuminating than ones about the software stack.

willvarfar 11y ago

Ah the "lets make the project cooler by adding a DSL so customers can add their own features!" never ever pans out! ;) I spent the 90s working on office automation projects that always seemed to degenerate into report DSLs. Is nothing new? The better I get at coding the more I am attracted to avoiding complicated tooling.

gearoidoc 11y ago
There's always a flip side! My current project has a DSL (not written by me) and it functions superbly. It does take about a full work day to wrap your head around though :)
fidz 11y ago
> The better I get at coding the more I am attracted to avoiding complicated tooling. Could you tell me your story?

abalone 11y ago

So a project was "months" behind schedule, they implemented an agile process for tracking tasks, and "everything slowed"? Slower than what? Being months behind schedule? I get that some PMs can undervalue refactoring code / minimizing technical debt, and that's super frustrating and shortsighted. But the basic premise of this criticism of agile process is deeply flawed: 1. The claim that features took "longer" to ship is directly contradictory to the admission that the project was months behind schedule. 2. If they were behind schedule, then "inflating" their estimates in response to a detailed tracking process was not, in fact, an inflation. It was a reality check. Estimates are really hard. But the solution is not to just "give autonomy" with zero estimation, because that's how you get into that problem they had in the first place: a guy in a room that doesn't ship for months. That's why agile's approach of breaking things down into tasks with very rough sizing and measuring actual after-the-fact time and shipping small milestones frequently is so helpful. You don't have to have super accurate estimates. You just need to report your time and then it figures out a team "velocity". That helps teams be more predictable, which is what it means to be professional and deliver things to customers on time.

Joeri 11y ago
Yet agile implemented top-down without team ownership of what to work on is not agile and not good for the health of the codebase. I have seen it fail repeatedly. Basically, if your team is skilled and capable, the process is not that important, as they will find a way to get things done. If the team is not good, the process won't make them much better. The key to a smoothly performing software dev team is good hiring and good coaching.
- abalone 11y ago
  So if you're behind schedule, your team just isn't skilled enough? That's kind of a dodge. Every team can improve. Instead of exclusively focusing on finding "good" developers, let's also focus on evolving "good" process. Time tracking, estimates, itemizing tasks.. these are in fact good things.
  - 11y ago

option_greek 11y ago

Sometimes I feel JIRA is the manna (http://marshallbrain.com/manna1.htm http://marshallbrain.com/manna1.htm) for software developers :(

edderly 11y ago

Not 100% convinced by the conclusion. There is good project management which can be relatively fine grained, but it doesn't have to be micromanagement and it doesn't have to be a death march. There are some basic red flags raised: > Our project manager would be displeased when tasks took longer than the estimate and would immediately assign one of the other team members to work with the original developer to hurry it along. Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks > Whenever there was any debate about refactoring the code, or backing out of a problematic feature, the new guys would argue against it, saying it was ‘ivory tower’, and not delivering features. The PM would veto the work... Why does the PM have a veto? No technical lead or management with balls? PM's need to manage the features of a release and changes to the plan. Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management.

vfc1 11y ago
> Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks The problem is that if the PM decides to do that, the developer has no authority to refuse that. > Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management. Most PMs are just proxies for business, they manage up and out but not down. They will not risk their jobs by refusing requests from business, in the long term that would put them in an unsustainable position.
- ViViDboarder 11y ago
  Maybe at some companies. Where I work, Engineering Managers and PMs are totally separate. So Engineers have much more representation. But, even in places where this is not the case, they are willing to hire-- spend money - - to speed the project up. If it's made clear, not just to the PM, that it's going to cost money and have no positive effect, it should be a clear business decision.

pacaro 11y ago

The moral of this story is that "let's create a DSL so that users can encode their business logic" is jumping the shark. I was mildly disappointed that the hero of this tale (the PM) didn't fire the "DSL guy" on day one

bcjordan 11y ago
DSLs for stakeholders aren't always bad. DSLs thrown over the fence without early and regular stakeholder testing are usually bad though :)

nostrademons 11y ago

The more projects that I've shipped from conception to completion, the more I'm believing that there are two fundamental phases for each project, and you need radically different management philosophies for each. Phase 1 is "will it work?" You get a vaguely-specified business requirement, maybe some intuition that a market could be better served by software. And your job is to build that software, and figure out exactly what's required for it. In phase 1, you need the creative-genius programmers, and they need to work in small teams with large amounts of autonomy. Because most of what goes on in phase 1 is failure: you are learning about the problem space and all of its corner-cases, you're trying out different approaches, and you're hoping to make that one creative leap that brings everything together. Prototyping is invaluable, refactoring is important, and deadlines and estimates might as well be plucked out of thin air. To successfully run a phase 1 project, you often need to be able to redefine success. When I read the article, my first impulse was to say "Well, the biggest fuckup management made was to not cancel the feature, because they had ample evidence that this feature was not worth the cost." A startup's entire life is spent in phase 1, because once it's exited phase 1 it's called a "high-growth company", and their version of redefining success is the pivot. Phase 2 is "make it work". You start phase 2 with a working prototype that demonstrates the feasibility of what you're hoping to do, but still has a lot of rough edges. And your job is to polish it down to something that the customer wants to use daily. That means fixing bugs, improving usability, adding admin tools & logging, improving performance and reliability, ensuring security, etc. In phase 2, you need a much larger team of disciplined, detail-oriented engineers. Because debugging can be parallelized. You need unit tests, you need formal processes, you need issue trackers, you usually need PMs or management. It helps to break things into user stories so that you know you're always making progress. I see a fair amount of hate for Agile and Scrum on HN, but these are tools, and specifically tools for Phase 2 work. I use them myself, for my own projects, because I find that they help me manage all the little tasks involved in bringing a product to market. The hate comes from people who misapply them: startups who have big-company management who blindly apply what worked at their last employer, or established companies that are trying to do new green-field projects and believe it works the same way improving your 10-year-old product works. But similarly, there are a large number of abandoned startups and open-source projects that never bothered to cross the Ts and dot the Is, and so are largely useless to people.

gyardley 11y ago

Oh, the joy of being a product manager for the particular type of programmer who, by virtue of being a programmer, also knows absolutely everything about absolutely everything. This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month, but if they disagree with a tiny aspect of the feature you've brought them, the deep domain knowledge you were hired for and dozens of customer visits you've done are nothing in the face of the awesome might of their computer science degree. Better get comfortable, because it's going to take you several hours to persuade them that you do in fact know how to do your job and the wild-ass alternative they've just come up with is wanted by the market about as much as syphilis. With these guys (and they're always guys) you've got to process up and micromanage, because the only way to get a little bit of intelligent estimating out of them is to ask for ten times as much, so they can give you what you need while still feeling like they're largely ignoring you. The only silver lining is the process eventually makes them leave, so they can be replaced by people who work well with others. You know, I really don't miss being a product manager. Ranting aside, good developers in larger organizations realize that people have specializations, they and other parts of the company are interdependent, and a little administrative overhead is necessary to keep everybody moving forward together - so they work with people from other parts of the company in good faith, and this makes it possible to keep the administrative crap (which no one likes, it's not just them) as light as possible for as long as possible.

PhantomGremlin 11y ago
This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month A comment in the article made a similar point. QFT: I dare say you wouldn't win much work though turning up to pitch to potential customers and declaring that you'll definitely deliver something, but you don't know how long it will take or how much it will cost. Every employee needs to be aware of time, of deadlines, and needs to understand that the money to pay their salaries needs to come from somewhere. Or they need to find a job working for some government agency, or in academia, not in the real world.
- mobiuscog 11y ago

mikekchar 11y ago

The "Heisenberg Developer" name is really excellent. I recall DeMarco saying in his excellent books (so many years ago): Do not measure anything unless you have a very specific action you want to take based on the data. Why? Because every measurement alters the way programmers work. The author reports that increasing the granularity of the work (and thereby decreasing the time between measurable status updates) led to a lack of refactoring. I have also experienced this one and it led to much head scratching on my part. Which is not to say that one should not measure. I've never actually used Jira, but apart from that, many of the things the author talks about are generally good ideas: reduce story size to a day or so, prioritise every 2 weeks, measure delivery at about the same interval. Don't throw the baby out with the bath water. I can say with some confidence that where they went wrong was that they tried to estimate the stories and then they made the cardinal sin of trying to measure the elapsed time for each story. In the first case, you don't need estimates. Each story is a day or so. It's enough granularity. In the case of measuring, there is no organisational benefit. You can see the average throughput of stories. You can estimate your final delivery (especially if you use a defect growth model to estimate how many requirements you are currently missing before delivery). Measuring the actual time of an individual story adds absolutely nothing to your control of the project. The main argument that I've heard for measuring are two fold. First they feel that measurement will allow people to get better at estimating. Again, it is not needed. If you have a granularity of a day or two in your story sizes (and your throughput is showing that you are achieving that), then you have nothing to improve. If your throughput is not there, then you need to see what the problem is. It will be one of 3 things: your stories are too big, your code is too complicated, your programmers are crap. The first is solved by making your stories smaller, the second is solved by working on technical debt, the third is solved by firing your programmers. I recommend doing everything you can to solve the first, move on to the second, and only then resorting to the third. What measuring will give you is an idea of the variance in the story sizes. This is unimportant. In fact it is critical not to measure this. All you care about is throughput. Variance is where the developers are putting the extra effort in to improve your throughput (by dealing with technical debt, improving tests in critical areas, creating efficient build systems, writing documentation, etc.). If you remove the variance (as described by the author), you destroy the ability for the developers to optimize throughput. The second argument for measuring time is to identify stories that are (or were) in trouble. Again, this is unnecessary. First, if you have a story and you are having a hard enough time that it is taking you longer than a day or two, then you already know about it. Asking for help is what stand up is for (and really, I hate to have to say this, but that's all standup is for). If you are not having trouble, but you are spending a few extra days to refactor something, then you already know about it. Everyone else does too because they can see the code that you refactored. If you are sitting on your ass and wasting your days writing extremely long posts on HN, then you already know about it. And so does everyone else (because you haven't written any code today, and it's not like you asked for help...). I'm just going to write this one time. If your reasons for measuring the amount of time for stories is because you secretly think that your developers are crap and that they don't know what they are doing, no amount of measurement is going to solve the problem. Make a decision. Fire them, or not. You can't make a crap programmer good by pointing out how much time they spent on a story. They already know it.

ArkyBeagle 11y ago

There's no "Heisenberg" here - the company decided to do the moral equivalent of invading Russia in the winter. I quote - "Then came that requirement. The one where you try to replace an expert user’s years of experience and intuition with software." The only problem with "finely grained management" is that it costs too much.

partycoder 11y ago

About processes: You add a process when you want repeatable results. Adding blocking, synchronous steps involving people slows things down. Adding non-blocking, asynchronous, tool assisted steps are less intrusive in people's work. About hierarchies: You add hierarchies in your organization when your quorum involves too many people and things slow down. Hierarchies exist to make consensus building simpler at the cost of representing fewer people and all the associated consequences. Hierarchy must not be abused. People need to be respectful towards others regardless of hierarchy. Each contributor is important. About quality and technical debt: If you are always reacting to defects, you lost control of your product. You can no longer plan because you are too busy reacting to ad-hoc unplanned work. This is unprefessional and unnecessary. Keep things under control by being preventive, proactive and professional. If someone tries to convince you that non-functional requirements cannot be sold, remember that person that person to focus on functional requirements and leave the non-functional requirements to the engineers.

jondubois 11y ago

I've worked for companies like this. What's hilarious is that most of the employees at these companies take the process very seriously (they obviously don't know better). I've worked at both startups and big companies - I find that fine-grained management in big companies is extremely inefficient. In software, the more constraints you add to a project, the slower things will progress. It gives non-technical managers extra visibility at the cost of speed and agility. I can't help but chuckle to myself whenever we have a 'retrospective meeting' - Every single time, it's the same problems that come up over and over again (related to management/communication issues) and these problems never get fixed. What's even funnier is that the closer we get to a deadline, the more meetings we have - And the more it slows us down. There is a fundamental problem with having very fine-grained cards/stories/tasks; often, related tasks are assigned to different people but it would have been much more efficient to assign all these tasks to a single person.

yetihehe 11y ago
> It gives non-technical managers extra visibility at the cost of speed and agility. Hmm, just like with tracing. The more finegrained tracing, the more resources are used for communicating what you do and less resources are going into actual doing. Developers understand this, managmenet may not. Management IS about communicating, so they try to "Do Something" and enforce more communication.
dev360 11y ago
>>> It gives non-technical managers extra visibility at the cost of speed and agility. Keen observation. Often times these situations are just self-inflicted wounds on the part of devs too. I have worked with many devs that have had a habit of keeping stakeholders and coworkers in the dark just because they feel like they are too important to be bothered/be held accountable. I know what I'm in for if a project management or glass house CIO is all of the sudden needed, so my top priority is always to primarily earn the trust of business stakeholders and to be as honest as possible.

taylodl 11y ago

Ever work with an engineering team? Building new weapons systems? Fighter planes and the like? Just as creative an endeavor if not more so than software development yet they have schedules and budgets to meet too. And yet people's lives depend on the result. Software development can learn a lot from other engineering disciplines.

seivan 11y ago
I feel like you might have missed the point. Also you're assuming these engineering teams for weapons systems and fighter planes are successful by default. F-35?
- taylodl 11y ago
  Not all engineering projects are successful either. What I'm saying is there's a lot of similarities between these disciplines and so there exists a large body of knowledge and experience from which we can cull and learn.
FLUX-YOU 11y ago
Software dev isn't driving this, business is. NASA coding practices prove we can do exactly what you're saying, but businesses don't care for (or don't often need) the rigor that NASA requires. I'd bet a lot of people would enjoy participating in NASA-quality projects if only to experience it and feel good about producing rock-solid code even if they only commit 50 lines total, but they are very rare.

vfc1 11y ago

This is one of the best posts on software development I've read in many years. Each sentence rings true and is an amazing read. Its like the author is describing many of the projects I've worked before. Micromanagement and software factories are the death of software development. But then no matter how much I dislike these management methods, I can see why they are put in place. There are certain developers that get to a project and just start rewriting everything with no good reason, introducing new cutting edge tools and frameworks for the fun of it and for pure CV driven development. They introduce huge bugs close to release dates, breaking browser support, refusing to test on IE. Lets face it, loose canons exist on all teams and we've all seen it before. This is OK and necessary in the early development cycle, but when things get to production its different. One day something gets seriously broken, and management comes in putting in JIRA or equivalent, and micromanagement starts. Demotivation of the early developers sets in, the ones who knew how to setup an architecture and make technical decisions. The leave and are replaced by other developers that don't necessarily could take those decisions. The project entered a pure maintenance phase, where business as sort of given up asking too many features, it just costs too much and the results are less than ideal. The project enters the keep it running final phase, where noone knows how certain parts of the system work anymore, all original developers long gone. Here the goal is to touch the code as least as possible and its no longer a development job, its mostly technical analysis and troubleshooting of test environments. Then 5 or 7 years have gone through, and the business decides to replace the system with a new one and the cycle starts again. The only way i've found to deal with this, is to become a contractor and work mostly on early to mid phases of projects. When the project enters pure maintenance I wait for a few months and then look for a new project.

iamthepieman 11y ago

This is similar to an experience I had. Me and the small dev team were being micromanaged. But we were getting lots of new customers for version 2.0 of our main software product and specifically targetting feature relases to snag certain customers, I feel like it worked from a business perspective. We didn't have time to refactor, didn't have time to anticipate how something would be used in the future and build extensibility into it and the number of hacks in the codebase grew daily. most of us on the dev team knew it was going to be a complete disaster at some point. It was going to take a week to fix a simple bug because it's copy-pasted in 7 different places and something derivative now relied on the bugs behavior. But we were releasing fast and getting money because of it. Initially we fought it but eventually I just figured that if I wasn't on another project when it came time to pay the piper then I'd just find another job. I had given my warnings - when I did have time I still tried to do things right and refactor old code. Ultimately though, the business tradeoff decisions weren't mine to make and I wasn't going to lose any sleep over it.

rocky1138 11y ago

This post should be pinned to the top of Hacker News.

draw_down 11y ago

I say it's a mistake to expect to have creative control at all, over something owned by the corporation you work for. Best to accept that it's not your baby you're working on. You don't get the profits or the glory or any of that. Just do your tasks and treat it like what it is: a job. Creative control and passion and all that is for side projects and things you build yourself. I just feel it's setting yourself up for disappointment to think otherwise. Companies are not founded to provide the ideal environment for software development. They are founded to make products and hopefully a profit. You might argue that a smart business person would provide that environment in order to get their product built, and maybe you'd be right, but that also risks building the thing developers want to build as opposed to what could sell. And as soon as you intervene, poof goes the ideal environment. So even if the environment exists at a company, as at the beginning of this story, it's best understood as a happy accident and shouldn't be expected to last.

kolbe 11y ago

Work long enough and with many different companies, and you will inevitably have had an experience much like this one. And it's not just in software. Any profession that relies on some form of engineering knows what this is like. There's a reason why Dilbert is so funny.