Are you worried about your development teams not being "agile" enough? I wouldn't tell you to think that it may be related to technical debt.
Did you know that the cost of managing Technical Debt in large organisations is estimated to be, on average, 25%, of the whole development time?
What could you do with 25% more budget?
Seven years ago, I was working in Portugal, my home country.
Besides my primary employer, I was also helping local software companies to develop software faster and better. But, something in my personal life changed, and I moved to Amsterdam.
I thought about what to do with all the material produced, in the last three years, for the training and coaching sessions. Luckily I did everything in my best English, and I thought I might licence it under a CC license. Did it and forgot it until last year.
I created a google group when I left Portugal in 2012 because I wanted people to benefit from the sweat I put doing those slides. Only 39 joined, and they had no questions. I did not engage with them, and my focus was somewhere else.
But the interesting thing happened around two years ago.
A student from Warsaw, Poland, contacted me one day with questions about the content I published. I find out he was a Computer Science student, and this material was being used to teach Object-Oriented design to classes in Warsaw. I was ecstatic and happy it helped, potentially, so many future developers.
I want to share this material with you on this blog, and, while editing the slides to post in this blog, I came across the following bullet point (This is from where this post title came from):
Only add new interfaces if users really require it (Being agile, remember)
I don't know if you think good practices and a good understanding of Object-Oriented concepts contributes to and healthier agile project. If your software is developed with Object-Oriented languages, such as Java, C++, C#, Go, Ruby, etc..., then I think you might think it is.
Is like, when people learn that one should program to interfaces, they tend to leave an interface for almost every class they produce.
But Why?
Java developers, for example, connect with ease this recommendation with the keyword "interface", then because of that easy connection, they tend to add more Java interfaces to the code base...
If a developer thinks a bit more abstractly, one may realise that "interface", in it's most abstract form, is just a way to interact with something.
What does it mean to code to interfaces then?
Means that a developer might want to separate interfaces from implementations. Not that for every class, there should have an interface.
The point is, I see too many times programmers adding technical debt to the codebase because of misunderstanding some concepts and recommendations. Ignoring good practices and underlying principles create waste in the code base, which is something not healthy for your "agile".
Excellent object-oriented programming, with good software development practices, is healthy for maintaining a good codebase in any agile organisation that produces software.
There's power mastering the basics, and the following slides helped developers to learn the basics and code well in Object-Oriented languages, such as Java, C++, C#, Go, Ruby, etc..
Please, share them with your teams and Help them to start with the right foot in Object-Oriented programming.
What will your team learn from these slides?
- Why we need objects
- How to design good code
- Knowing the differences between interface and implementation
- Thinking abstractly
- The principle of the smallest interface
- Object-Oriented concepts
- Encapsulation and Data Hiding
- Inheritance
- Polymorphism
- Composition
You might want to download the slides and customise them to your teams' needs.
Thank you.
Can I send you all the training material to your email?
Good software developers keep their cognitive muscles sharp by life-long learning.
Why not use all my material and customise it to your software development teams training programs?
If you give me your best email, here's what I will send you to your email:
- A link to a shared Google Drive folder with all the material in editable format
- A link to a zip file with all the material in editable format
The editable training material has the following templates:
Why do I want your email?
You're probably involved somehow with software development, and you care about the skills and competences of your development teams.
That's why I think it might be a good idea to have an informal chat about what your pain points might be and see if I can help.
My name is Joao Pereira, director and principal engineer at Yule Technologies, LTD.
I build software commercially for more than 18 years, and while working in a myriad of roles in multiple projects across different industries, I learned a bit about this industry.
I'll build your ideas. I'm very hands-on and code a lot, mainly in Java and distributed systems. I'm formally certified and have experience in Agile Methodologies and more waterfall' ish ones, like PMP from the Project Management Institute and have led multiple development teams during my career.
Will you let me send you all training material and get in touch?
Thank you.
Joao Pereira
Developing software commercially for more than 18 years, in a myriad of roles in multiple projects across different industries, I learned a bit about this industry. There's nothing we can't do because there's nothing we can't learn. Teams over technology and process.
Share this