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?
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?
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
* 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
* 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
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?
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
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
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
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?
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
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
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
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?
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
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?
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
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
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
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?
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
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?
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
- 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
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?
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
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
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?
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?
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
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
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
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
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
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?
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
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
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
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
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
"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
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
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
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
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?
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
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
- 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
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?
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
"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
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
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
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
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
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
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?
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
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?
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
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
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
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
