Agile software development

What Hacker News says

1. pkoirdDec 2022
   So I asked this same question to ChatGPT, here's its response. This thing really does have the potential to be a good recommendation tool for books/resources.

   "Here are a few books that may be helpful for improving your skills as a software engineer:

   "The Pragmatic Programmer" by Andrew Hunt and David Thomas: This book offers practical advice on a wide range of topics, including how to write clean and maintainable code, how to work effectively with others, and how to manage your time and priorities.

   "Clean Code" by Robert C. Martin: This book focuses on the importance of writing code that is easy to read and understand, and provides specific guidance on how to write clean and maintainable code.

   "Peopleware" by Tom DeMarco and Timothy Lister: This book discusses the human side of software development, including how to create effective teams and work environments, and how to avoid common pitfalls such as overwork and burnout.

   "Agile Software Development" by Alistair Cockburn: This book provides an introduction to agile software development methodologies, which are designed to help teams deliver high-quality software quickly and efficiently.

   In addition to these books, there are many excellent blog posts and online resources on these topics. Some websites that may be helpful include the Pragmatic Programmer blog, the Agile Alliance website, and the ACM SIGSOFT Software Engineering Notes journal.

   Another helpful resource may be attending conferences and workshops on software engineering and related topics. These can provide opportunities to learn from experts in the field, network with other professionals, and stay up to date on the latest trends and best practices. Many conferences and workshops also offer certification programs, which can be a valuable way to demonstrate your knowledge and expertise to potential employers. Some well-known conferences in the software engineering field include the ACM SIGSOFT International Symposium on the Foundations of Software Engineering (FSE), the ACM SIGCHI Conference on Human-Computer Interaction (CHI), and the International Conference on Software Engineering (ICSE). "

   Show morethread
2. jdlshoreJul 2022
   At the risk of self promotion, my book (The Art of Agile Development) attempts to balance explaining the underlying theory with providing pragmatic "how to" guidance. A lot of the theory is set up in the first chapter, which is online here:

   https://www.jamesshore.com/v2/books/aoad2/what_is_agile

   The rest of the theory is spread throughout the book, in "key ideas" sidebars (which you can find in the index) and the "Experiments and Alternatives" sections at the end of each practice.

   I'm not aware of any books that are purely about the underlying theory, but these books swing the pendulum more towards the theory side of things:

   Lean Software Development (Mary and Tom Poppendieck) - if you only read one, this is the one to read

   The Principles of Product Development Flow (Tom Reinertsen)

   Agile Software Development, 2nd. ed. (Alistair Cockburn)

   Extreme Programming Explained, 2nd ed. (Kent Beck)

   The Lean Startup (Eric Ries)

   Show morethread
3. shellabJan 2014
   The book that really helped me was Agile Software Development by Robert Martin. It outlines some of the best principles for writing software that will be high quality and easy to extend and refactor for years to come.
   thread
4. andrewcookeSep 2013
   i like http://www.amazon.com/Agile-Software-Development-Cooperative... (cockburn's cooperative game), but i am not sure if it's suitable for a library.

   i guess what i mean is, that i think it's a great book for a developer. but it's not very prescriptive, so may not be great for teaching. it's more about trying to get you to think than telling you what to do. imho.

   thread
5. whstlJul 2023
   Calling it a misconception is not really fair.

   The "serve a single actor" is a recent revision of the principle by Uncle Bob, from a 2018 book, AFAIK. That's almost 20 years too late (if going by the sources I can find).

   I can't find mentions of "actors" or similar terms in Agile Software Development or Clean Code. Pretty much every pre-2018 literature says that SRP relates to modules "[having a] single reason to change", or "[not having] too many responsibilities". The examples are always fuzzy and imprecise, but in the books the principle essentially boils down to class/method size. There are no examples in Clean Code or ASD relating to this new meaning, nor mentions of "actors" or "stakeholders", and until recently there's rarely any article contradicting the original meaning of SRP.

   This revisionism seems to come first from backlash from part of the programming community, and also an adaptation of the more recent "one team per microservice" rule.

   But the damage of almost 20 years of SRP being taught the way it was in the past was already done.

   Show morethread
6. jdlshoreNov 2022
   I’ve found hardware-oriented businesses to be woefully behind the times when it comes to software engineering processes. This article is no exception. Although I agree with his overall framing, once you get to the details, James is describing a document-oriented approach that was in vogue about 25 years ago, and has long since been superseded.

   What replaced it? Agile. Wait, don’t throw rotten vegetables—I’m not talking about the overwrought excuse for micromanagement people call “Agile” nowadays, but the truly innovative thinking that was happening in the late 90s and early 2000s. Stuff like the Poppendiecks’ Lean Software Development (based on their experience at 3M) and Cockburn’s Agile Software Development (based on research he originally conducted at IBM). And of course Beck’s Extreme Programming, based in part on his work with Ward Cunningham at Tektronix.

   These processes and thinking started with the reality that it’s impossible, given a large, complex system, to correctly specify everything in advance. They recognized that documents are a particularly poor communication medium—one that’s time-consuming to create and consume, and very difficult to do in a way that isn’t misunderstood.

   Instead, they focused on people as more important than process, and adaptation as more important than prediction. Traditional SDLCs fell by the wayside, and for good reason: they didn’t work well. Their document-heavy approach resulted in poor visibility for management and software that met the spec but not customer needs.

   I talk about this more in my book. The first chapter talks about how and why Agile supplanted traditional processes. It’s free online (along with a lot of other material) here: https://www.jamesshore.com/v2/books/aoad2/what_is_agile

   Show morethread