21 ms·

Why Programming is Difficult (2014)

175 points by merlinsbrain 11y ago

mbrock 11y ago
In my experience, the overwhelmingly most difficult thing about programming is writing code that makes sense, even after it has gone through a couple rounds of requirements changes and bug fixes. Any concrete coding task can be dealt with straightforwardly enough, but projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. The idea of composability is a good approximation to what it means for a program to make sense. If any part of the program can be understood as a sensible composition of parts, then the program probably makes sense. But so many parts of real world code bases seem to end up incoherent. You look at a function and instead of seeing code that obviously, say, maps the render function over the list of widgets, you see three obscure conditionals, an apologetic comment, a bug tracker issue number, two boolean parameters named "force" and "dontRenderLast" (for some reason), and so on. This is why I think the ideas from "domain-driven design" are so important, including the notion of a ubiquitous domain vocabulary. Also the FP idea of denotational semantics. And that well-known benefit of unit test driven design. There's not enough recognition and clear understanding of this problem, in my opinion. We all know the problem, but somehow we don't talk about it enough, and don't acknowledge it as an enormous problem for development speed, programmer happiness, agility, and so on.
- turaw 11y ago
  Do you think that sort of a problem (incremental changes eroding an initially sound structure) could be fixed with better refactoring tools? It seems like the issue you're describing is that logic is leaking from some parts of the codebase to others, which might be fixable with sufficiently powerful refactorings.
  - Roboprog 11y ago
    Yes. But it's still a lot of work to identify what to click on in an overly complicated function / class and then to select "Transmogrification # 17" on it/them. Getting to a deeper understanding of what the old code is doing takes a lot of work. When we get to that point, refactoring to make what we learned apparent is a good idea. Assuming there is a way to test the changes. (Now I get to spend 2 days making "mocks" in environment X -- learning the mockup tool, and determining the content appropriate for the use cases) It's a good point you bring up, but it's not a freebie. I am in favor of doing what you said, when you can.
  - mbrock 11y ago
    Yeah, I think the sheer manual friction of moving things around is a big impediment to change. But also, I think there has to be some conceptual basis for us to be able to think about factoring in a clear way, and that kind of intellectual labor is hard on another level. Eric Evans' book on domain-driven design has some examples of programming tasks that generate confusing and unclear code, until the coder together with the "domain expert" reaches some kind of epiphany—like "ohh, if we think of these three things as being parts of the same kind of thing, then this part of the program makes more sense." A program is a kind of philosophical theory about a certain topic, and if the theory isn't very clear, then you'll end up with a lot of special cases and obscureness even if you have unit tests and refactoring tools. They say naming is the hardest thing in programming and that becomes more true when you start to introduce any level of abstraction. "Design patterns" were an attempt to create more general small theoretical pieces, above the syntactic level. In the FP world, a similar vision is that algebraic and categorical abstractions can provide some of those pieces. We still haven't seen much of what algebraic abstractions can do for ordinary programming... But these abstract pieces, I think, are pretty crucial if we want programs to be understandable as anything but arbitrary collections of procedures and types. So yes to refactoring tools, and yes to more discussion about design patterns—it didn't end with the Gang of Four! read Christopher Alexander and Richard P. Gabriel!—and yes to more inspiration from mathematics and engineering and philosophy and all kinds of stuff, to provide inspiration for factoring—yes to study of logic and language and ... I'm getting carried away.
    - amatic 11y ago
      Very smart comment. I've had a long brake from programming and all this functional and lisp stuff is new, and it is not always clear what is the benefit. But is great to see a diversity and experimentation.
      - johnmaguire2013 11y ago
        Lisp is actually the second oldest programming language (behind Fortran.) 1. https://en.wikipedia.org/wiki/Lisp_%28programming_language%29 https://en.wikipedia.org/wiki/Lisp_%28programming_language%2...
  - perlgeek 11y ago
    > Do you think that sort of a problem (incremental changes eroding an initially sound structure) could be fixed with better refactoring tools? Only if those refactoring tools could refactor the domain itself (and the environment), not just the code :-) Often these special cases aren't intrinsic to the code, but caused by inconsistent business rules, or weird issues with the environment (some browsers not sending some events, workarounds for compiler bugs on ancient platforms that must still be supported, socket closing might or might not cause a flush depending on whether you're on Windows or *nix, ...)
  - dasmoth 11y ago
    Possibly, but if so I suspect it'll be a big change from the tooling we've got at the moment. And there's always a risk that tooling which makes some changes (rename a method...) trivial will make substantive changes seem even harder (because, comparatively, they are). Somewhat the same arguments apply to approaches which put a lot of emphasis on small-scale/unit testing -- they offer reassurance when doing small-scale refactoring at the expense of making substantive refactoring harder.
  - Consultant32452 11y ago
    In my experience the only thing that prevents that phenomenon is unrelenting stubbornness from the development staff. It takes a tremendous amount of thought and care with each change to make sure it doesn't happen. Also in my experience, there is no "fixing" it once things have gone down hill. It's theoretically possible, but I've never personally seen it happen. Whereas I have seen fairly large code bases remain coherent after years of significant changes. That dev team was like a bunch of nazis as far as code quality was concerned. It was the best team I've ever worked with.
  - allengeorge 11y ago
    Only in the most trivial cases. Most systems I've worked on have some overriding architecture and assumptions. The worst quality erosions happen when changes are shoehorned into the code without a complete understanding of those factors: it's likely there'll be semantic mismatch between the new feature and existing components, unexpected bugs, and harder to modify code (because the overall architecture is no longer coherent). You can mitigate the disintegration by having a maintainer with a strong understanding of the architecture and the problem(s) being solved by the original system. Talking with them can give you a roadmap on how to modify it properly, and if it's even possible to do so while maintaining architectural and design coherence. Note: my comment is an opinion based on personal experience. I'm not trying to play it off as fact.
- heleph 11y ago
  I think it's difficult because no one particular change is a problem and in isolation they are mostly completely reasonable. It's the accumulation of these changes that cause the code to rot. There are a whole heap of "human nature" problems that are the same like getting into debt, being over weight, protecting the environment. The short term pay-off is fairly big, the contribution to the long term problem is very small. Also the person who is often responsible for making the decision may not be technical, so finds it difficult to imagine the eventual impact. Plus in the fast moving field of software development, they'll be unlikely to even be around when it happens.
- nickpeterson 11y ago
  One thing I really liked about the DDD idea of ubiquitous language was that you reduce the amount of artificial abstractions between domain experts and the code, and it forces developers to be able to converse better with the business. I also think we should be doing a much better job documenting the intent of an entire system. New features get added by working them into the narrative of the 'Document of Intent', rather than becoming some set of requirements in an issue tracker. Otherwise we have difficulty understanding 'why' a system works the way it does, and possibly, if that way is actually incorrect. Many companies I've worked at, the system 'becomes' the rule. Even domain experts will ask what the system currently does when pressed for how something should happen. I think at a certain scale, it's just hard to keep business process in a single person's head.
  - noir_lord 11y ago
    Something I've considered on and off is that our current way of writing code is insufficient, I'd really like to have an editor/IDE that had "layers" so that I could attach code related comments in one layer and intent/documentation in another layer - throw in the ability to hide/show layers at will and you'd have a much more flexible way of documenting code than we currently have.
    - sklogic 11y ago
      It was possible do it with literate programming for ages. Combine it with emacs, mmm-mode and, say, auctex - and you'll get your IDE.
      - rapind 11y ago
        I used litcoffee* for a while, and it really makes you think about and code for a future reader / maintainer, which is pretty great. It really slows you down though (good thing?) when trying to dump your ideas into code, especially if you end up writing exploratory code that you later delete (I do this a lot). I think literate code could be really great however for refactors. Once you've figured out the correct implementation and have the time & hopefully budget to revisit your fast code. Maybe it won't feel like the chore of straight up documentation, and more like the enjoyment of polishing your art. * http://coffeescript.org/#literate http://coffeescript.org/#literate
- davidjnelson 11y ago
  Totally agree. It seems like the driver is the tendency for businesses to think in the short term. It seems like building only the things that _really_ matter would be a solution. Then time would be more easily allocated to test driven design, composable architecture, state management, and data modeling. The question then becomes: "what truly matters to build". That's a whole other discussion.
- jacquesm 11y ago
  Complexity creep is something that should be fought tooth and nail where ever you find it. It's the biggest enemy of keeping your code maintainable. As soon as you feel that you're losing track of what is going on you need to step back and re-think your approach and re-factor. If you don't then in the long term you'll lose control completely. It's not a matter of 'if' but 'when' and by the time 'when' rolls around you will end up wishing you had taken care of the problem when it was still tractable. Short term thinking on long term projects is not an option.
  - jcoffland 11y ago
    This is absolutely correct. Maintaining control of your software means maintaining a good understanding of it which requires relentless refactoring. Refactoring without guilt. Too many programmers think they are wasting time when they refractor large parts of their program but this is always necessary.
- derefr 11y ago
  > Projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. Personally, I think this isn't inherent, but is just an effect of how all the current programming paradigms (procedural, functional, even logic) tend to compose features together by simply sticking more code into each node of the function graph. So code that was originally a single stream of simple definitions becomes a complex mess where each line could have come from a consideration a week ago or a decade ago, and you can't "follow the train of thought" that led to the current state any given function is in. I think we need to think very differently. A truly aspect-oriented programming language, like Inform7 but not limited to the domain of Interactive Fiction, could allow for "literate programming" that treats a codebase as a linear narrative of feature additions, rather than a mutable graph representing current behavior. You'd actually be able to read a codebase from "beginning to end" and get a sense of what thoughts went into constructing it, in order. Just reading git commit history won't get you there. Commits aren't the right granularity, for one thing—a log of merged PRs might work better. More importantly, git commits to a codebase are a mix of feature-commits and bug-fixing commits, which horribly muddies your vision of how each feature is defined. What you really want is for features to each be files, and bug-fixes to be commits to those files, such that you can read "the up-to-date edition" of each of the features. Do note that we already have this in one particular place. This is how database migrations work. We just need code migrations! :)
  - jschwartzi 11y ago
    Developing a linear narrative is a good part of why revision control systems and issue trackers exist. You use them to explain the evolution of the code base.
  - mbrock 11y ago
    I'd love to see some non-game software written in Inform 7. Like, a web framework. Seriously!
  - greenyoda 11y ago
    "that treats a codebase as a linear narrative of feature additions, rather than a mutable graph representing current behavior. You'd actually be able to read a codebase from "beginning to end" and get a sense of what thoughts went into constructing it, in order." That might be a good way of understanding the evolution of the system if you're already familiar with what the system does. But if you were a newly hired developer trying to understand the system from the ground up, wouldn't you want the features grouped together by logical function (systems and subsystems) rather than by their order of addition?
- JustSomeNobody 11y ago
  What I've seen kill code quality is a) management putting out fires and b) cocky programmers who boast they can do X in a few hours. Ok, sure, any of us can but why don't you take longer and properly refactor the code. Problem is, they've already opened their mouth so now management expects it in a few hours.
  - rorykoehler 11y ago
    Business people care about instant revenue generation therefore the fastest programmer is the highest value one in their eyes. Maintainability and technical debt is an abstract and far off cost through this lens. Agile methodology was developed in response to this but in my experience the move fast and break things mindset it brings usually translates into move fast, break things and then put the broken things onto a ever growing bug database where only the most critical bugs ever get fixed.
    - jcoffland 11y ago
      If you're afraid you're going to break things then you need to refractor. Fear that changes will break things is a sign of code fragility.
      - rorykoehler 11y ago
        I agree but there is little you can do about the code of your peers especially when they have seniority and you're not doing the code reviews. It's a cultural issue and I'm sure it's not like that everywhere but it is definitely prevalent. Everyone talks a good game about code quality but in practice moving fast is valued more by the money men.
    - deleted 11y ago
      [deleted]
    - golergka 11y ago
      You either have a very bad luck with "business people" or talking about a stereotype that is about as close to the truth as similar stereotypes about programmers are. Business people are very familiar with terms like "infrastructure", "extensibility", "maintenance" and the like. They're not idiots. May be you should try explaining why refactoring and good architecture is good in business terms instead of programming?
- deleted 11y ago
  [deleted]
  - invalidOrTaken 11y ago
    >structured programming visual, which is misguided. Can you expand on this? What is "structured programming"? Why is it misguided to make it visual? I am working on a tool that could be described as 2D functional programming, so these are not idle questions.
    - erichocean 11y ago
      Historically, structured programming was developed to eliminate the need for the GOTO statement and gave us the conventional control structures present in most PLs today: for-loops, while-loops, if-then-else statements, switch-case statements, etc. I think these structures are inappropriate in 2D because they assume a linear, 1D context for understanding.
      - invalidOrTaken 11y ago
        This seems worth remembering: >Structured programming gave us the conventional control structures present in most PLs: for-loops, while-loops, if-then-else statements, switch-case statements, etc. None of them are appropriate in 2D (but are very appropriate in a 1D program, usually written in text). Historically, structured programming was developed to enable the elimination of the GOTO statement. However I don't understand how conventional control structures are necessarily inappropriate for 2D. It seems to me that the 1D nature of text is used to map to execution point; even if that point jumps around a lot, it starts at the beginning, moves down by one line unless told otherwise, and ends at the bottom. In my tool, execution order is determined by dependencies, which is fine because there's no mutation (not by code anyway) so order doesn't really matter. So some constructs---`for`, `while` and `until` for instance---do become obsolete/meaningless. If and switch, however, remain very relevant. For that matter, switch draws its name from real-life switches in real-life machines, which run on ultra-concurrent physics. But we still find a use for them. Have I mis-stated or misunderstood you? As for the 2D similarity of 1D languages, that certainly sounds interesting. By "presenting them in 2D," do you mean something like Blockly? Blockly kind of leaves me cold because it seems like normal code, plus extreme syntax help. I mean, cool and stuff, but we can dream bigger, you know? Anyway, do you mean that imperative, functional, and concatenative all have the same basic made-from-text look when put into something like Blockly, or is there a deeper point I'm missing? Thanks a ton, btw. I'm always interested to hear what people think on this subject.
- hyperpallium 11y ago
  Also, just normal efficiency and error handling tend to obscure the basic idea of code. Keeping a commented-out copy of the original can document the basic idea. Or, it's epicycles within epicycles until a paradigm shift to a simpler theory. Though most real-world programming goals are not intrinsically simple, but a mish-mash of mess.
csydas 11y ago
I think the author nailed it on the head with the Workplace parts about why programming is difficult. The physical/socio-political environment that someone is in compounds the normal issues in the programming process and I've seen it drive quite a few programmers to straight up quit when the mountain of issues became insurmountable. Without the freedom to tinker and explore a bit, as the author bemoans, I think that it's when programming becomes a chore and At my last job, I think the only time that I had ever seen our programming team actually happy to work on a project was when by chance and via a minor mutiny, we were able to break them away from the minutia of constant maintenance and repair and let them actually just work on a project with no expected outcome. It was an alternative path for our identity management solution and the entire project was a challenge to the managers for the Enterprise team. Our programmers were down-right chipper at the prospect of just being able to flex their creativity and try something just to see if they could do it.
- Roboprog 11y ago
  I am thankful that at my current job, we do get some time to experiment here and there. Begin tangent: I work for a university doing grant projects for a few state and federal agencies, though. Some might like it, some might consider it hell for an entrepreneur. It works for me :-) We are in the process of re-writing our "flagship" app from 10+ year old java libraries. We were able to dodge the bullet of "upgrading" (???) from Struts to JSF. The new app is going to be a services based (REST + JSON) Java (mostly) back end, with an Angular based front end. We just did a demo of a subset of the new app at a trade show where a 3rd party app imports a partial record (via web service) into our app, then launches a nested browser window to run the rest of the relevant data entry. (the rest of the workflow will be handled by the legacy app until the complete new version is finished) No, I couldn't persuade my coworkers and supervisor to discard Java entirely and go with Node.js :-) I'm not entirely sure I would be comfortable with that, either. We are doing some server side Javascript lately, though, by using the Java scripting engine interface. We will likely soon be redoing another (30 or so year old) app from a sister university that the state uses, as well. Interesting times! For almost 5 years before this, I worked at a financial services company. I got paid a bit more (bonuses), but I spent all my time, really, keeping 2 legacy applications going without ever getting to spend much time REALLY updating some sore spots.
yasuo 11y ago
It is not difficult, trust me. I know C, C++ , Java and Phyton. It is all about logics and the only thing that differs is the syntax. Get in touch I might help you
- sklogic 11y ago
  Really? Just a syntax? No inherent complexities of the real world problems, no need to invent, evolve or imagine heuristics to cover the otherwise NP-complete problems? No painful semantic mismatch between the real world and available models? No issues with arbitrarily complex performance, latency and throughput constraints?
- MereInterest 11y ago
  Ah, I see that you stopped reading the article after the first paragraph, before getting to the section on "additional constraints".
- njharman 11y ago
  Too many guys like this are what makes software dev hard. Too many yahoos who think its just about code. Code is only an implementation detail of how most dev is done today. Even today, code isn't about the code. It's about explaining your program, your process, wtf you where thing when designed this thing to the next guy/gal. Sadly, what too much code tells us is "Design? That's what gui people do, right? I just kept typing stuff until it worked enough for non-technical person to think it was OK or we ran out of money/time."
  - dclowd9901 11y ago
    So much this. My cohorts and I aren't spending hours talking about why we should use es2015 or typescript or whatever else. We're spending hours nearly coming to blows over how to properly implement a Flux architecture.
  - its2complicated 11y ago
    Too many sentences like, "you where thing when designed this thing to the next guy/gal" make reading hard. Slow down dude, wtf?
WWKong 11y ago
The bigger question is, why are we still programming the way we did 20yrs ago? Higher level languages were a great improvement over machine language. But what comes next? Why don't we have it yet? A decade ago I was setting up database, writing queries, designing forms, writing the code to wire it all up. I still have to do all these steps with more amount of effort today.
- merlinsbrain 11y ago
  I think Backend-as-a-Service providers are a good step towards a place we want to be, although I still think we're not super close to using such services to deploy complex business logic on. Services like parse cloud code and AWS lambda are another step closer. Context: We (me + couple of collaborators) are writing a similar platform for ourselves, although the purpose is dogfood more than $.
  - xyzzy4 11y ago
    Parse is shutting down though.
    - merlinsbrain 11y ago
      While I view them as pioneers in the space, the fact that executed their cloud code functionality, and did it well is enough for the rest of us to take it from here :) Perhaps it's even a part of the (now) open source parse-server? I am not sure, but as I am building a similar thing I will definitely be having a closer look at their source code in the coming weeks.
  - davidjnelson 11y ago
    Aws lambda does look like a particularly large innovation regarding complexity management. Anyone have stories on using it to share?
    - room271 11y ago
      Nothing amazingly innovative, but I've used it a lot at work. For simple jobs/event processing it is amazing as it removes a load of complexity (logging, monitoring, scaling, deploying). Lambdas tend to be < 100 lines of Javascript which means maintenance and rewriting is trivial. And because the jobs are so simple people don't need to be Javascript experts or aware of the JS ecosystem to write them. Lambda is also very cheap if you have bursty or just very low-volume workloads.
FreedomToCreate 11y ago
The most important line from the author is "it takes time to be a good programmer". Those nights of debugging and reimplementing will decrease as you better understand how to develop code. Also I find open concept offices terrible to work in. I'm not the type of person who can put on a pair of headphones, blast music and pump out code. I like solitude as I think though the problem and code. Unfortunately for me, the open concept is here to stay it seems.
- merlinsbrain 11y ago
  I love that line as well. I just told a friend of mine that if I spend the next 10years writing 3 languages exclusively (one per domain of systems, web/mobile application and high concurrency distributed systems) I would hopefully probably be a "good programmer" as I envision it. That might be a tall statement, but that's just my interpretation of how it takes time to become a good programmer, YMMV.
njharman 11y ago
>code that produced it should be cleaned up and documented before the next project was started. A major why waiting to the end to test document and clean up code is a failure. Write beautiful, tested code from the start. Even throwaway code, because half time prototypes, etc end up production.
- lifeisstillgood 11y ago
  See the middle part "there is not enough time to do it right first time"
  - mbrock 11y ago
    And even if there happens to be, check back in six months and see what's happened. Did your beautiful design smoothly accommodate the fix for the tricky issue #5388? Was there enough time then to update your clear documentation, or does the documentation now clearly explain something false? Did the new coworker who implemented that new feature understand the point of your design such that she was able to extend it properly while you were busy for three weeks chasing a deadlock? And so on. Beauty always fades!
    - lifeisstillgood 11y ago
      Agreed
    - davidjnelson 11y ago
      Yup. Unit tests, clean code built via tdd, auto generated docs from interfaces, high level architecture diagrams and explanations on a wiki, instructions on getting your machine / environment set up on a wiki, and api contracts on a wiki are the best documentation from my experience.
- seivan 11y ago
  You're assuming programmers get the time they need to set up the test environment. Try out a few different libraries to make things easier for testing. Manage quirks and bugs within the tests themselves or test runners and etc. From my PoV that's rarely something we get to allocate time for. The sales people sell "continuous integration" and "tests". But it doesn't mean that we're allowed to allocate time for that.
sjclemmy 11y ago
> Sleep. A lot of programming problems get solved while you sleep. I love it when I go to bed mulling over a problem, and when I get up I have the solution. The brain is truly a wondrous machine!
ksk 11y ago
I don't think programming - in the sense of what 99% of programmers do - is as difficult as programmers love to blog about. Most professional programmers write stuff that is not all that hard, and most of it has been done by others countless number of times. All the "hard" cutting edge stuff is done by a tiny tiny fraction of programmers. Heck even the things people think are cutting edge now, just taking a random example - VR, have been explored decades ago. Seriously, go read some SigGraph papers. However, programmers more than other professionals love blogging about their work, which is great - because it helps spread ideas (more so than any other field I've seen), but also creates this illusion that programming is this super hard thing. I mean people complain about going to interviews and being asked about algorithms and stuff that you could "just google" when, if you were to ask an average scientist, the amount of active working knowledge they have at any given time is simply astounding.
- kris-s 11y ago
  My pet theory is that even relatively simple programming problems drain a very limited daily resource of programming time (something on the order of 2-4 hours of real work per day). Because a programmer can be drained of programming ability so quickly we just compensate by blogging, posting, talking about it incessantly as a backfill.
- mei0Iesh 11y ago
  There used to be a difference between scripters and programmers. I'm a scripter, and it feels similar to learning a natural language and writing essays in it. In other words, it's easy and doesn't require any mathematical skill. There are low-level programmers who do things similar to other sciences involving math, and my brain wouldn't be able to do that. So if you're talking about scripting, which I think most people do, then I agree it isn't difficult.
  - sklogic 11y ago
    Not sure what do you mean by "scripting", but there is an awful lot of complexity on any level, all the way up. Mathematics and algorithms aside, there are vague requirements and tight deadlines. There is a need to estimate how long will it take (know of anything else harder than this?). There are maintenance considerations which complicate everything, even a one-line script: documenting, packaging, future-proofing against platform updates, etc.
njharman 11y ago
I believe author means things like code, build system, etc when they say "inputs are beautiful". Cause In my experience one of the major inhibitors of beautiful code, what takes many tests, and what makes dev hard is how fucked up input is. Esp user, as in interactive human, input.
dclowd9901 11y ago
If David Sedaris was a software developer...
xdc55 11y ago
It is much easier to prove a particular program function correct when complexity is properly handled, this is the true art of programming, handling complexity in a way that makes sense. Many complex phenomena in nature is explained by very simple mathematical equations, likewise great engineering design is achieved when there is nothing else to remove, and in order to achieve those results, a great deal of effort and thinking has to happen first. The thing is, as the author put out, the environment is just too hostile in order to design beautiful programs, from the insane expectations of what can be done, to incompetent peers, politics, distractions and what not. If you are skilled, you can define a problem in a precise way, be able to dissect it in smaller problems, solve them and prove the solution correct. What is ultimately hard is how to handle the hostile environment you're usually stuck with.
ScottBurson 11y ago
Programming is difficult because it is easy. Here is what I mean. Implementing new functionality where nothing existed before is easy: just figure out what you want the machine to do, and tell it to do that. It isn't trivial, but on a relative scale, it's easy. Precisely because it's easy to create functionality, we do a lot of it. Our programs grow. As they grow, they get complicated. As they get complicated, it gets to be more and more difficult to understand what they're already doing so that we can make them do something different. So, the less tongue-in-cheek version of my thesis here is that programming gets to be difficult because it starts out being easy. This is why I always say that the essence of software engineering is the management of complexity. And this is the part that people who have not actually worked on large programs will probably never understand. (As someone once said to me, "what you need to get is that management views programming as primarily a clerical function".) Viewed one-by-one, the tasks seem simple. And yet, somehow, when you put them all together, they're not simple anymore.
- engi_nerd 11y ago
  > This is why I always say that the essence of software engineering is the management of complexity. Your point is valid, and you can delete the word "software" and make a more general point that is also true.
- imtringued 11y ago
  When things are easy expectations rise until they reach a point where things become hard again.
shockzzz 11y ago
Now I find no particular joy in implementing archaic and perverse protocols but often the quickest way to progress is to re-implement them from scratch. whaaaa
meesles 11y ago
I see these posts every so often: "X is hard". Aside from just illuminating the X, I don't really see the point of the posts. Most higher-order jobs are difficult, that's why people train and educate themselves to work in the field. Coding has it's own set of challenges, but I don't think anyone is saying coding something slightly complex is easy. Just like how designing a building is hard, or swimming an olympic time is hard, or solving a complex science equation is hard. If I'm being honest, these posts come off a little whiny.
namnam88 11y ago
All good points, but this is not just specific to programming IMO. I work as a sales engineer for a networking company and I face the same issues as you when I work with customers who use our products. Documentation is never good, you're always solving customer problems so you never really have time to dig deep (read 391 page manuals are out of the question), new features are not described correctly and when I try to lab things up (demo or otherwise) there are about 100 things that can go wrong (I made up that number but you get the idea). Great article though- I think it applies to most technical roles.
jcoffland 11y ago
The author and a number of commentors seem to be saying that incremental changes eventually lead to tangled and unmaintainable code. My litmus test for the quality of a code change is the amount of code it allows me to remove. If a change results in many other parts of the code collapsing or getting simpler then I know I've made a good decision.
aryehof 11y ago
I think for those programming complex systems in business and industry, the biggest problem remains how to represent concepts in code. Even the simplest problem, like a Purchaser placing a Purchase Order for a Product from a Supplier can't be easily modeled and programmed by the majority of software developers - with any sort of predictability based on prior art or their own experience. At best, we approach a problem with a combination of modular procedural code (modularity via subroutines)(from the 1950's) and structured programming with functional decomposition (from the 1960's). There is no shortage of technical prowess, but a warehouse system is not based on design patterns, libraries, frameworks, or technologies. Instead, it is based on people, places, things and transactions interacting together to solve a problem. How to represent real-world concepts and systems (real or abstract) into code, remains the challenge it always has been. We just don't seem to learn any lessons from the past.

175 points by merlinsbrain 11y ago

In my experience, the overwhelmingly most difficult thing about programming is writing code that makes sense, even after it has gone through a couple rounds of requirements changes and bug fixes. Any concrete coding task can be dealt with straightforwardly enough, but projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. The idea of composability is a good approximation to what it means for a program to make sense. If any part of the program can be understood as a sensible composition of parts, then the program probably makes sense. But so many parts of real world code bases seem to end up incoherent. You look at a function and instead of seeing code that obviously, say, maps the render function over the list of widgets, you see three obscure conditionals, an apologetic comment, a bug tracker issue number, two boolean parameters named "force" and "dontRenderLast" (for some reason), and so on. This is why I think the ideas from "domain-driven design" are so important, including the notion of a ubiquitous domain vocabulary. Also the FP idea of denotational semantics. And that well-known benefit of unit test driven design. There's not enough recognition and clear understanding of this problem, in my opinion. We all know the problem, but somehow we don't talk about it enough, and don't acknowledge it as an enormous problem for development speed, programmer happiness, agility, and so on.

turaw 11y ago
Do you think that sort of a problem (incremental changes eroding an initially sound structure) could be fixed with better refactoring tools? It seems like the issue you're describing is that logic is leaking from some parts of the codebase to others, which might be fixable with sufficiently powerful refactorings.
- Roboprog 11y ago
  Yes. But it's still a lot of work to identify what to click on in an overly complicated function / class and then to select "Transmogrification # 17" on it/them. Getting to a deeper understanding of what the old code is doing takes a lot of work. When we get to that point, refactoring to make what we learned apparent is a good idea. Assuming there is a way to test the changes. (Now I get to spend 2 days making "mocks" in environment X -- learning the mockup tool, and determining the content appropriate for the use cases) It's a good point you bring up, but it's not a freebie. I am in favor of doing what you said, when you can.
- mbrock 11y ago
  Yeah, I think the sheer manual friction of moving things around is a big impediment to change. But also, I think there has to be some conceptual basis for us to be able to think about factoring in a clear way, and that kind of intellectual labor is hard on another level. Eric Evans' book on domain-driven design has some examples of programming tasks that generate confusing and unclear code, until the coder together with the "domain expert" reaches some kind of epiphany—like "ohh, if we think of these three things as being parts of the same kind of thing, then this part of the program makes more sense." A program is a kind of philosophical theory about a certain topic, and if the theory isn't very clear, then you'll end up with a lot of special cases and obscureness even if you have unit tests and refactoring tools. They say naming is the hardest thing in programming and that becomes more true when you start to introduce any level of abstraction. "Design patterns" were an attempt to create more general small theoretical pieces, above the syntactic level. In the FP world, a similar vision is that algebraic and categorical abstractions can provide some of those pieces. We still haven't seen much of what algebraic abstractions can do for ordinary programming... But these abstract pieces, I think, are pretty crucial if we want programs to be understandable as anything but arbitrary collections of procedures and types. So yes to refactoring tools, and yes to more discussion about design patterns—it didn't end with the Gang of Four! read Christopher Alexander and Richard P. Gabriel!—and yes to more inspiration from mathematics and engineering and philosophy and all kinds of stuff, to provide inspiration for factoring—yes to study of logic and language and ... I'm getting carried away.
  - amatic 11y ago
    Very smart comment. I've had a long brake from programming and all this functional and lisp stuff is new, and it is not always clear what is the benefit. But is great to see a diversity and experimentation.
    - johnmaguire2013 11y ago
      Lisp is actually the second oldest programming language (behind Fortran.) 1. https://en.wikipedia.org/wiki/Lisp_%28programming_language%29 https://en.wikipedia.org/wiki/Lisp_%28programming_language%2...
- perlgeek 11y ago
  > Do you think that sort of a problem (incremental changes eroding an initially sound structure) could be fixed with better refactoring tools? Only if those refactoring tools could refactor the domain itself (and the environment), not just the code :-) Often these special cases aren't intrinsic to the code, but caused by inconsistent business rules, or weird issues with the environment (some browsers not sending some events, workarounds for compiler bugs on ancient platforms that must still be supported, socket closing might or might not cause a flush depending on whether you're on Windows or *nix, ...)
- dasmoth 11y ago
  Possibly, but if so I suspect it'll be a big change from the tooling we've got at the moment. And there's always a risk that tooling which makes some changes (rename a method...) trivial will make substantive changes seem even harder (because, comparatively, they are). Somewhat the same arguments apply to approaches which put a lot of emphasis on small-scale/unit testing -- they offer reassurance when doing small-scale refactoring at the expense of making substantive refactoring harder.
- Consultant32452 11y ago
  In my experience the only thing that prevents that phenomenon is unrelenting stubbornness from the development staff. It takes a tremendous amount of thought and care with each change to make sure it doesn't happen. Also in my experience, there is no "fixing" it once things have gone down hill. It's theoretically possible, but I've never personally seen it happen. Whereas I have seen fairly large code bases remain coherent after years of significant changes. That dev team was like a bunch of nazis as far as code quality was concerned. It was the best team I've ever worked with.
- allengeorge 11y ago
  Only in the most trivial cases. Most systems I've worked on have some overriding architecture and assumptions. The worst quality erosions happen when changes are shoehorned into the code without a complete understanding of those factors: it's likely there'll be semantic mismatch between the new feature and existing components, unexpected bugs, and harder to modify code (because the overall architecture is no longer coherent). You can mitigate the disintegration by having a maintainer with a strong understanding of the architecture and the problem(s) being solved by the original system. Talking with them can give you a roadmap on how to modify it properly, and if it's even possible to do so while maintaining architectural and design coherence. Note: my comment is an opinion based on personal experience. I'm not trying to play it off as fact.
heleph 11y ago
I think it's difficult because no one particular change is a problem and in isolation they are mostly completely reasonable. It's the accumulation of these changes that cause the code to rot. There are a whole heap of "human nature" problems that are the same like getting into debt, being over weight, protecting the environment. The short term pay-off is fairly big, the contribution to the long term problem is very small. Also the person who is often responsible for making the decision may not be technical, so finds it difficult to imagine the eventual impact. Plus in the fast moving field of software development, they'll be unlikely to even be around when it happens.
nickpeterson 11y ago
One thing I really liked about the DDD idea of ubiquitous language was that you reduce the amount of artificial abstractions between domain experts and the code, and it forces developers to be able to converse better with the business. I also think we should be doing a much better job documenting the intent of an entire system. New features get added by working them into the narrative of the 'Document of Intent', rather than becoming some set of requirements in an issue tracker. Otherwise we have difficulty understanding 'why' a system works the way it does, and possibly, if that way is actually incorrect. Many companies I've worked at, the system 'becomes' the rule. Even domain experts will ask what the system currently does when pressed for how something should happen. I think at a certain scale, it's just hard to keep business process in a single person's head.
- noir_lord 11y ago
  Something I've considered on and off is that our current way of writing code is insufficient, I'd really like to have an editor/IDE that had "layers" so that I could attach code related comments in one layer and intent/documentation in another layer - throw in the ability to hide/show layers at will and you'd have a much more flexible way of documenting code than we currently have.
  - sklogic 11y ago
    It was possible do it with literate programming for ages. Combine it with emacs, mmm-mode and, say, auctex - and you'll get your IDE.
    - rapind 11y ago
      I used litcoffee* for a while, and it really makes you think about and code for a future reader / maintainer, which is pretty great. It really slows you down though (good thing?) when trying to dump your ideas into code, especially if you end up writing exploratory code that you later delete (I do this a lot). I think literate code could be really great however for refactors. Once you've figured out the correct implementation and have the time & hopefully budget to revisit your fast code. Maybe it won't feel like the chore of straight up documentation, and more like the enjoyment of polishing your art. * http://coffeescript.org/#literate http://coffeescript.org/#literate
davidjnelson 11y ago
Totally agree. It seems like the driver is the tendency for businesses to think in the short term. It seems like building only the things that _really_ matter would be a solution. Then time would be more easily allocated to test driven design, composable architecture, state management, and data modeling. The question then becomes: "what truly matters to build". That's a whole other discussion.
jacquesm 11y ago
Complexity creep is something that should be fought tooth and nail where ever you find it. It's the biggest enemy of keeping your code maintainable. As soon as you feel that you're losing track of what is going on you need to step back and re-think your approach and re-factor. If you don't then in the long term you'll lose control completely. It's not a matter of 'if' but 'when' and by the time 'when' rolls around you will end up wishing you had taken care of the problem when it was still tractable. Short term thinking on long term projects is not an option.
- jcoffland 11y ago
  This is absolutely correct. Maintaining control of your software means maintaining a good understanding of it which requires relentless refactoring. Refactoring without guilt. Too many programmers think they are wasting time when they refractor large parts of their program but this is always necessary.
derefr 11y ago
> Projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. Personally, I think this isn't inherent, but is just an effect of how all the current programming paradigms (procedural, functional, even logic) tend to compose features together by simply sticking more code into each node of the function graph. So code that was originally a single stream of simple definitions becomes a complex mess where each line could have come from a consideration a week ago or a decade ago, and you can't "follow the train of thought" that led to the current state any given function is in. I think we need to think very differently. A truly aspect-oriented programming language, like Inform7 but not limited to the domain of Interactive Fiction, could allow for "literate programming" that treats a codebase as a linear narrative of feature additions, rather than a mutable graph representing current behavior. You'd actually be able to read a codebase from "beginning to end" and get a sense of what thoughts went into constructing it, in order. Just reading git commit history won't get you there. Commits aren't the right granularity, for one thing—a log of merged PRs might work better. More importantly, git commits to a codebase are a mix of feature-commits and bug-fixing commits, which horribly muddies your vision of how each feature is defined. What you really want is for features to each be files, and bug-fixes to be commits to those files, such that you can read "the up-to-date edition" of each of the features. Do note that we already have this in one particular place. This is how database migrations work. We just need code migrations! :)
- jschwartzi 11y ago
  Developing a linear narrative is a good part of why revision control systems and issue trackers exist. You use them to explain the evolution of the code base.
- mbrock 11y ago
  I'd love to see some non-game software written in Inform 7. Like, a web framework. Seriously!
- greenyoda 11y ago
  "that treats a codebase as a linear narrative of feature additions, rather than a mutable graph representing current behavior. You'd actually be able to read a codebase from "beginning to end" and get a sense of what thoughts went into constructing it, in order." That might be a good way of understanding the evolution of the system if you're already familiar with what the system does. But if you were a newly hired developer trying to understand the system from the ground up, wouldn't you want the features grouped together by logical function (systems and subsystems) rather than by their order of addition?
JustSomeNobody 11y ago
What I've seen kill code quality is a) management putting out fires and b) cocky programmers who boast they can do X in a few hours. Ok, sure, any of us can but why don't you take longer and properly refactor the code. Problem is, they've already opened their mouth so now management expects it in a few hours.
- rorykoehler 11y ago
  Business people care about instant revenue generation therefore the fastest programmer is the highest value one in their eyes. Maintainability and technical debt is an abstract and far off cost through this lens. Agile methodology was developed in response to this but in my experience the move fast and break things mindset it brings usually translates into move fast, break things and then put the broken things onto a ever growing bug database where only the most critical bugs ever get fixed.
  - jcoffland 11y ago
    If you're afraid you're going to break things then you need to refractor. Fear that changes will break things is a sign of code fragility.
    - rorykoehler 11y ago
      I agree but there is little you can do about the code of your peers especially when they have seniority and you're not doing the code reviews. It's a cultural issue and I'm sure it's not like that everywhere but it is definitely prevalent. Everyone talks a good game about code quality but in practice moving fast is valued more by the money men.
  - deleted 11y ago
    [deleted]
  - golergka 11y ago
    You either have a very bad luck with "business people" or talking about a stereotype that is about as close to the truth as similar stereotypes about programmers are. Business people are very familiar with terms like "infrastructure", "extensibility", "maintenance" and the like. They're not idiots. May be you should try explaining why refactoring and good architecture is good in business terms instead of programming?
deleted 11y ago
[deleted]
- invalidOrTaken 11y ago
  >structured programming visual, which is misguided. Can you expand on this? What is "structured programming"? Why is it misguided to make it visual? I am working on a tool that could be described as 2D functional programming, so these are not idle questions.
  - erichocean 11y ago
    Historically, structured programming was developed to eliminate the need for the GOTO statement and gave us the conventional control structures present in most PLs today: for-loops, while-loops, if-then-else statements, switch-case statements, etc. I think these structures are inappropriate in 2D because they assume a linear, 1D context for understanding.
    - invalidOrTaken 11y ago
      This seems worth remembering: >Structured programming gave us the conventional control structures present in most PLs: for-loops, while-loops, if-then-else statements, switch-case statements, etc. None of them are appropriate in 2D (but are very appropriate in a 1D program, usually written in text). Historically, structured programming was developed to enable the elimination of the GOTO statement. However I don't understand how conventional control structures are necessarily inappropriate for 2D. It seems to me that the 1D nature of text is used to map to execution point; even if that point jumps around a lot, it starts at the beginning, moves down by one line unless told otherwise, and ends at the bottom. In my tool, execution order is determined by dependencies, which is fine because there's no mutation (not by code anyway) so order doesn't really matter. So some constructs---`for`, `while` and `until` for instance---do become obsolete/meaningless. If and switch, however, remain very relevant. For that matter, switch draws its name from real-life switches in real-life machines, which run on ultra-concurrent physics. But we still find a use for them. Have I mis-stated or misunderstood you? As for the 2D similarity of 1D languages, that certainly sounds interesting. By "presenting them in 2D," do you mean something like Blockly? Blockly kind of leaves me cold because it seems like normal code, plus extreme syntax help. I mean, cool and stuff, but we can dream bigger, you know? Anyway, do you mean that imperative, functional, and concatenative all have the same basic made-from-text look when put into something like Blockly, or is there a deeper point I'm missing? Thanks a ton, btw. I'm always interested to hear what people think on this subject.
hyperpallium 11y ago
Also, just normal efficiency and error handling tend to obscure the basic idea of code. Keeping a commented-out copy of the original can document the basic idea. Or, it's epicycles within epicycles until a paradigm shift to a simpler theory. Though most real-world programming goals are not intrinsically simple, but a mish-mash of mess.

csydas 11y ago

I think the author nailed it on the head with the Workplace parts about why programming is difficult. The physical/socio-political environment that someone is in compounds the normal issues in the programming process and I've seen it drive quite a few programmers to straight up quit when the mountain of issues became insurmountable. Without the freedom to tinker and explore a bit, as the author bemoans, I think that it's when programming becomes a chore and At my last job, I think the only time that I had ever seen our programming team actually happy to work on a project was when by chance and via a minor mutiny, we were able to break them away from the minutia of constant maintenance and repair and let them actually just work on a project with no expected outcome. It was an alternative path for our identity management solution and the entire project was a challenge to the managers for the Enterprise team. Our programmers were down-right chipper at the prospect of just being able to flex their creativity and try something just to see if they could do it.

Roboprog 11y ago
I am thankful that at my current job, we do get some time to experiment here and there. Begin tangent: I work for a university doing grant projects for a few state and federal agencies, though. Some might like it, some might consider it hell for an entrepreneur. It works for me :-) We are in the process of re-writing our "flagship" app from 10+ year old java libraries. We were able to dodge the bullet of "upgrading" (???) from Struts to JSF. The new app is going to be a services based (REST + JSON) Java (mostly) back end, with an Angular based front end. We just did a demo of a subset of the new app at a trade show where a 3rd party app imports a partial record (via web service) into our app, then launches a nested browser window to run the rest of the relevant data entry. (the rest of the workflow will be handled by the legacy app until the complete new version is finished) No, I couldn't persuade my coworkers and supervisor to discard Java entirely and go with Node.js :-) I'm not entirely sure I would be comfortable with that, either. We are doing some server side Javascript lately, though, by using the Java scripting engine interface. We will likely soon be redoing another (30 or so year old) app from a sister university that the state uses, as well. Interesting times! For almost 5 years before this, I worked at a financial services company. I got paid a bit more (bonuses), but I spent all my time, really, keeping 2 legacy applications going without ever getting to spend much time REALLY updating some sore spots.

yasuo 11y ago

It is not difficult, trust me. I know C, C++ , Java and Phyton. It is all about logics and the only thing that differs is the syntax. Get in touch I might help you

sklogic 11y ago
Really? Just a syntax? No inherent complexities of the real world problems, no need to invent, evolve or imagine heuristics to cover the otherwise NP-complete problems? No painful semantic mismatch between the real world and available models? No issues with arbitrarily complex performance, latency and throughput constraints?
MereInterest 11y ago
Ah, I see that you stopped reading the article after the first paragraph, before getting to the section on "additional constraints".
njharman 11y ago
Too many guys like this are what makes software dev hard. Too many yahoos who think its just about code. Code is only an implementation detail of how most dev is done today. Even today, code isn't about the code. It's about explaining your program, your process, wtf you where thing when designed this thing to the next guy/gal. Sadly, what too much code tells us is "Design? That's what gui people do, right? I just kept typing stuff until it worked enough for non-technical person to think it was OK or we ran out of money/time."
- dclowd9901 11y ago
  So much this. My cohorts and I aren't spending hours talking about why we should use es2015 or typescript or whatever else. We're spending hours nearly coming to blows over how to properly implement a Flux architecture.
- its2complicated 11y ago
  Too many sentences like, "you where thing when designed this thing to the next guy/gal" make reading hard. Slow down dude, wtf?

WWKong 11y ago

The bigger question is, why are we still programming the way we did 20yrs ago? Higher level languages were a great improvement over machine language. But what comes next? Why don't we have it yet? A decade ago I was setting up database, writing queries, designing forms, writing the code to wire it all up. I still have to do all these steps with more amount of effort today.

merlinsbrain 11y ago
I think Backend-as-a-Service providers are a good step towards a place we want to be, although I still think we're not super close to using such services to deploy complex business logic on. Services like parse cloud code and AWS lambda are another step closer. Context: We (me + couple of collaborators) are writing a similar platform for ourselves, although the purpose is dogfood more than $.
- xyzzy4 11y ago
  Parse is shutting down though.
  - merlinsbrain 11y ago
    While I view them as pioneers in the space, the fact that executed their cloud code functionality, and did it well is enough for the rest of us to take it from here :) Perhaps it's even a part of the (now) open source parse-server? I am not sure, but as I am building a similar thing I will definitely be having a closer look at their source code in the coming weeks.
- davidjnelson 11y ago
  Aws lambda does look like a particularly large innovation regarding complexity management. Anyone have stories on using it to share?
  - room271 11y ago
    Nothing amazingly innovative, but I've used it a lot at work. For simple jobs/event processing it is amazing as it removes a load of complexity (logging, monitoring, scaling, deploying). Lambdas tend to be < 100 lines of Javascript which means maintenance and rewriting is trivial. And because the jobs are so simple people don't need to be Javascript experts or aware of the JS ecosystem to write them. Lambda is also very cheap if you have bursty or just very low-volume workloads.

FreedomToCreate 11y ago

The most important line from the author is "it takes time to be a good programmer". Those nights of debugging and reimplementing will decrease as you better understand how to develop code. Also I find open concept offices terrible to work in. I'm not the type of person who can put on a pair of headphones, blast music and pump out code. I like solitude as I think though the problem and code. Unfortunately for me, the open concept is here to stay it seems.

merlinsbrain 11y ago
I love that line as well. I just told a friend of mine that if I spend the next 10years writing 3 languages exclusively (one per domain of systems, web/mobile application and high concurrency distributed systems) I would hopefully probably be a "good programmer" as I envision it. That might be a tall statement, but that's just my interpretation of how it takes time to become a good programmer, YMMV.

njharman 11y ago

>code that produced it should be cleaned up and documented before the next project was started. A major why waiting to the end to test document and clean up code is a failure. Write beautiful, tested code from the start. Even throwaway code, because half time prototypes, etc end up production.

lifeisstillgood 11y ago
See the middle part "there is not enough time to do it right first time"
- mbrock 11y ago
  And even if there happens to be, check back in six months and see what's happened. Did your beautiful design smoothly accommodate the fix for the tricky issue #5388? Was there enough time then to update your clear documentation, or does the documentation now clearly explain something false? Did the new coworker who implemented that new feature understand the point of your design such that she was able to extend it properly while you were busy for three weeks chasing a deadlock? And so on. Beauty always fades!
  - lifeisstillgood 11y ago
    Agreed
  - davidjnelson 11y ago
    Yup. Unit tests, clean code built via tdd, auto generated docs from interfaces, high level architecture diagrams and explanations on a wiki, instructions on getting your machine / environment set up on a wiki, and api contracts on a wiki are the best documentation from my experience.
seivan 11y ago
You're assuming programmers get the time they need to set up the test environment. Try out a few different libraries to make things easier for testing. Manage quirks and bugs within the tests themselves or test runners and etc. From my PoV that's rarely something we get to allocate time for. The sales people sell "continuous integration" and "tests". But it doesn't mean that we're allowed to allocate time for that.

sjclemmy 11y ago

> Sleep. A lot of programming problems get solved while you sleep. I love it when I go to bed mulling over a problem, and when I get up I have the solution. The brain is truly a wondrous machine!

ksk 11y ago

I don't think programming - in the sense of what 99% of programmers do - is as difficult as programmers love to blog about. Most professional programmers write stuff that is not all that hard, and most of it has been done by others countless number of times. All the "hard" cutting edge stuff is done by a tiny tiny fraction of programmers. Heck even the things people think are cutting edge now, just taking a random example - VR, have been explored decades ago. Seriously, go read some SigGraph papers. However, programmers more than other professionals love blogging about their work, which is great - because it helps spread ideas (more so than any other field I've seen), but also creates this illusion that programming is this super hard thing. I mean people complain about going to interviews and being asked about algorithms and stuff that you could "just google" when, if you were to ask an average scientist, the amount of active working knowledge they have at any given time is simply astounding.

kris-s 11y ago
My pet theory is that even relatively simple programming problems drain a very limited daily resource of programming time (something on the order of 2-4 hours of real work per day). Because a programmer can be drained of programming ability so quickly we just compensate by blogging, posting, talking about it incessantly as a backfill.
mei0Iesh 11y ago
There used to be a difference between scripters and programmers. I'm a scripter, and it feels similar to learning a natural language and writing essays in it. In other words, it's easy and doesn't require any mathematical skill. There are low-level programmers who do things similar to other sciences involving math, and my brain wouldn't be able to do that. So if you're talking about scripting, which I think most people do, then I agree it isn't difficult.
- sklogic 11y ago
  Not sure what do you mean by "scripting", but there is an awful lot of complexity on any level, all the way up. Mathematics and algorithms aside, there are vague requirements and tight deadlines. There is a need to estimate how long will it take (know of anything else harder than this?). There are maintenance considerations which complicate everything, even a one-line script: documenting, packaging, future-proofing against platform updates, etc.

njharman 11y ago

I believe author means things like code, build system, etc when they say "inputs are beautiful". Cause In my experience one of the major inhibitors of beautiful code, what takes many tests, and what makes dev hard is how fucked up input is. Esp user, as in interactive human, input.

dclowd9901 11y ago

If David Sedaris was a software developer...

xdc55 11y ago

It is much easier to prove a particular program function correct when complexity is properly handled, this is the true art of programming, handling complexity in a way that makes sense. Many complex phenomena in nature is explained by very simple mathematical equations, likewise great engineering design is achieved when there is nothing else to remove, and in order to achieve those results, a great deal of effort and thinking has to happen first. The thing is, as the author put out, the environment is just too hostile in order to design beautiful programs, from the insane expectations of what can be done, to incompetent peers, politics, distractions and what not. If you are skilled, you can define a problem in a precise way, be able to dissect it in smaller problems, solve them and prove the solution correct. What is ultimately hard is how to handle the hostile environment you're usually stuck with.

ScottBurson 11y ago

Programming is difficult because it is easy. Here is what I mean. Implementing new functionality where nothing existed before is easy: just figure out what you want the machine to do, and tell it to do that. It isn't trivial, but on a relative scale, it's easy. Precisely because it's easy to create functionality, we do a lot of it. Our programs grow. As they grow, they get complicated. As they get complicated, it gets to be more and more difficult to understand what they're already doing so that we can make them do something different. So, the less tongue-in-cheek version of my thesis here is that programming gets to be difficult because it starts out being easy. This is why I always say that the essence of software engineering is the management of complexity. And this is the part that people who have not actually worked on large programs will probably never understand. (As someone once said to me, "what you need to get is that management views programming as primarily a clerical function".) Viewed one-by-one, the tasks seem simple. And yet, somehow, when you put them all together, they're not simple anymore.

engi_nerd 11y ago
> This is why I always say that the essence of software engineering is the management of complexity. Your point is valid, and you can delete the word "software" and make a more general point that is also true.
imtringued 11y ago
When things are easy expectations rise until they reach a point where things become hard again.

shockzzz 11y ago

Now I find no particular joy in implementing archaic and perverse protocols but often the quickest way to progress is to re-implement them from scratch. whaaaa

meesles 11y ago

I see these posts every so often: "X is hard". Aside from just illuminating the X, I don't really see the point of the posts. Most higher-order jobs are difficult, that's why people train and educate themselves to work in the field. Coding has it's own set of challenges, but I don't think anyone is saying coding something slightly complex is easy. Just like how designing a building is hard, or swimming an olympic time is hard, or solving a complex science equation is hard. If I'm being honest, these posts come off a little whiny.

namnam88 11y ago

All good points, but this is not just specific to programming IMO. I work as a sales engineer for a networking company and I face the same issues as you when I work with customers who use our products. Documentation is never good, you're always solving customer problems so you never really have time to dig deep (read 391 page manuals are out of the question), new features are not described correctly and when I try to lab things up (demo or otherwise) there are about 100 things that can go wrong (I made up that number but you get the idea). Great article though- I think it applies to most technical roles.

jcoffland 11y ago

The author and a number of commentors seem to be saying that incremental changes eventually lead to tangled and unmaintainable code. My litmus test for the quality of a code change is the amount of code it allows me to remove. If a change results in many other parts of the code collapsing or getting simpler then I know I've made a good decision.

aryehof 11y ago

I think for those programming complex systems in business and industry, the biggest problem remains how to represent concepts in code. Even the simplest problem, like a Purchaser placing a Purchase Order for a Product from a Supplier can't be easily modeled and programmed by the majority of software developers - with any sort of predictability based on prior art or their own experience. At best, we approach a problem with a combination of modular procedural code (modularity via subroutines)(from the 1950's) and structured programming with functional decomposition (from the 1960's). There is no shortage of technical prowess, but a warehouse system is not based on design patterns, libraries, frameworks, or technologies. Instead, it is based on people, places, things and transactions interacting together to solve a problem. How to represent real-world concepts and systems (real or abstract) into code, remains the challenge it always has been. We just don't seem to learn any lessons from the past.