Phone
+447526 265819
Email me
michele.fadda@fwlab.com
Location
Somewhere in London, usually
Software development myths
If someone tells you that making good software is easy, or that everybody could do it, or makes it look like it is easy, it is likely a salesman speaking.
Aiming at good, and I mean really good is actually very hard.
Making it right is not more expensive than making it wrong, provided you take the right decisions early on.
in software, tiny details matter, and they are not necessarily the details you see, the shiny graphics and presentations that matter.
Agile.
Self proclaimed experts are a dime a dozen.
"Agile" means very little by itself.
Actually, Agile does not mean that you should blindly follow the methodology and expect it to work.
Agile needs to be customised to the organisation and is not a panacea.
It is not a cure all approach, and as all methodologies, or tools, is best handled when critical thinking and an open culture is in place.
For instance, if you have a limited budget and timescale, you can't be completely "Agile", you will however benefit from having Agile ceremonies.
Agile alone is not enough, as a strictly non-technical scrum process can determine crippling technical debt. You can't be agile and just ignore the technical management of a project.
Methodologies don't really matter, or, to be more precise, they matter a lot less than the experience and competence of the developers involved in a project:
A competent developer would probably manage to reach successful project completion no matter what the software development process is.
An incompetent agile developer, would not reach a successful outcome, no matter what methodology is in place.Michele Fadda
Sharing knowledge and growing together.
I've been around developing software for about three decades, in so many different organisations that I've practically become a sort of corporate anthropologist.
Good teams are more than the sum of their individual parts. Bad teams are just the opposite: politics, personal agendas and egos drive to inferior achievement.
The least creative teams are those characterised by strong cohesion and conformity: if all contributors are all alike, come from the same culture, have the same age, you can expect stagnation.
Chiefs tend to be opinionated about their tools
A good chief typically uses many different knives, and be quite passionate about their different uses. Good software development is not different, and is more akin to craftsmanship and art than actual engineering.
The right tools do make a difference Thus not all programming languages are the same
Some programming languages are more expressive, or are more suited than others for a particular task. Some are very fast, but it isn't at all easy writing safe code with them.
Some programming languages have implementations which might be less secure and leave your system more amenable to attack or reverse engineering. Or their license might not be as free as you think, leaving you exposed to higher costs in the long run.
You should base the technology choices on the problem at hand, and on your organisational environment, not on preconceived prejudices.
You probably shouldn't be using Java in a startup, because cheaper, more effective alternatives exist within that organisational environment.
Choosing the appropriate tools for a task is a strategic decision: it will affect you and your organisation for many years to come, and each tiny advantage a software tool could offer you (or remove from the table) will add up in the long term.
If all you know is python Django, and use it because "authentication in Django" is really easy, probably the system you are going to design is not going to be super-secure, if an additional level of security is required, e.g.: storing confidential sensitive information about your users.
The very worst decision is using just what you know, and never look at alternatives because of your own personal history.
Another terrible decision is going with the flock, following a fashion, just because everyone else is doing the same thing.
By definition, if you do precisely what everyone else is doing, you are removing any chances at getting any strategic advantage from your implementation.
However, no matter what you choose, it has to be compatible with the culture of the developers, but up to a point.
If you think this is a fixed constraint, then no evolution will occur in the field, and we will often find this argument used to justify laggards, late adopters, who often praise themselves as being "innovators".
Take everything with a grain of salt.
Absolute perfection does not exist, but there are different degrees of difficulty.
No chef wants to cut sushi with a blunt knife.
Today maybe I would not advocate using Rust in a corporate back-end.
But I know first hand that Go has earned its place in this domain.
An iOS developer’s guide to SwiftUI
Get started with SwiftUI and accelerate your iOS app development with this guide to leveraging the declarative approach, with key images printed in color.
Key Features
Learn how to structure and maintain clean app architecture
Integrate SwiftUI with relevant frameworks to create professional and responsive apps
Understand the declarative functional approach and focus on asynchronous programming within the context of SwiftUI
Purchase of the print or Kindle book includes a free PDF eBookaudience in public.
What You’ll Learn:
Master SwiftUI: Deep dive into UI coding across all Apple platforms.
Advanced App Development: Master complex architectures and asynchronous programming.
Interactive Design: Utilize animations, graphics, and user gestures for responsive UIs.
Modern Data Handling: Employ contemporary methods for data storage and sharing.
Seamless Integration: Combine SwiftUI and UIKit to boost your app capabilities.
Cross-Platform Development: Extend your applications to macOS, iOS, tvOS, and more.
This book is for iOS developers interested in mastering SwiftUI, software developers with extensive iOS development experience using UIkit transitioning to SwiftUI, as well as mobile consultants and engineers who want to gain an in-depth understanding of the framework. Newcomers equipped with knowledge of Swift, UIkit, XCode, and asynchronous programming will find this book invaluable for launching a career in mobile software development with iOS.
Table of Contents
Exploring the Environment – Xcode, Playgrounds, and SwiftUI
Adding Basic UI Elements and Designing Layouts
Adding Interactivity to a SwiftUI View
Iterating Views, Scroll Views, FocusState, Lists, and Scroll View Reader
The Art of Displaying Grids
Tab Bars and Modal View Presentation
All About Navigation
Creating Custom Graphics
An Introduction to Animations in SwiftUI
App Architecture and SwiftUI Part I: the Practical Tools
App Architecture and SwiftUI Part II – the Theory
Persistence with Core Data
Modern Structured Concurrency
An Introduction to SwiftData
Consuming REST Services in SwiftUI
Exploring the Apple Vision Pro
is People
It might be surprising for some managers that the human factors, team dynamics and interactions make software project development difficult.
You might be wasting a large part of your resources or be getting inferior results.
Maybe you thought you could randomly put together teams based on the technical knowledge of their members and hope for the best.
Or your company might even be paying some consultant who promised to deliver "better, more cohesive teams", only to discover that no innovations and creativity are coming out of those teams.
You might be aware that results are not what you expected, project completion takes wildly longer than you could afford, and you know you are wasting money and resources. You are not alone.
This blog is about those pesky human factors and culture in technological organisations.
It also addresses my thoughts on software and software architecture.
Email me
michele.fadda@fwlab.com
Location
Somewhere in London (Usually)
Phone
+44-(0)7526-265819
Suggestion: Message me on LinkedIn.