Business leadership is technical, they create the requirements with technical leaders, those leaders build out the roadmap. I don't believe in 'agile' but I think 4-6week chunks of work broken off and worked on by a small team (2-4 people) works well. I like to see small design doc to ensure open questions are ironed out that gets signed off on by stakeholders - everyone should be committed on the vision and these signoff should happen relatively quickly, ideally comments resolved and go/no-go decision within a week.
The small team should have a lot of support in terms of an infrastructure platform, strong culture and tooling for development/testing, project management set up for them, an escalation path and check-ins where they can raise blockers. There is a template but essentially the small team is left to work how they want to work.
After the 'chunk' is delivered, there is a week of wrap up, and then a week of maintenance where people are allowed to work on whatever they think is the most pressing issue.
Very detailed design documents can also be lovely. I've personally worked at a few organizations where expected behavior was ironed out before we started building it. (Banking, Engineering etc. will be used to decision flows, so this can be common.) The Million Man Month covers the effectiveness of good schematics.
However the technical people needed to work them out with stakeholders can be expensive to have fight with stakeholders for ages, so it tends to be rare. And of course many domains are unknown, so you just keep reiterating until something sticks.
Modern agile sucks, but if you read the old discussions on c2.com of how agile appeared e.g. https://wiki.c2.com/?AgileProcesses there really is a lot of value to find, learn and apply. Of course, the ninjas, blackbelts and cargoculters kill that.
An MS-DOS based program in GWbasic, or Turbo Pascal from the 1980s, or a Visual Basic 6 prototype that someone wrote in the 1990s and still gets the job done, or an excel sheet/google doc that someone does to do the calculations "by hand", are all excellent requirements documents.
They do the work, are executable (so you can test against their behavior), and already account for all the normal error handling, etc. The people who wrote them saved you a few trips over the waterfall, and perhaps a decade of grief and work.
Your closest bet today is to fire up Lazarus anywhere, or VB.NET on a windows box and quickly build the prototype. Once everyone agrees on its behavior, then you're back to the races again. Get buy in on a single quick and dirty prototype, then scale up from there.
They can be a wonderful resource for the validation tests, but a developer needs a model to start. The documentation of existing tools may be a nice requirement document, provided it is exhaustive enough.
By the way, every time I was requested to implement something "exactly like this gizmo here", I proposed to just keep using that gizmo there, and then the discussion became interesting: "No! We want the same, but...."
As soon as the "but" was pronounced, the person in front of me realised the gravity of the situation: they didn't know what they wanted, and by handing me an ancient (despised) tool they were just planning for me to fail and for them to throw me under the bus.
I’ve seen design docs that are vague, and design docs that are so detailed and specific that they can’t be kept up to date. I don’t know that anyone has found a happy medium.
The week of wrap up and the week of maintenance is so important, and has basically never been there at places I have worked.
Managers reading this - if you constantly jump from new features to new features you will ensure that your developers are forced to cut corners, make an unmaintainable mess, increase bugs, development velocity will slow and developers will burn out.
It also causes incentive alignment problems, if I push myself to deliver great quality on-time, and I’m striving and working hard, then I don’t get so much as a “well done” and then an immediate enormous chunk of new work - you’re rewarding hard work and quality with large amounts more work, what’s my incentive to perform? Exhaustion?
I feel the same way, but the countervailing force is significant group of managers and developers alike who really truly hate spending any time without a rigid structure. Having never taken the time to build a proper mental map, they are lost without a detailed literary. They're allergic to open-ended tasks and use process as a crutch for their lack of confidence.
Dealing with ambiguous technical problems is scary; there is a real prospect of failure, or going the wrong direction, or hitting an organizational blocker, or failing to anticipate changes... Some would rather work on an assembly line (and force their colleagues to as well) just so someone else can shoulder the responsibility for the hard problems. And their numbers are large enough to influence how software is developed.
I'm inclined to believe proper agile is a myth. I have never seen it done correctly, and it's always spoken about ideally. All forms of agile I have seen or heard about always breaks down in real businesses environments.
The Agile Industrial Complex is a horror show, but that doesn't mean it's not possible to do agile well.
There absolutely is a way of doing agile well, I've been involved in a number of teams that did. And it worked extremely well. In fact, we did agile way before the agile manifesto came out, and before I was aware of there being a name for the things we were doing. We were just doing them because they make sense, they make us go fast and they let us have fun while doing it. Which is basically what the XP people said when they started writing things down. They never claimed to have invented a brand new way of creating software. No, they were observing that certain teams were very productive, and looked at what those teams were doing. If there was a pattern. Spoiler: there was.
Anyway, I also introduced agile "practices" in a large company. Well, in a small team in a large company. We didn't do a single one of the practices the Agile Industrial Complex proposes and often mandates. The much more important team next to us did. They did all the AIC practices. We did the technical. And interacted closely. Did TDD, worked on trunk, paired when necessary, did stuff alone when not. Did the simplest thing that could possible work. ("Where's your database?" "We'll put it in when we need it". <later> "Oh we're done. I guess we didn't need the database ¯\_(ツ)_/¯" ).
The more important team next to us that was doing Scrum with the standups and whathaveyounot failed. We delivered. Hmm.
And if you can point to the practices being promoted by the AIC as being in direct and obvious conflict with, for example, what's written the Agile Manifesto, and can in fact point to ways of doing it right that are in harmony with the AM and in conflict with the AIC, then it ain't a No True Scotsman fallacy. It's a simple case of the AIC doing it wrong.
I too have seen great agile. However, it required the team to be in control of its own destiny. Namely, we didn’t have deadlines and the goals we reported against were impact. That meant we could run no-weekly sprints while safely fitting delivery into the goal reporting timetable.
In most companies, it seems management is incapable of measuring progress other than “will X be done before Y date”.
maybe the idea of "proper agile" is too vague to even be useful?
"That's not agile"
Has become one of the most annoying arguments I've ever heard. As someone who experienced a corporate takeover of agile "consultants", I can tell you, it is one of the hardest things to try and deal with people who have their own idea about agile.
"Proper agile" is too "team specific" that maybe it shouldn't have been a "manifesto", just call it good "team practices" and maybe it wouldn't have become such a cult
I’m adding that to my list of corporate tech paradoxes
It joins:
- Innovation departments being built the least innovative departments you’ll ever meet
- HR departments being the worst at dealing with people
I always enjoyed the irony of rigid adherence to agile processes. My philosophy has always been to ask "what are our goals" and then figure out how to make our process be in service of those goals. Scrum does provide some useful frameworks for estimation and planning and continual reflection & improvement.
Agile as a noun is a myth. Agile as an adjective is a journey. When I've seen a company being agile and responding to change it's not because they are using some system they learned at a seminar, it's because they trust their engineers to do the technical work, trust their product people to have solid relationships with customers, and empower both groups both in their individual roles and when communicating with each other.
All of this is to say that I agree with you. 'Agile Methodologies' are a crutch for companies that cannot tolerate agility
I'm not sure you have brought that reason. A sample size of 3 where only one did better than "fairly well" would not be my reason to advocate for "Agile" to be the "industry standard."
Across my sample size of about 7, half were maybe better than terrible, but only two were good enough where I would say it helped more than it hurt.
The tech industry I think would do well to more rigorously study "Agile" and do some A/B testing. Unfortunately this problem space feels like trying to A/B test forms of government. The downsides are generally known after the fact, are context specific, and there are few good ways to run a control
same for the legendary "maintainable/evolvable/perfectly encapsulated code". yes, until the team is very skilled, everyone is disciplined and there are tight processes around learning the architecture. 3 bad hires later because "investors want growth!!1" and you're done :D
cool links, thanks for sharing. I also share your feelings, but reality (or burnout) is starting to take its toll on me and I see too much uninterested people working as SWEs nowadays. I mean, tooling is probably part of the problem, but quality is going downhill real fast, with people with 2/3 years on the job not understanding simple things like HexArch or basic patterns (not advocating for anything, just mentioning something that should be common knowledge in 2023).
I'm starting to think that if we want to maintain this "race to the bottom" pace, we need a more industrialized/blue collar approach and be more less about the person and more about the tool. Most jobs in my area are web crud controlling a transaction script. there is no problem to solve.
I mean, tooling is probably part of the problem, but quality is going downhill real fast, with people with 2/3 years on the job not understanding simple things
I agree but I also wonder why we would expect them to.
Many coming into the industry have had little formal education in CS or SE. Employers providing substantial training is mostly a thing of the past because retention and professional development for employees has mostly been deprecated in favour of the rapid job-hopping culture. And for a while now it's been such an employee's market that developers haven't needed to invest their own time and money into professional development in order to progress their careers.
So even for relatively senior devs it's easily possible that they could have little academic education, little professional training provided by any of their employers, and little incentive to spend their own time studying. Their understanding might come from nothing but a few years of experience working on only 2 or 3 different products and - if they're lucky - some ideas they've been exposed to through more experienced mentors, team leads and code reviewers.
I personally believe our industry would be infinitely better if we could get back to the idea that professional development is important and employers should both look for people who've been learning and then support their people's ongoing learning themselves. Maybe we can even do that now that the gold rush is over and job-hopping every five minutes for a pay and title bump is no longer the most reliable way to climb the career ladder.
The key differences from the most common implementation of agile are bigger delivered chunks, multiple sets of smaller self driven teams, no highly prescriptive ways of working, and avoiding constant 'sprinting' with at least two weeks dedicated to bug fixing, maintenance, and retros/self improvement between 'sprints'.
Business leadership being technical cannot be overstated. At my current workplace, we’re not allowed to say the word refactor to management as that freaks them out. My current place also has the most spaghetti code that I’ve ever seen in my life with more spaghetti being produced on a daily basis.
We technically have technical leaders, they used to be engineers eons ago but I don’t think any of them could solve first 3 days of advent of code to save their lives.
It's good to trust your people. You want to foster independence among teams, can do spirit. But most orgs seem totally out of touch with the tech. Too many companies use only business success to discriminate on. And that's just too random, too chaotic to let the work be judged on, to decide how next to operate. There's too much decision making about where to go that needs a deeper level of consideration.
The six week cycle with down time in between chunks can be very effective. The crux is to make sure those blocks are properly scoped to make the best use of everyone's time.
This reminds me of the excellent book 'Shape up' by the team from Basecamp. They also champion upfront 'scoping' to make best use of those six weeks. Highly inspirational book for technically mature organizations.
Stop being productive. Just stop. Stop this insane qualification. Stop this forever-measure. This race for immer besser, always better. It is so saddening.
I came into tech for the joy and the wonder. You don't measure joy. You enjoy joy.
If you want to be in tech for joy and wonder that's great but that's not the same as being in a business. If you want to be in business and make money then output matters. It matters less to some companies than others but it always matters at the end of the day.
What I've seen in my career is that when developers were motivated by joy and wonder like 2830 said, or by a sense of mission, etc. productivity and customer satisfaction was high. But when the emphasis turned to productivity (CMMI 5, KPIs, OKRs, Big "Agile", punch clock tool in JIRA issues), the only thing that went up were numbers in a paper.
It's not that money and output are not important for a business, but obsessing with productivity may cause the opposite effect.
Or just maybe there's a way for us to prioritize the human aspect of work, such that we can acknowledge how important joy and wonder are, while still making money and providing value.
Otherwise we're going to just keep burning more and more people out. And for what?
This isn't an argument against what I'm saying though. You cannot be in business expecting it to be 100% joy and wonder. You have to be conscious of the "providing value" part of your statement. There are companies that have excellent work-life balance and provide ample space for play. I work for one of them but if the value you provide is 0 and you expect a 100% wondrous joyride, you won't be there for very long
the eternal dilemma of the min-maxers and the roleplayers.
the productivity cult are the min-maxers.
living cannot be min-maxed.
even productivity cannot be min-maxed, save for the short term, for the simple reason that we don't know what productivity is. technological revolutions are the prime example of this, where each turn of each revolution shifts the entire idea of what being productive is.
> You have to be conscious of the "providing value" part of your statement.
Perhaps if "providing value" is something you have to be conscious of and not something that comes about naturally from doing what energizes you then that's a signal to pursue a different line of work.
Having joy & wonder from what you build (and the value it provides) I believe is tangential to work-life balance. Why is work-life balance pertinent when the question is: "can we stop focusing on being 'productive' and focus on building the right things, that deliver value in unexpected deep ways?"
Another question, why does a work-place need to provide "ample space to play?" I have trouble knowing what this means. At a hack-a-thon, rather than building some throw-away project that was going to be a space to "play", I opted to see if I could decrease the test run time from its current 25 minutes. Obviously this was not a popular hack-a-thon project, but it was by far the most useful (all the others while cool, were never fully integrated).
I somewhat wonder if the "ample space to play" is reflective of an attitude where engineers need to be managed, and like children they need some recess time to burn off excess energy and to be made happy. Is that your take at all? What benefits does this "ample play" provide, and what does that look like? A very important element of job satisfaction is to not have your work thrown away. A "play" project seems exactly something like that. Given this, my impression of providing space to play means: (1) the developers are not taken seriously, are things to be managed, and are not partners in identifying user and business needs, nor are they drivers of identifying business process value [eg: hey, we could automate this, we could optimize that, what if we tweaked this thing a little bit and could then solve a few user-needs at once; vs just building what you are told exactly how you are told]. (2) the 'space to play' is going to be demotivating. "hey, the regular stuff is soul sucking, so here is some time to do something that is not soul-sucking, but it's 'play' and whatever you choose to work on is just a toy and like a toy we'll throw it away.
So, I'm really curious what this "play time" or "play space" looks like. If a developer chooses to work on something, either they are picking projects that do nothing, or they are picking projects that arguably should be already integral to the business development process (and hence should not be 'play' projects at all). Overall, it is work, and if you tell someone that has spent 3 days debugging J2EE configs or YAML configs that they should not expect 100% joy and wonder, or spending a week trying to fathom what the previous time rushed (time-boxes & project focused) developers jammed into the system, & you'll probably getter a rather curt 2 word response rhyming with 'no pit'. That is to say, it is work, I don't think the development profession expects for there to be "space to play", and if so, why are we bothering with wasting time like that? (which seems to be a good way to boost productivity, cut out this throw-away play-time. If developers want to play, as in boost productivity by developing their personal skills, that is for off-the-clock [find an OSS project]).
Sorry the rant-like nature. In sum, I do have these questions:
(1) Why is work-life balance pertinent to productivity at work, as related to development process? Asked another way, how does a work-life balance interact with any "Agile" development process such that the efficacy of that agile process is changed by 'work-life' balance?
(2) What is "ample space to play" - what does that look like? What artifacts come out of that? If useful things are being built, then why isn't that just part of the work? If useful things are not being built and are being thrown away, how does that help anything?
If I read your comment with extreme charity, I think that sentiment boils down to the fact that everyone needs money to continue having food, shelter, and medical care. If I read your comment mildly charitably, it would reduce to a tautology: everyone who works for money wants money. If I read it uncharitably, meaning anyone who does sustained, hard, taxing work wants money, I would argue it's easily disproven since people do incredibly hard work as volunteers. It baffles me that tech titans rail against government and academia, and think everyone has a single-minded desire for money, when the Internet (gov't), the World Wide Web (academia), and Linux and a slew of open-source software (volunteer) powers our lives.
Employees are not in bussiness. They are employees. Employers are in bussiness. They get all the risk and the profits. Now they just want to push the risk to the employees, but keep the profits (all recents official and unofficial layoffs)
When I feel joy and wonder at work, I'm incredibly productive and I work long hours on top of that. When my senses of agency, exploration, and play are undermined, I'm deeply demoralized and find it very difficult to focus and can't wait to walk away from my computer.
I'm still trying to figure out how to better regulate myself away from those extremes (how to put my work down for the sake of other aspects of my life when I'm excited on the one hand, and how to push through and 'reset' when I am frustrated by something outside my control on the other). But one of the things I've already learned is that focusing on productivity in terms of sheer discipline doesn't really work. I get a lot farther working with self-reflection on my emotions and carving out space for joy and freedom in the formal structure of my work week than with sheer mental effort.
I have it similarly. For me, if I can't "play around" or explore something new in a while, my motivation and focus drops to zero.
On the other hand, most days I'm just too mentally exhausted to work on programming when I get home. So I rarely get to scratch that itch on my own time.
To get around that, every now and then I take some time while working on some issue to do something new, like play around with programming language constructs and exploring the limits of the language.
It's not always easy to do though, with deadlines and whatnot. So can be a real struggle at times.
The joy and wonder you feel in tech comes, directly or indirectly, from a lot of prior capital investment. Trillions of dollars over the decades, and a sizeable portion of those outflows are into developer salaries.
Any trillion dollar capital outlay will invariably measure performance, irrespective of the motivations of sector's people.
I wish the “how much an engineer can focus” section was first, because that’s been by far the biggest bottleneck in most organizations in my experience.
All the other things the engineers can themselves address (e.g. better tooling, etc), but the organization’s culture around protecting makers schedule is impossible to address individually
> All the other things the engineers can themselves address (e.g. better tooling, etc)
Everyone choosing their own tools? Isn't there usually some central department that takes care about that, at best controlled by a kind of committee representing those who use the tools, typically full of people who are no longer doing practical work and have no idea what improvements have been made outside of the company during the last decades?
No, the best organizations have a happy path laid out for org chosen tools and a platform that supports adding in “non standard” tools / libraries by individuals and teams as needed, with a defined path toward those additions become the new golden path standard.
There needs go be a balance. Common tools are useful, but you need to switch which tool you use from time to time as the old one gets stagnant (or bought out and the new owners raise the price too high).
Sometimes people change tools for the wrong reason. I've been in many companies that changed their bug tracker because the old one was too cumbersome, but they never addressed why all those mandatory fields were added to the old one, and so in a few years they learn the hard way and now the new one is cumbersome because of all the mandatory fields.
I don't think the obvious things really help though. Whether a compile takes 5 minutes or 10 minutes, you are still going to async out of it and do other things. You might not come back to it until well after, eg at 15 or 30 minutes. If the same compile only took 10s though, you would stare at the screen and then get to testing immediately. So it's definitely non-linear in the sense that it would be great if it were super fast but if it's already slow, being a little slower doesn't harm much. With all the tooling, there's a distinction between fast enough to use synchronously and so slow that you need a reminder to come check the results.
IMO the thing that really matters is domain knowledge, a fancy way of saying judgement. If you know your domain you might avoid the most expensive mistakes: having to change language or framework, requiring entirely different developers, bricking hardware that you paid a lot of money for, buying services that you don't need, writing code that won't be used.
Another thing I'd mention is having people to bounce ideas off. LLMs are actually ok at this, in the sense of spitting out lists of things that you might have missed. But in general having another expert around to really discuss stuff saves a lot of time going down caves that you forgot not to go down.
Productivity is absolutely a nonlinear with compile time. I work in Go, so compiling doesn’t take long enough to cause me to async away. Big switch from C++ a couple jobs back where iteration time was measured in minutes.
> It’s frustrating to hear the statements “you must use our infrastructure” and “you can’t do that with our infrastructure.” You waste time either working around the infrastructure or sitting in meetings where you attempt to convince the owners of the infrastructure to meet your needs.
Listen, I'm an infra guy, so maybe this hit a nerve, but 'othering' infra because it's inconvenient has got to stop. Infra serves many masters and you are probably the most flexible of them -- that's why there's so much push back.
IMO... infra teams need to realize that folks "othering" their infrastructure means the infra team isn't meeting their needs. Infra teams are now competing against DIY and PaaS solutions, especially all of the fly by night YC startups. Infra teams need to prove their worth or get out of the way and let the devs go buy a solution that replaces the infra team. The business cares about time to market, not the perfect little homegrown PaaS the infra team built.
Very true. I realize infra teams have their own priorities but all too often I meet infra folks that would rather tell me my requirements are wrong than work with me towards a solution. If you're not getting better customization from the inhouse team then it's not hard to see a big paas is probably a better offering than what the infra team deems necessary.
> Infra teams need to prove their worth or get out of the way
This is an incredibly demeaning comment. Assuming your colleagues have inherent worth and that they're doing their jobs reasonably given the constraints and demands placed upon them is a far more humane way to go about work.
> The business cares about time to market, not the perfect little homegrown PaaS the infra team built.
Those "perfect little homegrown PaaS" solutions get built for a reason - because of what happens after you get to market: the business starts to care a whole lot about how much it costs to run the thing you just shipped.
One of the main reasons a "perfect little homegrown PaaS" gets built is because it's typically a lot cheaper to run in-house. Lots of downsides to it, for sure, but you can't neglect the immense cost of a PaaS when you're running a business.
That sounds cute, but humans don't have inherent worth in a business. If you don't contribute to success (and aren't good enough at deceiving people that you are), you're going to get laid off.
I think that's what the parent comment is saying - infra is competing with potentially cheaper and more flexible solutions. Even if they do their jobs the best they can, put 100% effort in, yada yada yada - if there's a more efficient solution, infra as a whole will be left behind.
For example? The managed or cloud or... solutions are normally magnitudes more expensive than in house. PaaS are the closest in cost, due to the admin savings etc. but even there, we know current prices are investor funded to gain share.
At the far end, compare what you can get for $150/month at Hetzner vs. AWS. At real scale, paying for an infra team to run it will save a lot of money (and I've yet to see a fully managed solution which doesn't have a team of YAMLers anyway.)
> That sounds cute, but humans don't have inherent worth in a business. If you don't contribute to success (and aren't good enough at deceiving people that you are), you're going to get laid off.
Of course humans have inherent worth in a business - humans are the business. I refuse to emulate the hyper-capitalist mindset of "some people are worthless." I'm not sure if you're saying that this is a value you hold, but it is certainly a value I do not share. There's a lot of room to talk about what "value" is in a business (including how some "value" is more readily quantified than others, and how we tend to mistake that for the only "value" that exists). But we have to stop conflating that with the worth of the humans in the business - that's not a humane way to view your fellow man.
> infra is competing with potentially cheaper and more flexible solutions
[citation needed]
I've been in the field for awhile now, and I can't say I've ever seen a PaaS turn out to be more flexible or cheaper in the long run. Even my beloved Heroku, to whom I compare all present and past PaaS offerings on the market! There are some limited exceptions I recognize for things like internal applications, or niche applications that do not have a broad user base (and never will), but I don't think those exceptions are enough to support the statement.
Our industry chases fads in a circle. This isn't the first time we've all decried "infra is bad, long live hosted services!" - Heroku's heydey wasn't that long ago, and I fondly recall App Engine being a big deal. Then the bill comes due and people migrate. Hell, you could even consider mainframes a part of the cycle, if you squint at it.
I used to badmouth the MBAs at tech companies to no end, that they don't get it, just do management planning porn, aren't around for the consequences, favor sounding good over being substantive, and generally could all be fired.
I then realized later that leadership and getting a large group of humans to work on a common goal is very difficult.
The idea the other group is doing nothing is usually a perception (or a lack of perspective, lack of empathy, and maybe arrogance), usually.
100% this. If your company can run on a managed platform then it should. The reasons the whole world isn't already include: GDPR, SOC2 (audit, role level responsibilities), customer firewalls, encryption requirements (hello FIPS).
I don't agree. People are far more expensive than managed infrastructure and that is what the comparison should be... not against 'bare metal.' When you compare the managed infra costs to bare metal directly, you are comparing apples to oranges.
We run an 8 figure business on mid 5 figure managed infra costs. An infrastructure team would be several multiples more expensive than that... even if it was a single individual.
Just because you can do it yourself or more cheaply, doesn't mean the effective business costs are less.
>People are far more expensive than managed infrastructure and that is what the comparison should be... not against 'bare metal.' When you compare the managed infra costs to bare metal directly, you are comparing apples to oranges.
Clearly, because "DevOps" people / skills are for free right?
Good software engineers who additionally have exp with Cloud and all its craziness definitely aren't asking for way higher salaries?
I've worked in small size data center and the amount of work performed by 2x minimal wage technicians was huge.
They were running on 5-10 engineers + 3 more skilled ppl at day and 1 person on night shift with 1 or 2 being "wakeable"
Through the forcefield of a VP two levels above your boss who authorised it? Even if you know about it - which is a big "if" - you probably won't have either the authority or the practical means to shut it down.
It's become a classic problem. Organisations want to centralise infrastructure and services because consolidation saves on costs and increases visibility and control. Particularly if you're under specific regulations that can make things much easier.
But that only happens if the centralised provision actually works. It has to be adequately resourced and reasonably well managed and supportive of the people using the infrastructure or services it provides.
If the centralised provision is not good then it had one job and failed to do it. Whose fault it is doesn't really matter. It's not supporting the other parts of the organisation to do their jobs and inevitably a point will come where that infra gets "othered".
We've been seeing this phenomenon ever since we had central system administrators who could lock down the OS on individual employees' workstations. The admins argue that they need to make sure security updates are properly deployed and they need to prevent non-expert users from breaking things and they need to ensure consistency because they're also running the help desk and ultimately they're responsible for these things so they need the authority to control them. All very fair and reasonable. And all completely irrelevant to someone with actual revenue-generating work to do who is being blocked for days or weeks because some sysadmin whose opinions are not necessarily justified by their effectiveness hasn't enabled or authorised some essential facility.
I really hope you sold the devs on this instead of commanding them to use it, otherwise their director will use his credit card to sign up for their own AWS account.
Your absolute best way to make a programmer productive is to give domain experts the tools to build an executable prototype themselves. This was the true value of Hypercard, GW Basic, Visual Basic 6, Office/VBA, Excel, Delphi, etc.
They know what the actual details required for the inputs and outputs are, along with all the means to do the computations. Once they give you something that works (no matter how slow or kludgy), you have an executable specification to refactor, or rewrite, and you can A/B test to make sure your code works correctly compared to their reference/spec.
You spend some valuable time on the part of the experts, but you more than make up for it in saved time doing the wrong thing across possibly years.
No-code/low-code tools are great for prototypes, but are awful for software that is large enough. for small businesses many will not get to that point because many businesses sink by that time, but absolutely unusable for many enterprise software. Those solutions slow down devs past a certain level of complexity (and that level isn't all that high) but no-code/low-code experts will either not know any better or won't tell you. I have legitimately tried using a few, but they become a pain to work it beyond the initial prototype. I put them in the similar territory as Wordpress because they remind me of the pain of maintaining them.
Non-devs always underestimate complexity of software at scale. Even devs do as well. It's not gatekeeping otherwise, devs would already be out of a job
There’s one more thing, for me by far the most important: mental wellbeing.
In my case, having ADHD and going undiagnosed for decades (I only got diagnosed last December) has caused me to blame myself and my conscious actions for things directly caused by the neurochemistry of my brain. This year may have been my most productive ever.
I went through a similar experience this year. Finally got myself checked after I’ve been called “lazy” for so long, which immensely effected my self appointed value. I finally got my ADHD meds, and my productivity went through the roof. I tend to think what could’ve happened if I discovered my problem earlier, but Im happy that it at least wasn’t even later.
I think majority of software development productivity problems come down to communication. Either you both can say whats wrong or theres a weird little dance everytime something needs to be delivered.
Having a bunch of go-to guidelines is nice but really, you all just have to be on the same page whats the current state and to be able to say honestly whats going wrong when it happens.
Treating developers as monkeys who'll do as dictated doesnt really sit well for many of them.
I dispute "slow tools" being always as much of a problem as the article claims. From personal experience, having to wait for a build to finish sometimes makes me get up, and go make a tea or empty dishwasher / hang laundry out, as result feel refreshed and/or subconscious works on a problem. So often I go back to my chair with the solution having come seemingly from nowhere. Only because of the long build time did that happen. ;). A former colleague used to find excuses to have to walk from one office building to another to pick up a cable or something, in order to let his bring solve a problem rather than sit stewing in his chair. So... productivity is complicated. ;)
Can we discuss the fact that he forgot to mention that "having a good manager" makes people happy and productive? Because it's IMHO the most important thing that can make or break a good developer.
The whole article only mentions topics that developers can fix themselves, not stuff that we cannot change and are very important in the daily work.
given my current reality ~ an obscene company that marketed itself as super tech driven then it's just a bunch of operations people with a phone and a shared excel file that reject every effort to be automatized ~ the first and last list item hit very close to home as in what is sapping my energy.
it's incredibly discomforting to spend even 10 minutes building things the other party clearly doesn't want, but since everyone is a bloody "head" or "chief" of something, no one ever clearly defined upstream-downstream relations between teams. There is a lot of infighting and parleying over everything.
for the same reason, we switch gears mostly every 90 days, and most of the code has been written by some very junior programmers that never deleted any now unused feature and spaghettized everything (every 1-n relation has the fk on the wrong side lol). the PO is also a nice guy but absolutely incompetent at navigating this particular org, as suffers from the hero syndrome and wants to save the company.
the pay is decent (for where I live at least; it's a /10 from the "500k tc/1 yoy" reality of usa, and i have like 10 YoY, even if I worked in very modest places so not many big challenges), and i'm changing house in a couple of months. Thanks to idiotic local policies the furniture+building materials prices skyrocketed (literally 2-5x). This is literally the last bit of motivation I have and I'm counting the days until I can finally let go of those cretins, even if I have to stay a couple months without work.
To me it's not about management or whatever, it's about profit sharing.
If my productivity will eventually turn into profit that I can get by some bonus or rewards sharing, I will figure out so many ways to boost my productivity instead of waiting for a group of MBAs to figure out how to do the optimal KPI on me.
HR: What's your dream about your job here?
Me: My dream is to earn enough so I do not need work here(by the way, most likely that means the company will also be successful)
Even better would be a later stage startup (series C/D/E). Employee #1000 at Facebook, Square, Twitter (and many others) have probably done pretty well for themselves financially. Plus startup valuations are at multi-year lows right now.
One may be surprised to learn the dominant successful trait is being incredibly lazy, and finding the simplest minimal-effort solution that also requites minimal system-maintenance.
There are some people that are clearly into S&M, that proudly bring their kinks into project design.
This is extremely funny, because we all know this is actually true =)
Mark Twain is often quoted as saying, "I apologize for such a long letter - I didn't have time to write a short one."
In my experience, simple solutions are not the lazy minimal-effort ones. It takes a lot of work to distill complex problems down into simple solutions.
When I've seen this happen it usually boils down to communication problems. The solution is often to talk to the reviewers _before_ writing the PR.
For example,
1. Disagreement about the problem/solution - hash out the design first, then write the code
2. Disagreement about priorities - align expectations before investing too much time in design or code
3. (etc)
Yes, communication is hard. Unfortunately, it's really the only way to get things done with other people. Building decent communication skills is a worthwhile investment for all SWEs
Piggybacking this to say I will never be extremely productive when all my job boils down to is shifting code from one place to another, or building yet another braindead CRUD endpoint. My mind begins to wander and think about other things. I hear a lot of "we want to use our engineers in the best way possible" only to put people on mind-numbing zero-thinking framework guided work that doesnt capitalize on any of the traits of a good engineer. Before the frothing at the mouth business-minded people start saying "creative engineers are dangerous" I would suggest you actually go talk to your engineers. I doubt they say they want to greenfield a production idea in haskell. What they want is something that isn't the programming equivalent of a box ticking TPS report.
These are jobs where you want to be good enough to autopilot through the work quickly then fuck off and do whatever for the remaining 80% of the sprint. It's absolutely a dead end for anyone who wants to experience the 'craft' spirit of software.
If you're feeling particularly bold, you can hold two of these jobs and do something unheard of in recent times: actually being able to save for a decent retirement.
It's definitely not the endless hierarchy of interfaces, abstract classes and abstractions, etc. There is such a thing as cognitive overload and time spent to get to a goal. If I have to look at more than 3 files to know what is going on, maybe push it to 5. Then I know this project is a time sink. Let alone all the magicry to just get to Javascript in the browser. I miss the good old days. Where discipline was part of a developers mind and lazyness was not heralded as a panacea.
> it is advantageous to minimize how often ownership changes hands - no one will ever know more about a thing than the person who created it.
This may be true when looking at a single individual, but this is exactly how teams get locked into the bus factor of 1. The person who creates a codebase needs to train others on their knowledge, so the entire team has that understanding that allows them to be productive. The slowdown to train someone up to know as much as the creator is quickly paid off when 2 people know the codebase. And it scales more with each new person because not only do more people know it, but the knowledge transfer gets streamlined and the confusing parts of the app are identified and fixed.
I've begun to feel like we might put too much value in the "bus factor". Many companies have de-emphasized specialization in order to "spread knowledge and context". I think that's resulted in worse job satisfaction and developers who are spread too thin.
Not to say every person should have a silo-ed portion of the codebase that nobody else ever touches or understands. I just think the pendulum has swung too far in the other direction.
Not to say every person should have a silo-ed portion of the codebase that nobody else ever touches or understands. I just think the pendulum has swung too far in the other direction.
Yes. It's one of those mythical management "best practices" that never actually happens because it doesn't work.
Most interesting software development involves creative thinking. Unless someone finds a way to download the entire thought process of the original developers and losslessly transfer it to other developers later you can't recreate 100% of the knowledge and insights that came from the original development work.
What you can do is acknowledge that your developers are individuals with unique knowledge and abilities not just in general but because of their history within your own organisation. Value the unique experience they collect while working with you and - for as long as they remain with the organisation - encourage them to actively support colleagues who are later working in the same part of the code.
There is no substitute for retaining that knowledge and having the original source directly accessible but of course most people do move on eventually. So it's also a good idea to emphasise good design and coding and documentation practices so that even when the original developers move on and you'll never have access to the ideal source of knowledge again you still have enough to figure things out when you need to. The fallacy is the idea that working that way will ever be comparable in productivity to having the original source still around and willing to help.
So well put. I think one of the sources of burnout for many developers is the complete lack of acknowledgement of the creative aspect of programming in modern development processes.
I’m curious what others have experience here, as a code base grows.
I’ve been on several teams that consistently endeavor to keep the knowledge of a code base shared, but every time the code base reaches a certain size, the Bus Factor creeps right back in, but this time for “modules” or areas of the broader code base.
Combine a large code base, 4-8 engineers making constant changes all over, and it becomes a real struggle to keep everyone “up” on the whole thing.
Yep. I just got diagnosed recently. Still figuring out the right dose of the right meds, but in the meantime it has become painfully obvious that a lot of discussion around productivity and procrastination is happening without a lot of people realising they may simply have ADHD. There's a reason psychiatrists treat ADHD with medication first rather than trying to get you to follow productivity hacks or change your habits. Would have been good if ADHD was on my radar as a possibility much earlier.
The easiest way to be unproductive is to make something nobody wants. I've seen a lot of dev time spent on products where nobody bothered to validate their need at much less expense.
Instead of building tooling that reacts quickly, the approach I take is make it dead simple to build tools in the moment right into your documentation using markdown. If building the tool is little more than taking the command line you just ran and pasting it into the documentation, it’s fun to fix things and your teammates can instantly do what you did with a click. See it in action here: https://godspeed.run
As a former manager and current developers I say no thanks. Just stay out of the way, protect the team from outside BS, and focus on fixing what the team is annoyed about. Your team will love you for it.
somehow the (developer's) Fun is always left out of the functionality--time--price race.
All them things in the article - yes, but if it's no fun (even little) working all that, wontdo.
And the definition of fun can be elastic, but.. it has to be there.
This. Every manager should measure how much time it takes from pushing a commit to code review to CI to staging to production to feature flags enabling to rollback time.
Every single stage of this can be a flaky system, adding unnecessary toil on engineers. And your reports are not paid to fix all the toil.
Management should figure this out and bring it up to relevant teams to solve these issues before asking engineers to "do it faster"
Android developers would find this list depressing: huge SDK that never stabilises, Android Studio is the new Crysys, Gradle (and its scala dsl) is just confusing.
GNU Hyperbole for rapid, implicit linking of all your programming artifacts and management support for handling technical complexity. One of those you can get for free.
I used to work at a CMMI Level 5 (certified) shop. The process was inevitably tailored to the lowest common denominator. It was meh.
We used to say that the process will never turn a mediocre engineer into a good one but it will absolutely turn a good engineer into a mediocre one.
In general, I've observed that a lot of these heavyweight processes are used as a substitute for high quality engineering leadership. They are not a good substitute.
If you think that's productivity, wait until you have enough experience that you can do the vast majority of your work without stopping to rely on an outside system at all.
The small team should have a lot of support in terms of an infrastructure platform, strong culture and tooling for development/testing, project management set up for them, an escalation path and check-ins where they can raise blockers. There is a template but essentially the small team is left to work how they want to work.
After the 'chunk' is delivered, there is a week of wrap up, and then a week of maintenance where people are allowed to work on whatever they think is the most pressing issue.