5

I started working as a software engineer with a startup about one and a half year ago. Everyone here cares about this project and works hard. but I have been having an issue here for some time.

People here have "lack of discipline" when it comes to development tasks. They ask for one functionality, I ask a thousand questions so that I am clear on the requirements of the functionality. As I don't ever like to miss a single scenario when collecting requirements. and I do my work with all my heart and brain in it.

Later on the day of the demo, they would say: let's change this to that and that to this. 5 demos later, trying to fit in their changed requirements and flow, I end up with a mess of code that works the way they want.

Now, because the flow is totally changed, it's not even the same function that I started with, there's delay in launch, there are bugs in production and marketing people are screaming about it. I always end up in some mess. and I am tired of it.

I can't fix the issue with these people, I can only try to fix myself, I believe that issues come when they make me work on the same thing again and again and I get demotivated to work and I procrastinate.

I like this project, I really want to stay here for a bit longer and I want to give my best even if I am working on something for the 5th time.

Any advice on keeping the productivity level high in these scenarios? How do I make sure that I don't miss anything while changing the functions? and what do I do when I feel stuck.

p.s. ATM I am making changes in the flow of a user portal that I actually finished flawlessly last week. and now I am stuck, I don't feel like doing it. and I can't even think how to fix these issues.

  • Are you, or the startup, following a methodology, such as some flavor of agile, waterfall, or some combination? Also, is your demo based on finishing the task or verifying requirements? Basically, is this actually a wire frame? Are there any unit tests or any type of acceptance/integration tests? – eparham7861 Jul 30 '18 at 14:26
  • 1
    if everything changes so quickly it might be that you are “drafting” a product / service rather than actually build it: can you not ask your management to use prototyping tools? – Edoardo Jul 30 '18 at 14:59
  • 5
    Later on the day of the demo, they would say: let's change this to that and that to this. -- This is exactly how iterative development works. Iterative development works better than big design up front for many development scenarios. Perhaps your personal development process could use a bit of adaptability? – Robert Harvey Jul 30 '18 at 15:01
  • 1
  • 1
    @eparham7861 no we are not following any methodology. people just come up with new ideas, dump them on IT to implement, never settle on requirements (even after its gone in production) and keep pressuring for completion. – Saira Jul 30 '18 at 20:34
18

The idea that requirements are fixed and that the code you are writing will not have to be changed is extremely problematic. In reality, requirements are never fixed. Whether you need to change it prior to the initial release or not, at some point in the future, your code is very likely going to need to change. When that ceases to be true, it's because the code base is abandoned.

In your situation, you've identified that 1. your initial requirements are not what you will eventually deliver and 2. that you can't affect any change to that reality.

All of this points to one thing: you need to optimize your development strategy around the ability to change. A lot of software practices you will read about here are either about the ability to understand code later, the ease of modification, or both.

The first thing I would suggest is that you stop attempting to build a fully complete polished system before showing it to your product owners. Instead build functioning prototypes and get them in front of the decision makers early. Take their feedback, implement them and make things a little more finished. Show it to them again. Rinse and repeat. Eventually, you should get to a point where they start saying everything is OK except for the details. That's when you start finishing things off.

The other thing that stands out is that when you are making these changes, you are hacking them in. You should be following the same standards for your code whether it's a last minute change or if your code isn't due for 6 weeks. Yes, it's inevitable that you might need to tweak something at the last minute and clean it up later every once in a while but doing this as part of your regular release is very damaging to the code base. The more poorly written code you put in, the harder it will be to adapt to the stream of changes. Getting it in front of people early will help with this since you will have more time to make the changes appropriately.

The last thing I will recommend is a couple of specific development practices that can be very help in this kind of situation:

  1. Modular code: If nothing else, make sure you are breaking code down into short readable methods with a single responsibility and meaningful name.
  2. Unit tests: What's often misunderstood about unit tests is that they have relatively little value in determining whether your code meets requirements. Where they shine is when you are modifying code. They give an instant feedback when you have broken something. Keep them up to date and modify the tests that you need to change first before implementing the change.
  • 1
    I'd go even further and say the first step should be a wireframe, either using a tool or just by putting together some static HTML pages. I've found that actually having something that lets you click thru the interface really catches UI problems right at the start of the process. – DaveG Jul 30 '18 at 16:48
  • @jimmyJames thank you for your answer. I will try from next time to keep them involved during development and have demos before finishing the whole thing. We have no proper process in place for this kind of situations or even for testing and I will also try to talk to the head of IT regarding this. – Saira Jul 30 '18 at 20:29
  • 1
    Sometimes this kind of thing is referred to as a "walking skeleton" or similar terminology. Here's an article that popped up on a search that seems to give a good general overview of the idea. The big downside I should mention is that sometimes the product owners may look at this and say it's good enough as is. That might actually be the case but they don't know if it's all duct-tape and paper clips underneath. You may need the support of your management to hold the line on quality. – JimmyJames Jul 30 '18 at 20:35
2

JimmyJames answer covers many of the aspects well. I just wanted to add a few more points:

Reduce development time

Make sure you're writing as little code as possible. In particular, you want to make sure you only have to change code in one place (DRY) and aren't adding bells and whistles too early (YAGNI).

If you find you are making changes to the same code over and over and the structure is suffering, then by all means refactor to stop the software entropying further.

Increase accountability

Ensure all changes are documented. You'd be amazed how many requirements disappear when there is a paper trail!

Make sure all changes are verifiable. Wishes such as "that should look snazzier" and "that form could do with tidying up" are time drains. Ensure changes can be proved.

Finally, if development is time boxed to say, a sprint then there will be less temptation for endless tinkering.


As a final takeaway, making peace with the fact that software often changes (for many reasons) will stand you in good stead going forwards.

2

Reading your story, one thing stands out for me. Your attitude is very reactive/responsive/following. You expect your stakeholders to have a vision and give you smart, future proof tasks. The problem of course is they are not that smart or foreseeing. They just have some wild ideas and they only find out what is wrong with those ideas when you show them what they asked for.

So instead of pinning them down on what they asked for and mindlessly producing that, you should iteratively brainstorm with them until you all get a picture of what you want to be aiming for. Then you can take the first step to that (far) goal.

Your (and I mean "your" in a plural sense) frame is far too small now. You obviously want to go far but you do not know in what direction yet. Think a little bigger. Rather than taking an impulsive step into a random direction, try to think at least a couple of steps ahead and make sure you know where you (ideally) want to end up. Helping your stakeholders develop a vision can make your life easier and your job more rewarding.

  • 1
    Much as I like this answer it does seems a little bit "blue sky". While this should be a collaborative process, there are stakeholders who would much rather the developer do all the leg work rather than take the time to flesh out the process themselves as the subject matter experts. This is a common problem for internal developments where development time and/or cost aren't sufficiently constrained. – Robbie Dee Aug 1 '18 at 9:28
-2

Realise that you are not being paid to create 'good' software.

You are being paid to complete feature requests as fast as possible with zero defects.

This is achievable, you can be good at doing this and take pride in it. The business accepts technical debt.

  • Write loads of tests so you can be sure of the zero defects.
  • Get sign off on specs and change requests so you don't get blamed for writing the wrong thing.
  • Get your CI process in place so you don't have to do any infrastructure/deployment tasks.
  • 3
    How depressing is that first paragraph. – Robert Harvey Jul 30 '18 at 15:03
  • shrug you might also be paid to suggest good features at meetings. – Ewan Jul 30 '18 at 15:04
  • 3
    Two comments: 1. It is unlikely that "the business accepts technical debt". They are either not aware of it or assume that you or some other developer will pay it back later by working unpaid overtime. 2. Writing (and maintaining) useful tests takes a lot of time. Therefore it is even more unlikely in your case that the business will pay you to write them. – Frank Puffer Jul 30 '18 at 16:43
  • @Frank tests actually speed up development – Ewan Jul 30 '18 at 16:46
  • 1
    @Ewan tests actually speed up development - I haven't met anyone who believes that - not even the most ardent of TDD advocates. While it is patently true that it delivers a ton of other benefits, it delays the initial development of a feature measurably IMHO - YMMV... – Robbie Dee Jul 31 '18 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.