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.

JimmyJames
  • 24,682
  • 2
  • 50
  • 92
Saira
  • 63
  • 4
  • 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
    https://workplace.stackexchange.com/q/116519 – Robert Harvey Jul 30 '18 at 19:22
  • 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
  • @eddyce well there's never time to go for prototypes. everything is always urgent and people don't seem to care much about it. I personally find it difficult to deal with these situations and things that mess up with my productivity and cerativity. I find writing code fun but they always manage to make it a mess for me. – Saira Jul 30 '18 at 20:39
  • @RobertHarvey "Perhaps your personal development process could use a bit of adaptability" can you please elaborate this point for me? – Saira Jul 30 '18 at 20:41
  • The main reason for the methodology was to see if you could leverage some delivery schedule that can be defined with or without a methodology, and some other processes that help with scope creep that you are clearly having. As far as moving forward, it will be tedious, but testing has the potential to get you in a pattern of coding consistently. I would start looking at acceptance testing frameworks since you have "finished" work items with no tests. You can at least get a high level of reassurance of not breaking the product(s). – eparham7861 Jul 30 '18 at 20:50
  • welcome to the real world. Get used to it, that's just how it goes, there will ALWAYS be scope creep. – jwenting Jul 31 '18 at 05:35
  • @Saira there is always time to go for a prototype, a stub function or a sketch: i had people change prerequisites in front of me just after showing them an html view of what we were about to start coding: don’t give in, try to be involved in the decision, be critical, don’t just be a code monkey – Edoardo Jul 31 '18 at 11:13

4 Answers4

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.
JimmyJames
  • 24,682
  • 2
  • 50
  • 92
  • 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](https://gojko.net/2014/06/09/forget-the-walking-skeleton-put-it-on-crutches/) 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.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
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.

Martin Maat
  • 18,218
  • 3
  • 30
  • 57
  • 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 01 '18 at 09: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.
Ewan
  • 70,664
  • 5
  • 76
  • 161
  • 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
  • @Ewan: In the long term, assuming a certain degree of stability in requirements, assuming that the developers know how testing works, yes, for sure. But I have the impression that this is not the situation the OP is in. – Frank Puffer Jul 30 '18 at 19:26
  • @frank, no. in the short term, any requirements. tests speed up dev. – Ewan Jul 30 '18 at 19:27
  • @Ewan thank you for your answer. its just that I love doing what I do. and I want to do it the best way possible. i am not stuck with this job, i have other offers but i choose to stay here because i believe in the project and i believe it's gonna be a huge thing soon. That is why i want to create good software, no matter what i am getting paid for. and yes i do get your point but I just have to do my best. – Saira Jul 30 '18 at 20: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
  • @robbiedee well now you have. I'll see if I can dig out the studies for you – Ewan Jul 31 '18 at 13:35
  • @Ewan I don't doubt the stats are out there but *lies, damn lies and statistics*. 9 times out of 10, the complaint is usually to do with achieving some arbitrary code coverage figure which has little to do with whether the CUT works given the expected data. – Robbie Dee Jul 31 '18 at 13:47
  • @RobbieDee think about it this way. Everyone tests, the only question is whether you do it or your customer does. The performance measure is time to zero defect released code. As soon as you add manual testing in there that time skyrockets – Ewan Jul 31 '18 at 13:52
  • Zero defects is a laudable aim, but the simple fact is a lot of sw just has to deliver immediate value (ref: [Five Worlds](https://www.joelonsoftware.com/2002/05/06/five-worlds/)). If the end game *was* zero defects then this would of course make the question of unit tests making development faster moot. But in the real world, a certain defect rate is acceptable for many industries if sw can be delivered within a certain time window - especially for market edge. Way before unit tests were in vogue, there was something called formal testing. Sadly, it was (and still is) very expensive. – Robbie Dee Jul 31 '18 at 13:58
  • @RobbieDee we really start getting into the definition of 'defect' at that point. lets assume some arbitrary floating 'zero' line which is acceptable. It doesn't change anything, you still need to test to know whether you've hit it and you wont hit it first time unless you've written automated tests as you go. – Ewan Jul 31 '18 at 14:01
  • @Ewan Well yes, and the definition of "done". I'm sure we're all used to sprint pressures where we've been asked to throw something over the wall to testers while there are still known issues. – Robbie Dee Jul 31 '18 at 14:18
  • @Ewan that some professional pride right there... realize, you a code monkey, deal with it ; ) – Omar Gonzalez Jul 31 '18 at 14:55
  • @OmarGonzalez you could go the rockstar programmer route and just start saying no and programming your own features, but I think that makes you more stressed than happy – Ewan Jul 31 '18 at 15:01