Skip to content

Instantly share code, notes, and snippets.

@jakefolio
Created May 10, 2015 14:40
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jakefolio/c898b387147578051f36 to your computer and use it in GitHub Desktop.
Save jakefolio/c898b387147578051f36 to your computer and use it in GitHub Desktop.
10 Steps to Maintainable Software
Writing maintainable software is something we all strive to do when we start a project.
The problem is, there is no simple checklist that states whether your code is maintainable or not.
I once read it is much easier to recognize the absence of maintainable software than to define it.
In this session we will lay out a foundation to building more maintainable software and practices
to better your team workflow. We will cover anything from naming of methods/variables, VCS commit
messages, and code reviews.
@elazar
Copy link

elazar commented May 10, 2015

I'd say add a bit more on the end so that people have a better idea of the benefits of what you'll be covering beyond just that their software will be "more maintainable" (and the meaning of that phrase on its own can be rather subjective).

@adamculp
Copy link

Title: love it!
Abstract: In first paragraph you elude to a need for a checklist, and then do not include it as a deliverable. And there is a difference between "steps" used in title and "checklist" used in abstract.

Also in the first paragraph you state, "I once read.." which has no bearing on the talk to an attendees. Perhaps turn it into a statement like, "It's obvious when software is un-maintainable but hard to define what that means, so this talk will show how to properly define it."

In the 2nd paragraph you elude to "lay out a foundation..." which would be a great opportunity to more clearly define a take-away.

Also in the 2nd paragraph you state, "We will cover anything from..." which is very vague. If you don't wish to define a list, that is understandable. However, come up with a smoother way to define what you will actually cover. (self-documenting code, SOLID, separation of concerns, DRY, abstraction, inheritance, composition over inheritance, etc.)

@jakefolio
Copy link
Author

Thanks for the feedback! I need to describe the deliverables, but not give a complete outline of the talk. I'll take your feedback and rework this abstract a bit.

@lornajane
Copy link

+1 to everything above, from loving the title to needing more substance in the abstract itself. If you're not quite ready to write your 10 things list, then give us a clue - is it in automation? In frontend performance? In the frameworks we choose? In whether we use agile? Pick 3 or 4 things that you know will be themes and include them - then you can fill in the blanks in a panic when the talk gets picked :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment