When will programmers grow up? (2014)(web.archive.org)
web.archive.org
When will programmers grow up? (2014)
http://web.archive.org/web/20170226055627/http://articles.javatalks.ru/articles/35
28 comments
Most of the architectural wankery that happens in the real world does nothing to improve security or reliability of a project, though. People love to spend time discussing how to organize the code for potential future maintenance that then becomes irrelevant when requirements change, and didn't prevent someone from missing security vulnerabilities in an outdated version of a third party library anyway. So it's hard to compare that to pilots following a checklist or workers wearing helmets.
Imagine if pilots spent an hour debating which sequence to push a particular set of buttons that would be needed after takeoff - where either of several ways would work - to the point that the plane took off hours too late.
Imagine if pilots spent an hour debating which sequence to push a particular set of buttons that would be needed after takeoff - where either of several ways would work - to the point that the plane took off hours too late.
The pilots aren't inventing anything on each flight. If they fly the airplane exactly the same way every time, that's a good thing. Writing new programs is not like that.
>> The pilots aren't inventing anything on each flight. If they fly the airplane exactly the same way every time, that's a good thing. Writing new programs is not like that.
I have an intern writing and app for internal use. He's using Python, tkinter, and one pip-install package for talking on modbus. Deployment to our hand full of users is easy. Low number of dependencies. It's going really well. A few days ago he said "I really would have liked to use ZZYXX-web-whatever for the GUI instead of tkinter". I said "you users don't give a fuck about that but keeping dependencies easy to manage is important". Users don't actually care about dependencies either, but they do care when it negatively affects getting the thing up and running (or slows development or...). His main gripe with tkinter was actually a lack of familiarity. I said "dude, a large part of your job is going to be learning. Get used to it."
Many architectural decisions in software are completely arbitrary and don't matter nearly as much as some people think. That's not to say all such decisions, but really a lot are not a big deal. In those cases KISS trumps most preferences and big ideas. IMHO of course.
I have an intern writing and app for internal use. He's using Python, tkinter, and one pip-install package for talking on modbus. Deployment to our hand full of users is easy. Low number of dependencies. It's going really well. A few days ago he said "I really would have liked to use ZZYXX-web-whatever for the GUI instead of tkinter". I said "you users don't give a fuck about that but keeping dependencies easy to manage is important". Users don't actually care about dependencies either, but they do care when it negatively affects getting the thing up and running (or slows development or...). His main gripe with tkinter was actually a lack of familiarity. I said "dude, a large part of your job is going to be learning. Get used to it."
Many architectural decisions in software are completely arbitrary and don't matter nearly as much as some people think. That's not to say all such decisions, but really a lot are not a big deal. In those cases KISS trumps most preferences and big ideas. IMHO of course.
Just when I'd lost all hope for the future... Thank you!
> Imagine if pilots spent an hour debating which sequence to push a particular set of buttons that would be needed after takeoff - where either of several ways would work - to the point that the plane took off hours too late.
Thanks for this, this prompted me to submit an article I read yesterday. Pilots don't need the debate because the work is (for the most part) well-known. There is no debate because the aircraft has a method of working that is well-understood so long as you aren't in the field of flight testing new aircraft, which is to say: the vast majority of pilots. As a consequence, there is zero need for discussion because there is "one way" to do things, and where there are choices (actions that can be done in any order) there are often conventions (such as going left-to-right across a panel to reduce the risk of missing a step).
Software is different. Software is design, which pushes it towards the need to communicate more often and work in a collaborative fashion. In fact, a lack of communication seems to be the problem in the org of the article and not the desire for high quality software. The programmers weren't talking with each other or their customer and instead acted more like the pilot situation, but without sufficient insight to actually make decisions or take the actions they were taking.
Thanks for this, this prompted me to submit an article I read yesterday. Pilots don't need the debate because the work is (for the most part) well-known. There is no debate because the aircraft has a method of working that is well-understood so long as you aren't in the field of flight testing new aircraft, which is to say: the vast majority of pilots. As a consequence, there is zero need for discussion because there is "one way" to do things, and where there are choices (actions that can be done in any order) there are often conventions (such as going left-to-right across a panel to reduce the risk of missing a step).
Software is different. Software is design, which pushes it towards the need to communicate more often and work in a collaborative fashion. In fact, a lack of communication seems to be the problem in the org of the article and not the desire for high quality software. The programmers weren't talking with each other or their customer and instead acted more like the pilot situation, but without sufficient insight to actually make decisions or take the actions they were taking.
I wouldn't expect the pilots to spend an hour debating before every takeoff, but rather to have had that debate ahead of time and have a solid set of patterns that they follow so they don't have to reinvent the wheel each time.
The fact that attention to code doesn't prevent all problems doesn't mean that it doesn't prevent some problems.
The fact that attention to code doesn't prevent all problems doesn't mean that it doesn't prevent some problems.
Most programming tasks don't involve the life safety issues you are using as examples.
It is certainly true that overdesign up front can be fatal to the finances of a project. There is even a term for people who engage in this, "architecture astronauts"
The point is to know what you are working on, and what the customer needs. If they need one or two simple data stores and a couple of web pages, you don't need to spend weeks talking about it.
It is certainly true that overdesign up front can be fatal to the finances of a project. There is even a term for people who engage in this, "architecture astronauts"
The point is to know what you are working on, and what the customer needs. If they need one or two simple data stores and a couple of web pages, you don't need to spend weeks talking about it.
It's funny because the article starts with a series of factors that the author claims to reduce code quality, and then goes to conclude that the project suffers from excess of quality.
And then ends it claiming that quality is something that slows down development...
And then ends it claiming that quality is something that slows down development...
Electricity, building houses is based on hard science, code quality is base on opinion
RAM and CPU usage is not an opinion.
Of course it is. You can prioritize cpu or ram or disk or network or developer or user resoures for the sake of the others in countless mixes and for countless mixes of reasons.
Those guys had to have unions to fight for safety practices. It's to protect the workers. This code quality stuff is about various competing business objectives and now annoying stuff is.
I've never seen a programmer be dismembered from a missing test though I'm sure such things happen in embedded systems and robotics. Tesla Autopilot or the Uber self-driving accident in Arizona are great examples of programming leading to deaths.
I guess if your Uber app doesn't work in the rain that is bad. It's when people are making safety critical decisions that this stuff matters more.
I've never seen a programmer be dismembered from a missing test though I'm sure such things happen in embedded systems and robotics. Tesla Autopilot or the Uber self-driving accident in Arizona are great examples of programming leading to deaths.
I guess if your Uber app doesn't work in the rain that is bad. It's when people are making safety critical decisions that this stuff matters more.
[deleted]
My first boss once asked me in a performance review if I was a perfectionist. I was and told him so. He then explained something that left an impression on me: the value of shipping something that works even if it’s not elegant. I think there’s a happy medium between getting stuff done and getting stuff done ‘the right way.’
A lot of young engineers seem to miss the forest for the trees and this can be seen early in a project’s timeframe. Sometimes customers don’t help either because they lack the vision to know what they are really asking for as well. I know there’s a problem when people start suggesting solutions, elegant or otherwise, before the user requirements are fully fleshed out.
I work in an industry where CI/CD isn’t really a thing due to qualification/validation, so getting things perfect for re-using or servicing codebase is really inconsequential, but you’ll see people fall into the trap of ‘this has to be genericized 100% so we can use it everywhere.’ In reality nothing really gets re-used in such a way that it’s effective in reducing effort. I’m not saying it’s that way for everyone, but in my company’s pseudo programming space this is true.
A lot of young engineers seem to miss the forest for the trees and this can be seen early in a project’s timeframe. Sometimes customers don’t help either because they lack the vision to know what they are really asking for as well. I know there’s a problem when people start suggesting solutions, elegant or otherwise, before the user requirements are fully fleshed out.
I work in an industry where CI/CD isn’t really a thing due to qualification/validation, so getting things perfect for re-using or servicing codebase is really inconsequential, but you’ll see people fall into the trap of ‘this has to be genericized 100% so we can use it everywhere.’ In reality nothing really gets re-used in such a way that it’s effective in reducing effort. I’m not saying it’s that way for everyone, but in my company’s pseudo programming space this is true.
This. Clean and correct, but correct above all else.
A correct solution, even when not clean, isn't going to earn money. No one (except perhaps textbook publishers) will pay for a solution that is clean alone.
You can clean up a correct solution at a later date, all the while maintaining correctness; a clean (but incorrect) solution might need to be completely redesigned to make it correct.
I've come to accept that the best engineers are those who ship (you don't get to 10x productivity if you don't ever ship) and that often means being able to call the correct compromises to make. Heck, I'd even say engineering in general is finding a working compromise given a set of constraints.
A correct solution, even when not clean, isn't going to earn money. No one (except perhaps textbook publishers) will pay for a solution that is clean alone.
You can clean up a correct solution at a later date, all the while maintaining correctness; a clean (but incorrect) solution might need to be completely redesigned to make it correct.
I've come to accept that the best engineers are those who ship (you don't get to 10x productivity if you don't ever ship) and that often means being able to call the correct compromises to make. Heck, I'd even say engineering in general is finding a working compromise given a set of constraints.
> A correct solution, even when not clean, isn't going to earn money
Was that meant to be ‘is’?
Was that meant to be ‘is’?
> often means being able to call the correct compromises to make
The fact that you redefined “clean solution” as “correct compromises” doesn’t say much unfortunately.
The fact that you redefined “clean solution” as “correct compromises” doesn’t say much unfortunately.
I’m not sure I follow how you came to that conclusion. I think their point is, paraphrased, spaghetti code that meets the requirements, schedule and budget is better than pretty code that functions, but does not meet one or more of the aforementioned. That’s not to say that only spaghetti code can make a good project, but to illustrate the point.
Sure, sometimes everything works out where you can refine something to the point where it’s a golden (or near perfect) solution, but any solution that meets business requirement x is better than one that does not at all.
I’m not sure if it really comes down to this, but my standards for internal tools are much higher than things developed on the customer facing side. I think I mostly attribute that to the fact that we know how to successfully develop our user/business requirements versus our customers who do not. Hell, I have customers who have asked us to write their requirements. That’s a huge red flag for an unsuccessful solution.
Sure, sometimes everything works out where you can refine something to the point where it’s a golden (or near perfect) solution, but any solution that meets business requirement x is better than one that does not at all.
I’m not sure if it really comes down to this, but my standards for internal tools are much higher than things developed on the customer facing side. I think I mostly attribute that to the fact that we know how to successfully develop our user/business requirements versus our customers who do not. Hell, I have customers who have asked us to write their requirements. That’s a huge red flag for an unsuccessful solution.
I don't think the author has to divide writing good (quality) with being slow (speed), and writing fast with being bad.
I firmly believe that the goals is aligned on both sides. Client wants a feature "just works" by a certain date, and programmer wants to ship that very feature (without breaking anything else) on that certain date.
The impedance mismatch is that programmers see (code) quality as enabling higher velocity (work on new features without needing to maintain old ones) with the trade-off being the upfront cost. The client sees that the time it takes to deliver feature X as being proportional to delivering feature Y and Z.
The catch is that it is very hard to communicate that delivering feature Y and Z would be quicker (or not needed) if feature X was designed properly. This is because you can only approach this in hindsight (orthogonal thought: this is why upfront waterfall fell out compared to iterative agile).
The hard truth both sides don't want to admit is that the programmer does not know what they are building and the client does not know what they are asking.
Instead of the client wishing that the programmer had more domain experience and the programmer wishing the client had more technical experience, there should just be a stronger focus on empathy and letting things fail as part of the process.
I find it interesting that when things fail, client knows exactly what failed and programmer knows exactly why it failed. Must have something to do with hindsight :)
I firmly believe that the goals is aligned on both sides. Client wants a feature "just works" by a certain date, and programmer wants to ship that very feature (without breaking anything else) on that certain date.
The impedance mismatch is that programmers see (code) quality as enabling higher velocity (work on new features without needing to maintain old ones) with the trade-off being the upfront cost. The client sees that the time it takes to deliver feature X as being proportional to delivering feature Y and Z.
The catch is that it is very hard to communicate that delivering feature Y and Z would be quicker (or not needed) if feature X was designed properly. This is because you can only approach this in hindsight (orthogonal thought: this is why upfront waterfall fell out compared to iterative agile).
The hard truth both sides don't want to admit is that the programmer does not know what they are building and the client does not know what they are asking.
Instead of the client wishing that the programmer had more domain experience and the programmer wishing the client had more technical experience, there should just be a stronger focus on empathy and letting things fail as part of the process.
I find it interesting that when things fail, client knows exactly what failed and programmer knows exactly why it failed. Must have something to do with hindsight :)
Yes. I agree with this whole heartedly. It’s usually an issue with not understanding the other side’s perspective. Experienced/good engineers who know the space they are operating in can get a better sense of what the customer wants even when the customer may fail to adequately express their needs. It always helps when there’s people on both sides who have clear visions and a means to communicate those ideas with their counterparts.
"It appeared that last couple of weeks were spent for designing domain model and database scheme (wat?). And they were not there yet! I started to be involved in all this designing and I found that every team member suggested their vision of the model. And here comes the discussion.. That discussion was overwhelmed with buzz-words like “Best Practices”, “OOD”, “Performance” and in the end they chose the most complex scheme suggested."
So I'm waiting for the part where somebody demonstrates "good programming skills"...?
"I recall working for a small company where I was asked to write a tiny project to mix some videos, list them and show them to the users who can vote. The project had a budget for 2 months and I could’ve make it! But I was too blind because of good practices and maintainability. I introduced complex technologies, caching; of course I split the project into different layers and added a lot of extra interfaces for flexibility. Should I say I missed deadline? Surely I did."
Still not seeing it.
"Professionals don’t write code, they solve business tasks"
Ah, I see the problem. All of the above are examples of amateur programming. He's not talking about professional programming at all.
Step 1: Go read The Psychology of Computer Programming, by Gerald Weinberg. From 19-fucking-73.
Step 2: See Step 1.
(Actually, that's not quite fair. Best-practice-itis wasn't a thing back then. But the fascination with doing things right rather than doing the right thing is really the other side of the same coin.)
So I'm waiting for the part where somebody demonstrates "good programming skills"...?
"I recall working for a small company where I was asked to write a tiny project to mix some videos, list them and show them to the users who can vote. The project had a budget for 2 months and I could’ve make it! But I was too blind because of good practices and maintainability. I introduced complex technologies, caching; of course I split the project into different layers and added a lot of extra interfaces for flexibility. Should I say I missed deadline? Surely I did."
Still not seeing it.
"Professionals don’t write code, they solve business tasks"
Ah, I see the problem. All of the above are examples of amateur programming. He's not talking about professional programming at all.
Step 1: Go read The Psychology of Computer Programming, by Gerald Weinberg. From 19-fucking-73.
Step 2: See Step 1.
(Actually, that's not quite fair. Best-practice-itis wasn't a thing back then. But the fascination with doing things right rather than doing the right thing is really the other side of the same coin.)
Someday, the average programmer won't have less than five years of experience.
Maybe.
Probably not, since the ever-expanding demand for software shows no evidence of slowing, and the churn of people getting out doesn't seem liable to stop either.
Maybe.
Probably not, since the ever-expanding demand for software shows no evidence of slowing, and the churn of people getting out doesn't seem liable to stop either.
I think the author doesn't make the distinction between *knowing* practice XYZ and effectively applying XYZ. As with anything, when we discover something new, e.g. a hammer, everything looks like nails.
As a professional, I expect you to be able to argue both ways, to understand how much XYZ you need, or why XYZ has downsides and how it could hurt the company.
This is not just about best practices, but about anything: libraries, programming languages, clouds, DBs etc.
As a professional, I expect you to be able to argue both ways, to understand how much XYZ you need, or why XYZ has downsides and how it could hurt the company.
This is not just about best practices, but about anything: libraries, programming languages, clouds, DBs etc.
Make it work, then make it good.
Maybe I'm wrong, but that's what works for me. I don't get bogged down in arcane sideshows until much later, when it's an unimportant use of time. In the meantime, the software is working well and people can use it.
AFTERTHOUGHT: I've always denigrated Microsoft for doing exactly that: "Microsoft doesn't get it right till Version 3".
Seems I'm in 'good' company. <grin>
Maybe I'm wrong, but that's what works for me. I don't get bogged down in arcane sideshows until much later, when it's an unimportant use of time. In the meantime, the software is working well and people can use it.
AFTERTHOUGHT: I've always denigrated Microsoft for doing exactly that: "Microsoft doesn't get it right till Version 3".
Seems I'm in 'good' company. <grin>
There is a certain zealousness that comes with learning new things and looking for ways to apply them. Any programmer likes to do this regardless of experience or maturity, so it's a little inaccurate to say programmers need to grow up, although perhaps a reduction in zealotry would be good.
Often workplaces don't provide programmers, especially new programmers, the opportunity to flex their new skills as they are learned. It's rare for the business to be able to function as an incubator for programming talent when there are tickets to be closed. So, we can encourage ambitious learners explore in their free time, or we can decide for ourselves to take the subversive route and shoehorn our new skills into projects to satisfy our own desires. I am not so critical of the subversive route, it can be a great source of motivation and the business doesn't need to get everything it wants all the time, the programmer can take something for herself once in a while. In the absence of a genuine dialogue with management about helping the programmer grow, it may be quite justified to behave this way.
That said, there might be a better way that involves reducing the focus on "efficiency" that has "optimized" a lot of exploratory work out of existence. There are things like 20% time and such, but getting a programmer to focus 100% on their fresh ideas is difficult for just one day a week. The cost of context switching etc. After working in a variety of small companies that were able to leave time on the table for programmers to dabble in personal interests, I have become quite skeptical of large, rich companies that don't seem to have the ability to create slack in their processes. Too much management, too much over-optimization, too many meetings and sync-ups and arbitrary metrics and other nonsense have been foisted on the workplace by various snake oil salesmen who then clog the hierarchy and continually meddle in processes with vain attempts to justify their existence.
The solution isn't obvious, even the useless need jobs after all, but a lot of this frantic over-analysis is driven from the top. The need to constantly react to the market, respond to threats and opportunities, change directions 100+ times over the course of a year as leadership squabbles over who has the reins, everyone trying to build a name for themselves as quickly as possible no matter the collateral damage etc etc. The programmers aren't the only ones who need to grow up... If a workplace could manage to cultivate calm and focus from the top (easier when you aren't in the red, of course), we might be able to allow programmers the space they need to grow as individuals, while simultaneously making the most pragmatic technology decisions needed by the business.
Often workplaces don't provide programmers, especially new programmers, the opportunity to flex their new skills as they are learned. It's rare for the business to be able to function as an incubator for programming talent when there are tickets to be closed. So, we can encourage ambitious learners explore in their free time, or we can decide for ourselves to take the subversive route and shoehorn our new skills into projects to satisfy our own desires. I am not so critical of the subversive route, it can be a great source of motivation and the business doesn't need to get everything it wants all the time, the programmer can take something for herself once in a while. In the absence of a genuine dialogue with management about helping the programmer grow, it may be quite justified to behave this way.
That said, there might be a better way that involves reducing the focus on "efficiency" that has "optimized" a lot of exploratory work out of existence. There are things like 20% time and such, but getting a programmer to focus 100% on their fresh ideas is difficult for just one day a week. The cost of context switching etc. After working in a variety of small companies that were able to leave time on the table for programmers to dabble in personal interests, I have become quite skeptical of large, rich companies that don't seem to have the ability to create slack in their processes. Too much management, too much over-optimization, too many meetings and sync-ups and arbitrary metrics and other nonsense have been foisted on the workplace by various snake oil salesmen who then clog the hierarchy and continually meddle in processes with vain attempts to justify their existence.
The solution isn't obvious, even the useless need jobs after all, but a lot of this frantic over-analysis is driven from the top. The need to constantly react to the market, respond to threats and opportunities, change directions 100+ times over the course of a year as leadership squabbles over who has the reins, everyone trying to build a name for themselves as quickly as possible no matter the collateral damage etc etc. The programmers aren't the only ones who need to grow up... If a workplace could manage to cultivate calm and focus from the top (easier when you aren't in the red, of course), we might be able to allow programmers the space they need to grow as individuals, while simultaneously making the most pragmatic technology decisions needed by the business.
The team I was with last year would exercise new language/library features (C# was their bread and butter) on one section of the system. A kind of test refactoring/development to answer the questions: Is this useful for us, do we like it, and do we understand it well enough to refactor more of the system with it.
If the answer to any of those was no, they'd revert the test stuff but keep it in mind for the future (as they'd experienced it they could make a more informed decision later if it were relevant again). This let the developers get a bit more novelty in their otherwise dull (not in a bad sense, but not interesting) enterprise projects. It was also disciplined enough that if a feature was useful (did the job) but didn't aid in other ways (clarity, time to develop, etc.) then it was quickly dropped rather than letting someone run amok in the codebase.
Timewise this was 1-2 sprints for them, one to ramp up, the second to really exercise it. The customer wasn't losing much time (they still did other work during the sprints, they didn't halt things to do this it was one story among many) and potentially gained (if it turned out to be useful).
If the answer to any of those was no, they'd revert the test stuff but keep it in mind for the future (as they'd experienced it they could make a more informed decision later if it were relevant again). This let the developers get a bit more novelty in their otherwise dull (not in a bad sense, but not interesting) enterprise projects. It was also disciplined enough that if a feature was useful (did the job) but didn't aid in other ways (clarity, time to develop, etc.) then it was quickly dropped rather than letting someone run amok in the codebase.
Timewise this was 1-2 sprints for them, one to ramp up, the second to really exercise it. The customer wasn't losing much time (they still did other work during the sprints, they didn't halt things to do this it was one story among many) and potentially gained (if it turned out to be useful).
"I see electricians making sure they're properly grounded before working on high voltage electrical equipment rather than just making sure they don't touch the dangerous parts while they're working. When will they grow up?"
"I see pilots going through the same checklist they went through the last time they flew the plane even though they never find anything wrong. When will they grow up?"
"I see lifeguards wearing buoys on their feet rather than just swimming right to begin with. When will they grow up?"
Programming suffers from a lack of attention to quality not a lack of awareness that we "solve business problems".