#DevDiscuss Archive


Tuesday October 16, 2018
9:00 PM EDT

  • ThePracticalDev Oct 16 @ 9:03 PM EDT
    Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • ThePracticalDev Oct 16 @ 9:05 PM EDT
    Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • DanFellini Oct 16 @ 9:06 PM EDT
    No need to be clever. Write clear code, even if it means more typing. Comment as much as necessary but don't overdue it. $x is rarely a good variable name except in a for statement. #devdiscuss
  • ASpittel Oct 16 @ 9:07 PM EDT
    * Use clear naming conventions * Write modular code * Write good documentation * Be consistent I wrote a full post on this a little while ago! https://t.co/1FWWy6k8rA #DevDiscuss
  • ASpittel Oct 16 @ 9:07 PM EDT
    * Use clear naming conventions * Write modular code * Write good documentation * Be consistent I wrote a full post on this a little while ago! https://t.co/TPzM1ZKThh#DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • KPath001 Oct 16 @ 9:07 PM EDT
    One of the things I learned the hard-way and from my mentor is modularizing your code as much as possible and make it readable. When you break up your code into multiple files and methods/functions you'll have an easier time debugging #devdiscuss
    In reply to @ThePracticalDev
  • t_sedgwick Oct 16 @ 9:07 PM EDT
    Developers should look to optimize for correctness and future readability first over performance. In most cases, simplicity and developer velocity are more important than shaving a few milliseconds off the code’s performance. #DevDiscuss
  • julichala Oct 16 @ 9:08 PM EDT
    #DevDiscuss design patterns and best practices like a paranoid.
    In reply to @ThePracticalDev
  • JhonnyBillM Oct 16 @ 9:09 PM EDT
    This is an excellent talk: “Embracing legacy code” https://t.co/rxHWsZKAVF #DevDiscuss
    In reply to @ThePracticalDev
  • bendhalpern Oct 16 @ 9:09 PM EDT
    A few key elements of maintenance come to mind: - Habits - Incentives - Permissions If the practices that lead to maintainable software are encouraged and considered of value, maintainable software is built. If the right behavior is not valued, we get a mess. #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • bendhalpern Oct 16 @ 9:12 PM EDT
    If maintainable code is what the cool kids are doing, everyone will write maintainable code. #DevDiscuss
  • lucasheim_ Oct 16 @ 9:14 PM EDT
    I've watched a @martinfowler presentation about refactoring that was reeeeeally interesting and talked about doing little refactors everytime and not waiting for a "planned refactor". This helps a lot with software mantaining as it scales https://t.co/WyyMwzk0l9 #DevDiscuss
    In reply to @ThePracticalDev, @martinfowler
  • gatlingxyz Oct 16 @ 9:14 PM EDT
    I've learned, after many, many years of ignoring it, that MVP (and other architecture patterns) and unit tests are LIFE SAVERS. Abstraction and testing have made my life so much easier. #DevDiscuss
  • bendhalpern Oct 16 @ 9:15 PM EDT
    If you try too hard to write "maintainable code", though, you might not ship anything. You write "good code"—the kind that gets released on time(ish) and has the general characteristics of code that will likely be maintainable. You never know. You try your best. #DevDiscuss
  • t_sedgwick Oct 16 @ 9:16 PM EDT
    Future you will appreciate your decision to keep the code maintainable by focusing on being deliberate and simple in your code. #DevDiscuss
  • bruno_dsm Oct 16 @ 9:16 PM EDT
    Use meaningful names for variables, functions and methods. It does save a lot of time when you're on call trying to solve a problem. #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • bruno_dsm Oct 16 @ 9:17 PM EDT
    It is important to have a reasonable test coverage for the feature/fixes you're developing. It helps the maintainer to keep track that his/her changes won't break the system. Also, the tests need to have successful/failure cases in order to be effective. #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • cathodion Oct 16 @ 9:17 PM EDT
    To build maintainable software for developers: - Readable documentation - Deterministic and fast unit tests - Comment and clean up the code - Refactoring For teams, allow time for the above, and understand refactoring #DevDiscuss
    In reply to @ThePracticalDev
  • jmdembe Oct 16 @ 9:17 PM EDT
    Say no to ‘this=that’ in your code. I have seen this before and it made want to kick things #devdiscuss
  • KPath001 Oct 16 @ 9:18 PM EDT
    Another thing is if your project is utlizing a framework or library try your best to maintain the functionality within the bounds of the framework/library. #devdiscuss
    In reply to @ThePracticalDev
  • dangolant Oct 16 @ 9:19 PM EDT
    Great point. I think it was @mipsytipsy who said ~"never design for more than 10x your current scale". I've definitely run into more issues debugging because of too much indirection than I have from like... something not being fix-able fast enough to meet a need. #devdiscuss
    In reply to @t_sedgwick, @KPath001, @ThePracticalDev, @mipsytipsy
  • sam_ferree Oct 16 @ 9:19 PM EDT
    Maintainable Code? You bet your SOLID butt I have opinions! #DevDiscuss
  • bruno_dsm Oct 16 @ 9:19 PM EDT
    Do not take logging for granted, it helps to track what happened in a unusual behaviour. #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • jmdembe Oct 16 @ 9:20 PM EDT
    Incremental infrastructure improvements! Because there will never truly be a “down” time in developing features. #devdiscuss
  • JT_Grimes Oct 16 @ 9:20 PM EDT
    Never ever think "I'll remember this." If you can't make a fix, open a ticket. If you can't open a ticket, at least put in a TODO comment. More than half of code maintenance is saying "what were we going to do about this?" #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • hassan_theitguy Oct 16 @ 9:20 PM EDT
    What can developers do to build maintainable software? Document, refactor, source control, peer reviews and code reuse comes to mind. #DevDiscuss
  • ASpittel Oct 16 @ 9:21 PM EDT
    I follow Sandi Metz's rules 99% of the time too: * methods only five lines long * classes only 100 lines * four arguments or less per method * controller can only instantiate one object #DevDiscuss
  • luxaritas Oct 16 @ 9:21 PM EDT
    - Small, well defined modules with low coupling - Obvious, consistent naming - Documentation (don’t leave anything in someone’s head) - Forethought and emphasis on “clean” over “fast”, with opportunities to refactor #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • Wintermute21 Oct 16 @ 9:21 PM EDT
    Refactor, refactor refactor. Make it work then make it pretty. #devdiscuss
  • t_sedgwick Oct 16 @ 9:22 PM EDT
    Premature / over optimization can completely derail a codebase’s readability and purpose. I harp on being developer forward in my code. I always keep the next developer (including future me) in the back of my mind when developing. #DevDiscuss
    In reply to @dangolant, @KPath001, @ThePracticalDev, @mipsytipsy
  • dangolant Oct 16 @ 9:22 PM EDT
    I think the key word here is "investment", which is a form of sacrifice. You sometimes will need to sacrifice speed, and invest in your workflow / product, in order to make something maintainable and gain speed down the line. #devdiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • dahlbyk Oct 16 @ 9:22 PM EDT
    Don't fix a bug without a failing test to prove there is an issue. If you don't have tests, start with these—then automate them! #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • Ld00d Oct 16 @ 9:22 PM EDT
    Remember when you're not writing an external facing API, you don't need to abstract everything down to the one call. Go ahead and inject that class. It's ok for the other code to know the concrete type. It will make things sooooo much easier for me to debug. #DevDiscuss
    In reply to @ThePracticalDev
  • hassan_theitguy Oct 16 @ 9:23 PM EDT
    What can teams and orgs do to build maintainable software? Hire enough devs, pair junior developers with senior developers and choose the appropriate technology stacks for the job, comes to mind. #DevDiscuss
  • DarkainMX Oct 16 @ 9:23 PM EDT
    Tonight's #DevDiscuss? Simple. Style guides. Look up the one @ID_AA_Carmack did for @idSoftware. It helps ensure everyone is in the same page about what code should do based on name alone.
    In reply to @ThePracticalDev, @ID_AA_Carmack, @idSoftware
  • hassan_theitguy Oct 16 @ 9:23 PM EDT
    What can developers do to build maintainable software? Document, refactor, source control, peer reviews and code reuse, comes to mind. #DevDiscuss
  • bendhalpern Oct 16 @ 9:24 PM EDT
    Don't think too big (strict high-level architecture) or too small (fussing over the tiniest improvements). Dip in and out of different abstraction levels and don't be too high and mighty about the code you write. It's ultimately a means to an ends. #DevDiscuss
  • davidbrunelle Oct 16 @ 9:24 PM EDT
    Controversial opinion: Focus on designing and building the right-sized solution that delivers high ROI. A heavy focus on maintainability doesn't *always* pay off and a premature focus on maintainability can waste energy, time, and money. #devdiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • dangolant Oct 16 @ 9:25 PM EDT
    In my reviews, I sometimes feel nitpicky when I suggest var name changes, but then I remember that if I didn't immediately get something *minor*, that's *exactly* the part that should be clear, because there are parts that are invariably going to get a bit hairy. #devdiscuss
    In reply to @t_sedgwick, @KPath001, @ThePracticalDev, @mipsytipsy
  • sam_ferree Oct 16 @ 9:25 PM EDT
    Slice your applications vertically by features, not horizontally by "layers" Do you have a moment to talk about our lord and savior CQRS? #DevDiscuss
  • ASpittel Oct 16 @ 9:26 PM EDT
    I try to... I started doing it just to challenge myself but then I found that it was really helpful and not that hard to get used to. #DevDiscuss
    In reply to @OsuvaldoRamos
  • davidbrunelle Oct 16 @ 9:26 PM EDT
    Before emphasizing maintainability ask: How long will this take last? Building something with a short shelf life? Maybe it doesn't matter. Will your codebase live on for years and years? Better make it easy to operate, maintain, and extend. #DevDiscuss
  • dangolant Oct 16 @ 9:26 PM EDT
    This is how I upped my git game, I saw that the people on my team more senior than me cared about good git commit messages and history. Maybe it's a bit meta, but I feel like a git history at some point contributes to "maintanability" #devdiscuss
    In reply to @bendhalpern
  • cathodion Oct 16 @ 9:27 PM EDT
    Refactoring means making changes to the code to improve its structure *without changing its functionality*. This requires unit tests. Martin Fowler's book on the subject is worth a skim. #DevDiscuss
    In reply to @ThePracticalDev
  • ASpittel Oct 16 @ 9:27 PM EDT
    Also, if you haven't read POODR, it's incredible https://t.co/kXlsYJ9lWO #DevDiscuss
  • ThatJoeMoore Oct 16 @ 9:27 PM EDT
    A maxim from my days as a Boy Scout comes to mind: "Leave your campsite better than you found it." Every time you touch a function/file/module/test case, leave it better than you found it. Rearrange things, update dependencies, add comments, add a test or two. #DevDiscuss
    In reply to @ThePracticalDev
  • KPath001 Oct 16 @ 9:27 PM EDT
    "Any fool can write code that a computer can understand. Good programmers write code that humans can understand. "~Martin Fowler and another solid point for software maintainability #devdiscuss
    In reply to @dangolant, @t_sedgwick, @ThePracticalDev, @mipsytipsy
  • simpgeek Oct 16 @ 9:28 PM EDT
    Don’t mutate data #DevDiscuss
  • davidbrunelle Oct 16 @ 9:28 PM EDT
    Another consideration: How often will the thing I'm building change? The answer will impact how much time you should spend on making that thing maintainable over time. #DevDiscuss
  • Wintermute21 Oct 16 @ 9:28 PM EDT
    POODR should be on anyone's to read list. I'ma buy a copy as soon as I can afford one. #devdiscuss
    In reply to @ASpittel
  • ardalis Oct 16 @ 9:28 PM EDT
    Remember, "New is Glue" #DevDiscuss https://t.co/f2ctZIhYL4
  • cathodion Oct 16 @ 9:28 PM EDT
    Management might misunderstand refactoring to mean either (a) wasting time or (b) rewriting. If you aren't sure if they understand, call it cleanup instead. #DevDiscuss
    In reply to @ThePracticalDev
  • dangolant Oct 16 @ 9:28 PM EDT
    I think the point about "permission" is paramount. If the response to "hey X is getting a bit hairy" is "well, we don't own that", you're discouraging a culture of improvement. That being said, the answer "so fix it" needs to come with some offer of help IMO. #devdiscuss
    In reply to @bendhalpern
  • bruno_dsm Oct 16 @ 9:29 PM EDT
    Premature optimisation is still one of the four horsemen of apocalypse (in software development). Be careful with that. #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • emiliovicentem Oct 16 @ 9:29 PM EDT
    Avoiding the classic mistakes that @stevemconstrux that directly or indirectly leads to unmaintainable code #devdiscuss https://t.co/6p0pQRYqNg (see pages 18 and 19)
  • dangolant Oct 16 @ 9:30 PM EDT
    I've been meaning to get to POODR. I think the rules included with Rubocop have upped my game *alot* in this aspect, and they take heavy cues from her AFAICT. #devdiscuss
    In reply to @ASpittel
  • hassan_theitguy Oct 16 @ 9:30 PM EDT
    Any words of wisdom for software maintenance? Keep code base at a manageable state, e.g. avoid feature creep and make deprecating features a priority. #DevDiscuss
  • cathodion Oct 16 @ 9:30 PM EDT
    Refactoring should be done separately from adding features or fixing bugs. At least in a separate commit. #DevDiscuss
    In reply to @ThePracticalDev
  • Nick_Craver Oct 16 @ 9:31 PM EDT
    - Care. This is step 1. - Get those who manage time allocation to care and see that's it takes less time in the long-run to do it right now. - Don't be short-sighted. A hack that saves some time today will cost you twice as much later. #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • ASpittel Oct 16 @ 9:31 PM EDT
    yeah, I agree. I like concrete guidelines though, so it really works for me. Here's a talk with more about them, definitely okay to break them! https://t.co/bnhT8x6YW4 #DevDiscuss
    In reply to @falicon
  • nicktail Oct 16 @ 9:32 PM EDT
    Stop putting it off! I've worked on a system recently where necessary upgrades had been put off for *seven years* because product managers are only interested in new things they can sell, not old things they have to maintain. Listen to your devs, and invest in them. #devdiscuss
    In reply to @ThePracticalDev
  • MrTurnerj Oct 16 @ 9:32 PM EDT
    Something I have been saying to my team recently is leaving code better than you found it. It doesn't mean replace the entire system but a function or two refactored help tackle the problem in bite-sized chunks. #DevDiscuss
    In reply to @ThePracticalDev
  • dangolant Oct 16 @ 9:32 PM EDT
    I think even just saying "ok this standard pattern/arch is good enough *for now*" is better than some of the more... evolutionary approaches I've seen that maybe fit the case better but are less standard. #devdiscuss
    In reply to @gatlingxyz
  • ASpittel Oct 16 @ 9:33 PM EDT
    It's one of my favorite books period even when I take non-programming books into account. I always give this quote to my students on their last day: #DevDiscuss
    In reply to @Wintermute21
  • Nick_Craver Oct 16 @ 9:34 PM EDT
    If convincing management tech debt is a huge issue doesn't work at first, but it's building...you can often show it's been building. Go back. Look at your estimates of time for features. You'll see them trend up as they come with more debt to fix before progressing. #DevDiscuss
  • cathodion Oct 16 @ 9:34 PM EDT
    A fast and deterministic unit test suite is very helpful. Usually means I/O and data access are mocked/faked though, which has downsides. Having automated integration tests might be beneficial, but it's good to have a test suite you can run in less than a second. #DevDiscuss.
    In reply to @ThePracticalDev
  • MrTurnerj Oct 16 @ 9:34 PM EDT
    I found out later that apparently this is called the boy scouts rule. #DevDiscuss
    In reply to @ThePracticalDev
  • Wintermute21 Oct 16 @ 9:35 PM EDT
    I always tell coworkers, "programming is the closest thing adults have to magic, because of what we can build from scratch" #devdiscuss
    In reply to @ASpittel
  • ramsey Oct 16 @ 9:35 PM EDT
    Creating tickets for things that pop into my head as I’m coding has become so freeing. I don’t have to keep it in my head, so the urgency to do it isn’t there, and I can focus on the task in front of me. #devdiscuss
    In reply to @JT_Grimes
  • JT_Grimes Oct 16 @ 9:35 PM EDT
    Maintainability is less important than shippability - nobody submits feature requests on software that hasn't been released. If you have a choice between getting it *right* and getting it *done*, pick *done*. #DevDiscuss
  • dangolant Oct 16 @ 9:37 PM EDT
    How do you balance it though? #devdiscuss
    In reply to @JT_Grimes
  • brianfenton Oct 16 @ 9:38 PM EDT
    code doesn't add any value to the org until it's in production. Adding small value & iterating is way more useful than sitting on a stale branch for months #DevDiscuss
    In reply to @JT_Grimes
  • ardalis Oct 16 @ 9:38 PM EDT
    Know and follow the Explicit Dependencies Principle (at least in strongly typed languages): https://t.co/C2pDh5SRdG #DevDiscuss
  • dangolant Oct 16 @ 9:38 PM EDT
    I started doing this a while back any time I would get frustrated by something outside of the problem I was *currently* working on, and it's made me much happier. I pretty much use tickets as a scratch pad now (can always delete them later) #devdiscuss
    In reply to @ramsey, @JT_Grimes
  • cathodion Oct 16 @ 9:38 PM EDT
    It should either succeed every time or fail every time. An example of a non-deterministic test would be something that relied on a worker thread that sometimes takes too long to complete, or fails when the network is slow. #DevDiscuss
    In reply to @santosroosevelt
  • ASpittel Oct 16 @ 9:38 PM EDT
    YES they totally are influenced by her. I really like Rubocop! #DevDiscuss
    In reply to @dangolant
  • dangolant Oct 16 @ 9:39 PM EDT
    This is always my question about mocks/fakes/things like VCR... at what point are you not testing in real world conditions? #devdiscuss
    In reply to @cathodion, @ThePracticalDev
  • davidbrunelle Oct 16 @ 9:39 PM EDT
    The best way I've found to get the balance right is by breaking work down into the smallest releasable increments. Delivering value continuously, in small pieces, helps you understand where to focus. #DevDiscuss
    In reply to @dangolant, @JT_Grimes
  • ASpittel Oct 16 @ 9:40 PM EDT
    It is at first, but it become a lot easier once you get used to it! #DevDiscuss
    In reply to @BekahHW
  • ASpittel Oct 16 @ 9:41 PM EDT
    Interesting, for me, I really stick by the methods and functions should do one thing and one thing only rule. I find that ~5 lines is normally good -- sometimes up to 10. #DevDiscuss
    In reply to @vikram_sun, @OsuvaldoRamos
  • dangolant Oct 16 @ 9:41 PM EDT
    On the third point, I feel like it's a clear point, and everyone accepts it, but it's in the category of things "I know it's bad but I won't ever learn it unless I make the mistake myself" #devdiscuss
    In reply to @Nick_Craver
  • davidbrunelle Oct 16 @ 9:42 PM EDT
    Worst case: you invest a ton of time making a feature maintainable and a competitor beats you to market. Or, you make a thing maintainable and customers never use it... Then the feature gets killed. #DevDiscuss
    In reply to @dangolant, @JT_Grimes
  • CrispinOwuor Oct 16 @ 9:42 PM EDT
    @ThePracticalDev #devdiscuss youtube is down, someone should have maintained the code lol
  • gatlingxyz Oct 16 @ 9:43 PM EDT
    See, this is how I get myself in trouble. I'd much prefer taking a second and just making it right the first time so I'm not trying to fix it later just so we can get it out faster. #DevDiscuss
    • JT_Grimes Oct 16 @ 9:35 PM EDT
      Maintainability is less important than shippability - nobody submits feature requests on software that hasn't been released. If you have a choice between getting it *right* and getting it *done*, pick *done*. #DevDiscuss
  • dangolant Oct 16 @ 9:43 PM EDT
    Right, makes sense. the actual decomposition seems more like intuition/experience than "here are some soft rules", because if you decompose wrong you might just end up with a bunch of branches running in parallel cross-dependent on each other #devdiscuss
    In reply to @davidbrunelle, @JT_Grimes
  • ASpittel Oct 16 @ 9:44 PM EDT
    YES! I love how she talks about integrating functional programming and OO elsewhere too -- I really like this answer from her @ThePracticalDev AMA #DevDiscuss
    In reply to @dceddia, @sandimetz, @ThePracticalDev
  • KPath001 Oct 16 @ 9:44 PM EDT
    I try my best at the 10 lines max rule! Whenever I go overboard I usually leave a comment to come back and refactor the extra lines into a separate method #devdiscuss
    In reply to @ASpittel, @vikram_sun, @OsuvaldoRamos
  • JT_Grimes Oct 16 @ 9:45 PM EDT
    "How do you measure tech debt" would be a great topic for a later #DevDiscuss.
    In reply to @Jhony0311, @ThePracticalDev
  • Programazing Oct 16 @ 9:45 PM EDT
    Check out my website/blog at https://t.co/4DAQVTUa1s #DevDiscuss
  • davidbrunelle Oct 16 @ 9:46 PM EDT
    One more thought: Focus on *simplicity* over *maintainability.* Simple systems are inherently easier to maintain. I've seen systems where maintainability was the goal end up becoming brittle, over-engineered, and impossibly complex. #devdiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • dangolant Oct 16 @ 9:46 PM EDT
    I like how Ruby's sparse syntax (python is good for this too imo) has made me more comfortable with 1-2 line functions. Looks way worse in JS/curly langs imo #devdiscuss
    In reply to @ASpittel, @vikram_sun, @OsuvaldoRamos
  • jfrankcarr Oct 16 @ 9:47 PM EDT
    "This VB6 program originally written in 2000 still works fine. If we need something new, your team patches it in for us. Why would we need to replace it?" #devdiscuss
    In reply to @Nick_Craver
  • davidbrunelle Oct 16 @ 9:47 PM EDT
    My friend @HenrikJoreteg said it best: #devdiscuss https://t.co/5RkZgDSLqa
    In reply to @HenrikJoreteg
    • HenrikJoreteg Aug 7 @ 2:00 AM EDT
      If you don’t actively fight for simplicity in software, complexity will win. …and it will suck.
  • jimmykoppel Oct 16 @ 9:47 PM EDT
    Practice looking at each line of code and asking "What changes to the rest of the system will make this break?" Then practice techniques for reducing that. Then learn to apply these techniques judiciously. #DevDiscuss
    In reply to @ThePracticalDev
  • jimmykoppel Oct 16 @ 9:47 PM EDT
    Get your data structures right and the rest will follow #DevDiscuss
    In reply to @ThePracticalDev
  • eric_dolecki Oct 16 @ 9:47 PM EDT
    Struct as an argument for a method is yummy. #DevDiscuss
  • bendhalpern Oct 16 @ 9:48 PM EDT
    The readability gains of 1-2 line functions are probably bigger when there is less curly-bracket noise #DevDiscuss
    In reply to @dangolant, @ASpittel, @vikram_sun, @OsuvaldoRamos
  • ramsankar83 Oct 16 @ 9:49 PM EDT
    End User is the king they don't give a shit about beautiful code, but developers need maintainable code to be resilient to changes. Do not obsess over beauty or metrics, beautiful code does not mean maintainable code. There are no thumb rules! #devdiscuss
  • ASpittel Oct 16 @ 9:49 PM EDT
    yeah -- though I'm mostly a Python person for math stuff, and so much is built in that it's not hard to stick to this. I've built some pretty robust statistical apps while following these rules #DevDiscuss
    In reply to @eric_dolecki, @ThePracticalDev
  • dangolant Oct 16 @ 9:49 PM EDT
    Totally! Also, leads to more composable code IMO #DevDiscuss
    In reply to @bendhalpern, @ASpittel, @vikram_sun, @OsuvaldoRamos
  • littlekope0903 Oct 16 @ 9:51 PM EDT
    Hey all, sorry I missed #DevDiscuss tonight! Needed some rest. Be back next week!
  • ozzyogkush Oct 16 @ 9:51 PM EDT
    I definitely agree with 4 arguments or less per method/function. Keep the complexity low. I try to keep it even smaller if possible. number of lines can depend on formatting and linter rules too but i mostly agree they should be limited to doing one thing well. #DevDiscuss
    In reply to @ASpittel
  • dangolant Oct 16 @ 9:51 PM EDT
    Always liked this post on Software "Gardening" https://t.co/HawM0L139V #DevDiscuss
    In reply to @bendhalpern
  • AliKolahdoozan Oct 16 @ 9:52 PM EDT
    Try to do coding - bug free - reusable - independent - less complex - well documented - easy to change #DevDiscuss
  • bendhalpern Oct 16 @ 9:53 PM EDT
    I independently started using the term "gardening" myself a couple years ago. It's a wonderful metaphor (hence tonight's gif 😄) #DevDiscuss
    In reply to @dangolant
  • ProgrammerAl Oct 16 @ 9:53 PM EDT
    Haven't seen people mention much about tools for code maintainability. Source analyzers like SonarQube are great to be able to view ratings over time and make sure the code base is improving. Just don't get too invested in hitting certain numbers. #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • cdrrazan Oct 16 @ 9:53 PM EDT
    Breaking and optimizing the components on basis of client requirement maybe the actual better way to have manageable softwares. Debugging and feature updates or feature add could get weird in sense of large codebase otherwise. Just a few cent. *phew. #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:05 PM EDT
      Time for #DevDiscuss Tonight’s topic is Software maintenance! 🛠 Questions to start: - What can developers do to build maintainable software? - What can teams and orgs do to build maintainable software? - Any words of wisdom for software maintenance?
  • dangolant Oct 16 @ 9:54 PM EDT
    the gif is what reminded me of it hahahaha #devdiscuss
    In reply to @bendhalpern
  • ThePracticalDev Oct 16 @ 9:54 PM EDT
    In the last few minutes of #DevDiscuss, does anybody have any news to share, like a project or a personal win, or any other announcement?
  • dangolant Oct 16 @ 9:55 PM EDT
    Tools and metrics are great, but I've seen them go wrong when upper management tries to use them in the wrong way. You poison your metrics when you just try to chase coverage/scores #devdiscuss
    In reply to @ProgrammerAl
  • ASpittel Oct 16 @ 9:56 PM EDT
    I wrote about the skills that are most important for programmers outside of programming, like collaboration, communication, patience, and creativity, and why they are all so important! https://t.co/cEmt6zPV3t #DevDiscuss
    • ThePracticalDev Oct 16 @ 9:54 PM EDT
      In the last few minutes of #DevDiscuss, does anybody have any news to share, like a project or a personal win, or any other announcement?
  • Wintermute21 Oct 16 @ 9:57 PM EDT
    currently looking for a new .NET based engineering role. #devdiscuss
    • ThePracticalDev Oct 16 @ 9:54 PM EDT
      In the last few minutes of #DevDiscuss, does anybody have any news to share, like a project or a personal win, or any other announcement?
  • cathodion Oct 16 @ 9:58 PM EDT
    When you're the one doing maintenance: - Add tests - Add documentation - Do cleanup (and maybe refactoring) #DevDiscuss
    In reply to @ThePracticalDev
  • DanFellini Oct 16 @ 9:58 PM EDT
    I've made a workplace decision to use vanilla JS going forward (when it's feasible) instead of jQuery (which I love and rely on) for my personal growth, and for future maintainability. Not sure if this is a win or not but I'm doing it. #devdiscuss
  • ASpittel Oct 16 @ 9:58 PM EDT
    I think it depends on the language, but some optimize for it. Also, the cost is so tiny especially in comparison to other factors (at least in my opinion) #DevDiscuss
    In reply to @naikrovek, @ThePracticalDev