January 20, 2019
This is the advice I wish I’d had when I was starting out as a freelance developer. Once you’ve gotten a client and sealed the deal, where do you begin?
Seriously, write them down. Share them with the client, get approval.
If something isn’t clear, now is your chance to get it cleared up.
Requirements will change. Plan accordingly.
However, don’t try to refine Requirements perfectly.
Which brings us to our first point:
Whatever you do, don’t disappear for 3 months with a plan to be “done” by then. Software projects are fundamentally complex so get feedback as frequently as possible.
If possible, invest some time in learning the basics of Scrum and use that as a feedback framework. The terminology can get a little confusing, but the basic idea is simple:
define a fixed time-period to show the product to the client and get feedback.
There are definitely other Agile Methodologies out there,
Maybe not every cycle, maybe every couple of cycles
When I first started I definitely underestimated the devOps side of things. In my mind the thing worked, there was no need to mess around with deployment till we were ready for customers.
What ended up happening was that I became a bottleneck and that, coupled with the fact that I didn’t setup regular feedback sessions, meant that the Product was out of the market for way longer than it needed to be.
That doesn’t have to be you, deploy to Production in Sprint 1 itself. This has two benefits:
It lowers the cost of feedback
You’ll get customers much sooner because they’ll be able to use it as well
I’ve become somewhat obsessed with this after being burned by not following this advice. Especially if it’s a web-app, there’s no excuse to not have the app hosted somewhere as soon as humanly possible.
Not all the tests, not 100% coverage, but definitely for critical paths and TDD as much as possible. It’s easy in the beginning, and the cost of introducing it gets harder and harder as time passes.
Write tests, future you will thank you for it.
For Details refer: Write Tests, Not Too Many, Mostly Integration
This is one I still struggle with even to this day. If you’re even a little imaginative it’s easy to get carried away. You think you know everything, and that you’d be able to fix everything if only you had the reins. If that’s true, you should just start your own thing, freelancing might not be for you.
However, if you’re in a team, and you’re working with professionals then they’re relying on you; so you should rely on them and let them do their jobs.
Be practical, finish your stuff first; it’ll probably take you longer than you think. Use your judgement.
This subject is vast, and each situation is different but hopefully these basics help set up a self-adjusting, adaptive structure for your app to live in.
For more specific recommendations I’d highly recommend the 12-Factor App as a starting point.
Good luck out there. :)
Cover Photo by rawpixel
Written by Joel Louzado who lives and works in Mumbai, India building fun things. Say hi on Twitter