Whether it’s The Cloud, Mobile Development, HTML5, iOS, Android, Windows Phone, Search, Big Data, Queuing or more, we know there’s a wealth of possibility of what we can do. But we then seem to combine that with a misplaced, seemingly schizophrenic, need to be able to do it all and then not ship it until it’s perfect Today we discuss the Ship-It! attitude
In computer software - it means to publish / distribute the application in its current state. Often used humurously when the software is buggy and clearly not ready to publish.
What is it about being a software developer that turns us in to perfectionists? Now that’s a bit of a generalisation, to be fair, but from common experience, we are.
We have grand ideas, even delusions, about what we can and will produce and by when. We hear about new technologies, techniques, vendors, ideas, concepts and practices, daily, if not hourly - or so it would seem.
Whether it’s The Cloud, Mobile Development, HTML5, iOS, Android, Windows Phone, Search, Big Data, Queuing or more, we know there’s a wealth of possibility of what we can do. But we then seem to combine that with a misplaced, seemingly schizophrenic, need to be able to do it all and then not ship it until it’s “perfect” - whatever that means.
Business managers, team leaders, business analysts, et al, come to us and ask for it to be done yesterday and we feel that we can’t, in good faith do that. We feel that to do it within the deadlines that they set for us we’ll be delivering a product that is less than ideal, less than worthy, less than shippable.
Have we stopped to ask ourselves why we may be, truly, reluctant to put our names to something we consider imperfect? I was having a discussion with a few developer friends recently about this, as I know that I am guilty as charged, of this disease if you will.
We threw around a lot of potential ideas, but one thing came up again and again and again - peer criticism, of the negative kind. We all felt that there’s a rather precocious concern about being seen as less than worthy in the eyes of our peers. We seem to be concerned that we can’t live up to an ideal not clearly defined.
We seem to feel that we have to have everything in there that we possibly could. It seems to be the case that before we can ship software, with our name on it, we have to have all the patterns, proper architecture, scaling and redundancy required.
We seem to live in a world where every application will be required to sustain traffic on par with LinkedIn, Facebook or Google. But how many of these sites really exist, out of the millions of sites and applications, that are already available and becoming available each and every day?
In all honesty, our applications don’t need to be this way and will never get to this level if we expect them to be perfect, first time. Cast your mind back to any skill that you’ve learned, such as walking, riding a bike, skiing, snow boarding, kite surfing, learning a foreign language or more.
You tried, fell down, dusted yourself off, tried again, learned some more, fell over again and the process repeated, ad nausea, as you gradually got better and learned to master your new skill.
Why should it be any different with software development? I’d venture that it’s not and is not logical to consider that it would be. I encourage you to not expect that this skill of software development, which is a skill like any other, should be.
A good friend and developer colleague said the following once, when I asked him what it takes to be a great developer and write great applications:
Write a hell of a lot of bad ones and learn, from each one, why they were bad
I’m not encouraging you to ship junk, far from it. But don’t get too hung up on perfection. Set your deadlines and milestones, do your best, but then keep shipping your code so that you get the feedback that you need to keep making it better - feedback from real world users.
This is where you really know what is good and what needs work. So get out there and keep coding, but don’t be too precious about it. Just Ship It!. Listen to what they have to say, review your work honestly and carefully, then get back in there and develop and ship the next release and keep going until you become the developer you know, in your gut, that you are and can be.
Do you suffer from this? Do you expect perfection or have worked with someone who does? Tell us in the comments.
Image credit coming shortly
To master the Zend Framework 2 we need to understand its core concepts. In this series, we work through four of the core ones, starting with Dependency Injection. Join me today to get started learning all about DI.
What is a Professional PHP Freelancer? It’s a tough question, but deserves asking. Today we have a series of questions to help you determine if you are.
Here we are at part three of the beginning cloud development with cloudControl series and in this part, we’re adding mongoDB support. In part one of the series, we laid the foundation for the application and got up to speed with what cloudControl is, why it works and how to get started using it.
Then in part two, we started to flesh out the application that we started building in part one and added MySQL support to it. We showed how to work with cloudControl to manage the key requirements, such as enabling MySQL support, connecting to the MySQL database and keeping the database up to date from a maintenance perspective (creating the database schema and loading data in to the database).
In this, the third part of the series, we’re replacing MySQL that we introduced in part two with mongoDB support.
Please consider buying me a coffee. It really helps me to keep producing new tutorials.
Join the discussion
comments powered by Disqus