-
-
Save jakefolio/c898b387147578051f36 to your computer and use it in GitHub Desktop.
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. |
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.)
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.
+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 :)
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).