Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Build e-2-e first (horizontal) instead of vertical (topdown or bottomup).
It's much easier to build on success. If you implement just enough of the process it gives you quick business and technical feedback (especially as it matures) thats invaluable to maintaining focus and developer satisfaction.
How to find what to pick first: Try to summarise the buisness' new feature request in a short sentence and keep simplifying it until you have the crux of it. Then start with that
^ sources: life experience and knowledge from Working Effectively with Legacy Code + The Pragmatic Programmer -
The sad reality is: most agile projects take longer than imagined and it might be inevitable. Even though you plan for an MVP and then end up spending days perfecting features that weren’t in the original mvp plan… maybe that was the best possible outcome.
maybe the MVP was not necessary to ship - just a way to get yo to think about the details. And if you had done the project in a more planned way it’s likely you wouldn’t have caught these details beforehand anyways
So how do you find motivation to finish a work project which is supposed to "go long"?
So, umm, this is weird, but i have been in this situation a few times and i am not sure if i deal with them correctly.
- the company proposes a brand new feature : a feature which never existed in the product before.
- they have high level directions (both business logics and technical) on how its supposed to be build
-they set vague but comfortable timelines (20-30days) to complete it
- they align me as the main dev for frontend, some x guy for backend , some y guy for parallel frontend (ios/web) and kinda forget about us.
- the business requirements are evolved/cleared as we go on making the product, the backend keeps on providing evolving apis which get stable over time.
- the business ppl shows that yeah there is no pressure and we won't mind extending this for release as other systems will be "obviously" taking time.
- our (the folks on new feature) feature is sidelined .nd we are rarely talked about until we reach those deadlines and at that time we are questioned.
I... am not a powerful performer in these situations. adding a new feature required solving some major problems again and again , while solving smaller problems too, so as the product finally takes shape . for eg:
1. i will start fast by adding all the possible screens, their abstract code, their navigation logic, their xmls etc
2. then based on designs, i will try creating designs a bit
3. then once the apis arrive, i start adding them and modify the logic to handle those.
4. meanwhile many smaller problems come up , like when sending an image from one screen to the previous screen, the thumbnail don't show up, so i spend 5+ hours ensuring that it works precisely . or how i could make 3 api calls in async and make the upload flow better.
5. this goes on for days, until and i and other people start to realise that my project is not upto the point of completion
i keep getting distracted from the original goal of making a working poc first and then fixing the nuances
rant