diffchat

We've always worked on ways to increase developer productivity and reduce development time. With faster changes in tech and business requirements, this trend is gaining momentum.

A product is useful only when it's used by the real world users. The more we keep the features we develop away from them, the less relevant it could become over time. I would say relevance and economics are two main reasons to aim for faster development and delivery.

our world changed a lot over the last decades. We are on a constant change every day. Before, things were more slow paced, so we didn't have to adjust so quickly, now if we don't adjust on time, there is a chance that what we do is not relevant anymore.

in a nutshell - we need more software in general and we have less engineers to do it. Anything that speeds up the development and delivery process is critical for progress, and #AI has a lot offer in terms of augmenting a developers day to day. #diffchat.

I would add, it is not just fast development, it should be sustainable fast development.

The cost pressures from commercial targets (& to continuously improve services) pushes developers to speed up software testing. #UnitTesting

@venkat4diffchat, in your opinion, what is it that makes development sustainable?

@venkat4diffchat absolutely! I think sustainability is where the role of #UnitTesting is at it's prime.

I agree, the trick here is to find a good balance between development, quality and delivery.

I agree. Not just faster development, but sustainable development.

increasing expectations by users and continual SaaS delivery are also contributing to this trend

I wonder, in everyones' observation, how often developers create "whack-a-mole" software.

@venkat4diffchat Great question! I wonder if @royletron has a view on this.

Would anyone here like to share an instance when they think they were rushed into delivering their code?

@eMalaGupta how much time we have Mala :)

less than an hour. probably not enough to list them all :)

@venkat4diffchat I remember times when I had to fight for quality when there was immense perceived pressure to deliver yesterday.

@venkat4diffchat we can get started :-)

@venkat4diffchat https://www.crowdchat.net/s/35tpo

@venkat4diffchat I have seen this happen a lot. Sometimes that can just be the nature of development, but a good regression suite ensures the newer moles are caught prior to them leeching to customers.

@diffbluehq True. Often actual time exceeds the estimated time, due to surprises on the way (which just never stop).

play games :)

Extra time? That's assuming majority of the developers are writing tests. I would actually like to know how much time vast majority of developers spend time writing tests?

Its like adding extra hours to a day! If I didn't have to write the tests - first - that would take some stress off me! I would relax those extra hours for 1-2 days and then use my 'uncluttered' mind to do anything :-)

Lego.

I wonder how much the "context switching" from coding to testing just hurts your productivity and brainspace. Actual coding is problem solving, active brain work. It's hard. If you lose mental energy to switching tasks constantly...

I honestly think it is not about time saving from writing tests. It is really about impact on the economics of software development. It is about getting fast feedback and saving time lost from recurring defects.

Time saving from writing test may be significant part of the industry, IMHO.

I meant "significant only to a small part"

On a more serious note. Features, integrations, better UX, the things that I actually want to write code for :). #diffchat

@division6 I think testing should not be done as a separate thing. Thinking on how you are going to test or what needs to be tested will make you think on all those corner cases that need to be implemented.

> Time saving from writing test may be significant part of the industry, IMHO.
@venkat4diffchat, that's what we hear from our customers regularly. Numbers range from 20 to 50% time spent on writing tests. So, there is significant potential.

@venkat4diffchat For every developer who spends 8 hours per day on a 6-month project, they spend a conservative 1 hour per day writing unit tests: https://www.diffblue.com/roi-of-ai-whitepaper

(edited)

@PeterSchrammel interesting numbers. Do these account for only the time to write the test or also the time you need to figure out what you need to write?

@DiffKroening my observation from seeing development at large is that it is much less. Even if we were to consider 1 hour to be a representation, I consider that very low. Hence my assertion it is not about time saving from writing tests but cost saving on regression.

@radcortez, overall. Figuring out what and how is the hard bit. #AIForCode can help exactly there.

Thanks everyone for your thought-provoking comments and questions!

thanks for the invite. It was a pleasure to be here :)

Thanks all, I am going to get back to writing #UnitTests... oh wait a minute, it's the future now and I don't have to because #AIForCode does it. Huzzaah!

Thanks! It was a pleasure to participate in this discussion today.

I don't think there is a right answer for this. You can start with a baseline and then adjust for your needs. Some industries require different things.

Its a generic question and the answer would depend on the existing structure of your team.

I think we are already seeing that QA is a responsibility of every developer and I would imagine this merge would only continue.

@Royletron exactly like the DevOps movment

As a starting point, testing gets closer to the developers, as opposed to a set up where QA is far away and administratively disjoint from writing software. That in turn enables developers to be closer to shipping software, and ultimately, operating it.

Ultimately, developers get control over a much larger part of the overall value chain

@radcortez oh now that is a topic I can talk about AT LENGTH.

Automation brings testing closer to developers. So, teams will become more integrated, I think. Throwing half-baked code over the wall to the test team will come to an end, hopefully.

@Royletron we need a DevOpsQA movement :)

@radcortez yes yes and yes. To all of that

I am wondering, do you think it's a good thing if the developers have more control over the overall value chain, or should there be "independent control"?

(edited)