Posts in Category: Agile

WordCamp Nashville 2016: The promise and peril of Agile and Lean practices

On September 20, 2016 by Mike With 0 Comments - Agile, WordPress
Presenting "the promise and peril of Agile and Lean practices" at WordCamp Nashville 2016

Presenting “the promise and peril of Agile and Lean practices” at WordCamp Nashville 2016

I’ve spoken at WordCamp Nashville every year since it started in 2012, and it was an honor to be invited back again this year. In preparing my talk, I wanted to share my experiences, both good and bad, in bringing Lean and Agile practices to different organizations over the years. Adopting these practices can lead to enormous benefits in quality, customer satisfaction, and developer happiness. But they can also involve very painful transitions, they can go very wrong if not done carefully, and some practices don’t translate well to the world of consulting and freelance work. The challenge was to present all these considerations, in 40 minutes, which doesn’t really allow time to explain a whole lot about actual Agile and Lean practices! My goal was to explain just enough about Agile and Lean – what they have in common and how they are different – and give some real life examples of what to expect if you try them in various kinds of work environments. The audience had great questions for me and I got really good feedback after the talk, so it went well. Here are my slides (they’re also embedded below).

As always, the after-party was great. It was at The Family Wash this year, and I saw a lot of familiar faces. Nashville is starting to feel like a 2nd home.

Here are my slides:

WordCamp Nashville 2016: The promise and peril of Agile and Lean practices from mtoppa

There were a bunch of excellent talks this year. I especially enjoyed these two:

I also had time to do some exploring around Nashville. Since it wasn’t my first time there, I skipped most of the touristy stuff. I spent most of my time in the Germantown neighborhood, where the WordCamp was held this year. Here are some pictures:

Mike’s Talk on Dependency Injection for PHP

On September 10, 2015 by Mike With 0 Comments - Agile, WordPress
Mike Toppa speaking at Boston PHP

Mike Toppa speaking at Boston PHP

Yesterday at the Boston PHP meetup I gave a talk on Dependency Injection for PHP. It went really well and I got a bunch of great questions at the end.

Our speaker Mike Toppa will first review some key concepts for object oriented programming in PHP. He’ll then discuss the benefits of writing small classes, how to do class auto-loading, and explain how to get your objects working together through the use of an injection container. He’ll also cover more advanced techniques for managing multiple object dependencies, dynamic dependencies, and dependencies within dependencies.

For a preview of the talk, here’s a short interview I did with Matt Murphy, who is one of the Boston PHP organizers, and my slides are below the video.


“This program has performed an illegal operation” – Why are error messages so bad?

On September 5, 2015 by Mike With 0 Comments - Agile

Last week Thomas Fuchs wrote an excellent post on how to write a great error message. He shows plenty of examples of all-to-common terrible error messages, and has solid advice on how to do it better.

For me this sparked the question, why has the software industry been so bad at this, and for so long? When I was in grad school, I made money on the side teaching people (mostly middle-aged) how to use their home computers. When I went to visit one of my clients, she was visibly shaken as I walked in the door. She told me she just got a message saying she had performed an “illegal operation.” She was genuinely concerned that it might have been automatically reported to the police. I had to explain to her that “illegal” had a different meaning to programmers, and it had nothing to do with criminality.

This program has performed an illegal operation

As someone who’s been responsible for my own share of unhandled errors and poor error messages over the years, I’ll share my thoughts on why this happens, and what to do about it:

  • Errors lost by the wayside of the “happy path:” developers, project managers, and most everyone involved in developing an application are focused on how to deliver the features they want their customers to use. The desired series of actions we want users to take is the “happy path” through the application. In developing and testing, we get tunnel vision, tending to use the application the same way, over and over again. But actual users will do all kinds of things with an application that we developers never dreamed of, and unintentionally will come up with novel ways to break it.

    Many years ago I had a formative experience as a junior developer: I was invited to a professional user testing lab, complete with one-way glass for watching participants. After months of working on the application being tested, and clicking through the same screen hundreds of times myself without incident, I was astonished to see a user completely crash our application in less than 60 seconds.

    Also, we developers often make all kinds of implicit assumptions about the environment of the application: database connections, API dependencies, browser versions, etc. We often don’t provide good error handling for when dependencies in the environment fail or don’t behave as we expect.

  • Lack of cross-functional teams: many organizations have tried to solve these problems by having dedicated testing teams. These teams are often great at finding errors, but then their reports are “thrown over the wall” back to the developers. The developers themselves may be divided into a database team, a back-end coding team, UI team, etc. A UI developer may be asked to add an error message, but this developer may be dealing with results from code created by a back-end developer that returns only “true” or “false,” indicating only whether the function worked out not. This leaves them with little useful information to communicate back to the user. A situation like this may very well be the story behind this Windows 10 error:

    Something happened

  • No recognition of business value: this is the key issue. The quality of error handling will only be as robust as the weight its given in the cost/benefit analysis that goes into the prioritization of work. For many projects I’ve seen, error handling often doesn’t come up as a point of discussion in the planning process, as an area where time and money needs to be dedicated. Which browser versions need to be supported? How often and what kinds of user testing should we do? How should we handle an API outage? Questions like these often go unraised (now that I’m old and wise, I always make sure to raise them 😉 ).

Error handling is an especially important issue for a consulting company like ours. Nothing will shake a client’s confidence in your ability more than seeing the application you’re developing for them crash with a cryptic and unhelpful error message. How do we address this, and how do we do it without driving the budget for a project through the roof?

  • Have Agile, cross-functional development teams: this removes the organizational barriers that prevent testers, developers and UI designers from working closely together. It allows their focus to go where it should: to the needs of the user, instead of being driven by the implicit incentives of organizational divisions. This approach doesn’t add cost, and may even decrease it.
  • Have a standard design pattern for handling errors: dealing with ugly error conditions only when your boss notices or a customer complains is a recipe for inconsistent results and messy, hard to maintain code. A better approach is for the team to develop a standard for how error conditions will be reported up the stack (e.g. from the database, to the business code, to the UI). This facilitates making error handling a routine and consistent aspect of the development process. Fuchs also provides excellent advice on the front-end aspect of this: having good and consistent UI elements for displaying error messages, and using clear, human-readable language.
  • Have standards for testing: you should have an automated test suite that confirms your error handling continues to function as expected as the application code evolves and changes (as it would be prohibitively expensive to manually and repeatedly test all the edge cases in the application). Usability testing with real customers is also important, but when and how to do this depends on several factors, such as whether the application is intended for use by the public.

Rails and WordPress, BostonRB and WordCamp Boston

On July 21, 2015 by Mike With 0 Comments - Agile, Ruby on Rails, WordPress

I recently moved from Philadelphia to Boston, and my house is currently overflowing with half-unpacked boxes. Despite all the craziness of moving (or perhaps because of it…), I was a speaker at WordCamp Boston this past weekend, and also gave a lightning talk at the BostonRB Ruby meetup last week.

If you’ve followed our blog so far, you may have noticed we talk about both WordPress and Ruby on Rails. While it’s unusual to see a consultancy that develops in these two very different platforms, supporting both gives us the flexibility to choose the platform that best suits our clients’ needs. For applications that primarily need CMS (content management system) functionality, WordPress is a natural fit, while Rails is best suited for highly customized application development. Well known sites with a focus on content, such as The New York Times, CNN, Mashable and many others use WordPress. Twitter was originally developed on Rails, and sites such as Groupon, Bloomberg, Airbnb, and many others also use Rails.

Many consultancies will shoehorn the development of your web application into the one platform they happen to know, even if it’s not a good fit for your needs (this may not be a conscious decision on their part – if they only know one platform well, they may not have the perspective to know whether another platform might be a better choice). For example, WordPress’ Custom Post Types are great for situations where your data can be well represented in the relational database table structure on which WordPress is built, and using them can speed along the development process. But if they aren’t a good fit, then you will likely encounter poor performance when your traffic increases, or have to do custom database development work, which is a breeze in Rails but is awkward and inefficient to do in WordPress.

We also do extensive work in javascript. The ROI calculators we’ve created for Hobson & Co are written entirely in object-oriented javascript, using jQuery and HighCharts (javascript frameworks such as AngularJS or ember.js would have been overkill for this kind of project). Our latest calculator for Greenway Health is a good example.

Regardless of the platform, we take an Agile approach to our work. On the technical side, this means a relentless focus on quality, using object oriented design and test driven development (TDD). My lightning talk at the BostonRB meetup focused on an aspect of this: following the Law of Demeter in Rails application development. Check out my slides.

My WordCamp Boston talk was about the business side of the Agile development process, with a focus on how to build professional, long term partnerships with your clients. I’ve given this talk a few times now, and it’s been a lot of fun to have the opportunity to refine it and keep improving it (I also gave it at the Philadelphia Emerging Technologies for the Enterprise conference and WordCamp Nashville). The video is above, and you can check out my slides.

Here are some tweets from people at each of my talks:

The ElectNext workation in Lake Tahoe

On September 15, 2013 by Mike With 0 Comments - Agile, Personal
ElectNext team dinner in TahoeElectNext team dinner in Tahoe
ElectNext team dinner in Tahoe13-Sep-2013 11:58, Canon Canon PowerShot ELPH 110 HS, 2.7, 4.3mm, 0.05 sec, ISO 320
View at Picasa
The ElectNext team at Maggie's PeakThe ElectNext team at Maggie's Peak
The ElectNext team at Maggie's Peak14-Sep-2013 03:34, Canon Canon PowerShot ELPH 110 HS, 8.0, 4.3mm, 0.006 sec, ISO 200
View at Picasa
 
Granite Lake, along the trail to Maggie's PeakGranite Lake, along the trail to Maggie's Peak
Granite Lake, along the trail to Maggie's Peak14-Sep-2013 02:18, Canon Canon PowerShot ELPH 110 HS, 8.0, 4.3mm, 0.004 sec, ISO 200
View at Picasa
View from the top of Maggie's PeakView from the top of Maggie's Peak
View from the top of Maggie's Peak14-Sep-2013 03:15, Canon Canon PowerShot ELPH 110 HS, 8.0, 4.3mm, 0.003 sec, ISO 200
View at Picasa
 

I’ve been with ElectNext for a little over a year, and this past week was only the third time since I started that everyone in the company was in the same place, and the first time that it was for more than a day. There are currently 7 of us, roughly equally divided between New York, Philadelphia, and San Francisco. So a typical workday entails a good amount of time in Google Hangouts, which is a great tool for keeping a distributed time on the same page. But there are a couple things for which there is no substitute for spending time in person: one is building team relationships (here’s a great article on building distributed Agile teams), and the other is brainstorming around challenging problems. As good as Hangout is, and tools like RealtimeBoard, there’s still no substitute for a team putting their heads together in person around a whiteboard or big easel pad.

We rented a 4 bedroom/7 bed house on the north side of Lake Tahoe, right across the street from the lake. This was a workation, which means we put in at least as much work time as usual. But we also enjoyed our evenings and our surroundings. We each had a turn preparing dinner, and sat down most nights around 8:30 to eat, staying at the table until late into the night. And we took the day off on Friday for a hike up to one of Maggie’s Peaks.

Click the album cover below to see more great pictures!

2013 - Lake Tahoe
2013 - Lake TahoeSep 10, 2013Photos: 26
 

Knowledge Slam

On April 17, 2013 by Mike With 0 Comments - Agile, Conferences

I presented at the Philadelphia Knowledge Slam tonight on job satisfaction and Agile. It was a lot of fun! The hardest part was putting together a coherent presentation that fit within the strict 5 minute limit, with no slides allowed. There were 10 great presentations on a wide variety of topics: the songs of Robins, the latest innovations in genetic treatments for sickle cell disease, screenwriting, cultural myths and personal myths, baking, tips for networking, the mis-measuring of educational achievement, and more.

This was my first time going – Knowledge Slam is held the 3rd Wednesday of every month. Check out the Facebook page for more info.

Short clips of each presenter were recorded. Here’s mine, followed by my complete script.

About 4 years ago I read a book by Malcolm Gladwell called “Outliers: the Story of Success.” Buried in the middle of that book he wrote a few paragraphs that, for me, were the most important part of the story. He described the 3 things that make a job rewarding. The things that make you look forward to a day at work when you get up in the morning.

First is reward for effort – this means money of course, but it also means recognition. We want our boss and our co-workers to let us know we’re doing a good job.

Second is having challenging work – work that isn’t routine and boring, but isn’t so hard that it becomes frustrating. Work that’s in that sweet spot in between, where the work engages your skills and makes you feel that you are learning and growing.

So those first two are pretty straightforward. The third one is the most interesting to me: a rewarding job is one that gives you autonomy. You have a feeling of control over your work, and you feel that your actions and decisions are meaningful. You can make things happen without someone second-guessing you all the time. It’s the opposite of feeling like a cog in a machine.

This struck a chord with me because at the time I wasn’t really happy in my job. I create web sites and web applications for a living. I’ve been doing it since ancient times – the early 1990s – when the first web pages were painted on cave walls in bison blood. And I wasn’t alone in feeling this way. Job satisfaction surveys of Americans show that between half and three quarters of Americans are unhappy in their jobs. If you consider that we spend about half of our waking lives at work, that’s a depressing statistic.

So I decided it was time for a change, and I made a terrible, terrible decision – I went into management. I joined the ranks of the people who are ultimately responsible for all those unhappy workers. I figured, there must be a better way to do this. So I did my homework, and I started learning about this thing called Agile, with a capital A. It’s a way of managing work that originated in the software industry and has been spreading to other types of work. And it’s got a great name, who doesn’t want to be agile?

But I learned it’s more than just a buzzword. Learning and following Agile practices made me fall in love with my work all over again. I would need to talk for at least an hour to explain how it all works, but since I just have a few minutes, I’ll focus on the part that relates to this idea of autonomy. In a lot of workplaces, you have responsibility, and your boss has authority. You don’t have autonomy. Managers talk about being results-oriented, but most are really more focused on control. Since you don’t have autonomy, you may not be motivated to do great work, so you’re given more policies and procedures to follow. The end result is management gets work that meets a consistent but minimal level of quality, and you don’t get a whole lot of job satisfaction. The undercurrent here is a lack of trust.

So how does Agile fix this? First, it gets management’s focus where it should be: on results, not control. And it provides some new ways of measuring progress and results that don’t depend on micro-management. And second, it adjusts peoples’ roles, so you actually have authority over the things you are responsible for. It gives you autonomy. It’s really about training management to get out of the way for the day-to-day work, to foster a learning environment, and to step in only when help is needed. It means treating people like adults, and creating an environment of trust.

And when you have trust, great things can happen. People start working together and pooling their skills to solve problems. This happened recently at General Electric. They had a water heater that was made in China. Here in the US a team of engineers, factory line workers, even sales and marketing people, all got together and completely redesigned it. By pooling their skills and experience they came up with a new design that was so much less expensive to manufacture, GE moved the manufacturing for the water heater back to the US, creating jobs here, and lowered its retail price by $300.

At the end of the day, its not policies and procedures that get the credit for good work and great products, it’s enthusiastic and empowered people.

WordCamp New York City 2012

On June 17, 2012 by Mike With 0 Comments - Agile, WordPress
WordCamp NYC 2012 kickoffWordCamp NYC 2012 kickoff
WordCamp NYC 2012 kickoff09-Jun-2012 09:13, Canon Canon PowerShot SD780 IS, 3.2, 5.9mm, 0.04 sec, ISO 400
View at Picasa
 

With 12 session tracks on Saturday, followed by unconference sessions on Sunday and encore performances of Saturday’s most popular presentations, WordCamp NYC last week was by far the biggest WordCamp I’ve attended. Then of course there’s the real reason people go – the after party on Saturday (there was also the sponsors and speakers party on Friday, which was a lot of fun too). At the parties I got to do what years of social training had previously convinced me was unacceptable: discuss code while drinking beer. I got to chat for a while with @garthkoyle (from Event Espresso), @jason_coleman (of Paid Memberships Pro fame), @vidluther (from zippykid), and @tinakesova (from Siteground).

Brad Williams speaking on WordPress security at WordCamp NYCBrad Williams speaking on WordPress security at WordCamp NYC
Brad Williams speaking on WordPress security at WordCamp NYC09-Jun-2012 09:37, Canon Canon PowerShot SD780 IS, 5.8, 17.9mm, 0.05 sec, ISO 640
View at Picasa
My WordCamp NYC presentation on object oriented programming for WordPress pluginsMy WordCamp NYC presentation on object oriented programming for WordPress plugins
My WordCamp NYC presentation on object oriented programming for WordPress plugins
View at Picasa
 

My presentation was on object oriented programming for WordPress plugins (my slides are below). I decided to focus on OOP in general with PHP, as its simply a huge topic to try to cover in 30-40 minutes. The room was full and there were good questions at the end, so it went well. I was 1 of 3 presenters from WebDevStudios – Brad presented on WordPress security, and Eric on the rewrite API.

WebDevStudios WordCamp NYC dinnerWebDevStudios WordCamp NYC dinner
WebDevStudios WordCamp NYC dinner
View at Picasa
 

Brad treated us to a great dinner afterwards (ribs!) and I stayed up too late with the WebDevStudios team Saturday night (including honorary team member for a night, Captin Shmit – yes that’s how he spells it). I found out at 2AM (when I checked the conference web site after we got back to the hotel) that the unconference presentation submission I made earlier in the day had been scheduled for Sunday morning.

Whiteboard from my WordCamp NYC unconference session on Agile project managementWhiteboard from my WordCamp NYC unconference session on Agile project management
Whiteboard from my WordCamp NYC unconference session on Agile project management
View at Picasa
 

So on my way back to the conference Sunday morning I stopped at CVS to get post-it notes and dry erase markers, for doing an Agile project management workshop. Aside from scribbling some notes 20 minutes before the session started, I didn’t have a detailed plan, and it turned out to be a lot of fun. My session was right before lunch, which turned out to be great, as almost everyone stayed after the time was up, and we went for another half hour. I started the session by having everyone describe their client relationship and software development problems (in brief post-it note format) and collected those on one side of the white board. Then I had them describe the things they want to achieve in their business (also in post-it note form), and collected those on the other side of the board. Then we spent about an hour talking through how to get from one side of the board to the other. It was only enough time to scratch the surface of Agile practices, but what made the biggest impression on everyone is how almost all software development teams face the same challenges, and that there are ways to deal with them that are concrete, achievable, and rewarding. ContentRobot selected it as one of the best sessions.

To continue with the shameless self-promotion, here are some tweets about my talks:

Tweets about my WordCamp NYC presentations
Tweets about my WordCamp NYC presentations
View at Picasa
 

And here are the slides from my OOP talk (the last half of the slideshow contains my slide notes).

Object Oriented Programming for WordPress Plugin Development

View more presentations from mtoppa

If you want to see more, check out the WordCamp NYC 2012 site and ChrisDigital has a collection of links to other summaries, and slides.

WordPress plugins: does size matter? Applying the Single Responsiblity Principle

On February 7, 2012 by Mike With 2 Comments - Agile, WordPress

In the last episode of WP Late Night, there was a brief debate about plugin size. Ryan expressed a preference for smaller plugins with tightly focused functionality. It’s natural to worry that, as the number of lines of code increases, so does the likelihood of bugs, and performance slowdowns.

This concern makes sense if you’re assuming plugin code is not very well organized and not very well tested. Unfortunately, that’s a safe assumption with many plugins. As plugin authors, we should have higher standards for our work. There are two things that come to mind:

  1. Optimizing the readability and maintainability of our code. This means writing “clean code” (the subject of my Philly WordCamp presentation). It reduces the likelihood of bugs, and makes our plugins easier to enhance and adapt to changing needs. It also makes it more likely that others will contribute to the project, or learn from it, and start writing better plugins themselves. These are some one of the main attractions for participating in the WordPress open source community, right?
  2. Optimizing for performance: one aspect of the “clean code” philosophy is to not prematurely optimize code for performance, especially when our guesses about how to do that are often wrong.

    More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.

    Wulf, W. A. “A Case Against the GOTO,” Proceedings of the 25th National ACM Conference, August 1972, pp. 791-97.

The rule of thumb is to optimize for readability and maintainability first. If a performance problem comes up, it is likely stemming from a small area of the code, and you can focus your performance optimization efforts there. As one person put it: “There is far, far more money wasted on fixing and customizing and maintaining hard-to-read code than there is lost on inefficient code.”

There are many techniques involved with writing clean code. A foundational one is following the Single Responsibility Principle (SRP). Bob Martin has a very succinct definition of the SRP: “a class should have only one reason to change.” In his book Agile Software Development, he explains further:

If a class has more than one responsibility [more than one reason to change], then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the ability of the class to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

If you follow the SRP, then it doesn’t matter how big your plugin is. What matters is how you use it.

The trick, of course, is figuring out what it means to have a single responsibility. WordPress itself helps you figure this out. When you call a WordPress hook or filter, it’s likely that you will want to create a class that implements what you intend to do for that hook or filter call. For example, if you call add_shortcode, then you should have it instantiate a class that implements your shortcode. If that class needs to change, it will be only because your needs for the shortcode have changed. The shortcode logic is not tightly coupled to other parts of the code. Removing that coupling is an important step towards also removing that sinking feeling of fear when you start monkeying with the innards of some gigantic application.

Not every hook and filter call deserves its own class. Some are merely stepping stones to others and do not need their own class. For example, if you call admin_menu simply for the sake of calling add_options_page, one class is enough. Others may need more than one class to support them. But for getting your feet wet, having a class per hook or filter is a good place to start.

My Post to Post Links II error: No post found with slug "shashin-wordpress-plugin" has a total of 55 classes and subclasses (you can see the code on GitHub). How can you find what you’re looking for in all those classes? It sounds horribly bloated for a WordPress plugin, right? It’s actually the opposite.

A coding habit that goes hand in hand with the SRP is the use of meaningful names. Each class in Shashin serves a specific purpose, and has a name that tells me what it does. If I need to make a change to the settings, I go to the Settings class; if I need to make a change to how album synchronizing is done with Picasa, I go to the PicasaSynchronizer class, etc. The majority of the classes are less than a couple hundred lines. With small, well-named classes and methods with clear purposes, when there is a bug, it’s usually not hard to find. And if I need to change something, I can make that change in one place with a greatly reduced fear of breaking something unrelated.

By using a class autoloader, such as Post to Post Links II error: No post found with slug "toppa-plugin-libraries-for-wordpress", you can also save yourself the trouble of figuring out where to put require_once statements, for loading your class files. With an autoloader, a class file is loaded only when “new” is called (so if you are worrying about performance with so many objects, they are only loaded when they are actually needed). How you keep track of object dependencies, and when and how you instantiate your classes, are what I’ll write about in my next post, which will cover using an injection container.

My last day at Penn, my first day at WebdevStudios

On January 9, 2012 by Mike With 0 Comments - Agile, Personal, WordPress

This past summer I started attending the Philly WordPress meetups, which led to an opportunity for me to speak at Philly WordCamp, which led to an amazing opportunity to work at WebDevStudios, with an amazing team. Today – Monday – was my first day on the job. I’m doing custom development work and soon I’ll get involved with project management. I’m starting with some enhancements to Baja.com. Friday was my last day at Penn, so my head is spinning a bit from the transition.

I’ve been part of the web team in Penn’s School of Medicine since 2004, and I’ve been Director for the past 2 years. My team had a lot of demands placed on them, with the need for projects outpacing what we could provide. One of the first things I did as Director was learn Agile practices so I could teach them to my team (and I brought in a scrum coach to help). These two graphics illustrate the two primary challenges we faced – not enough staff, and too much chaos:

Blue represents available SOMIS staff, red indicates how many people would be needed to complete the desired workBlue represents available SOMIS staff, red indicates how many people would be needed to complete the desired work
Blue represents available SOMIS staff, red indicates how many people would be needed to complete the desired work
View at Picasa
Illustration by Esther Derby showing a not very well functioning development processIllustration by Esther Derby showing a not very well functioning development process
Illustration by Esther Derby showing a not very well functioning development process
View at Picasa
 

For many months my work spilled over into nights and weekends as I tried to move things forward. I can’t say we entirely solved these problems, but we made a lot of progress, and got the wheels turning in higher levels of administration to address the situation (“turning the aircraft carrier,” as one of our project managers put it – change is not easy to implement in a huge institution). Deciding to leave was hard, but an opportunity to turn my WordPress plugin development hobby into a job, to work with Brad (@williamsba) and the WebDevStudios team, and having the flexibility of working at home… it was too good to pass up. I’m especially looking forward to having more time to code again. If the past 2 years have taught me anything, it’s that I have a passion for software development, and always striving to do it better.

Dependency Injection in PHP

On August 14, 2011 by Mike With 0 Comments - Agile

Last week I gave a presentation to my team on dependency inversion and dependency injection in PHP. Dependency inversion is the “D” in the the SOLID object oriented design principles, and dependency injection is a design pattern for implementing it.

We previously learned the single responsibility principle (PDF) (the “S” in SOLID). To me, dependency inversion is the next logical topic. Single responsibility is about how to write objects that do one thing; dependency inversion is about how you wire those objects together into robust, working software.

This was a fun presentation, and I think the slides work well even without my narration. Several of the code examples are from Post to Post Links II error: No post found with slug "shashin-3-development-progress", where I’m applying the principles. I’m still learning how to best apply them, so feedback in the comments section is welcome.

Dependency Inversion and Dependency Injection in PHP

View more presentations from mtoppa