With programmers complaining that managers are forcing them to push unsatisfactory code out the door, TechRepublic looks at whether developers are getting a raw deal.
Does this conversation sound depressingly familiar?
Programmer: “There’s a security hole in this code, can I fix it?”
Project manager: “No, we don’t have enough time, just ship it anyway”.
This type of exchange embodies what some readers feel is wider problem in software development - that programmers are not given time to write the code they feel is up to scratch.
A repeated complaint during a recent TechRepublic discussion about security holes in code was that the main concern of managers is to get code out of the door, and nothing short of a show-stopper of a problem will hold back its release.
The reality of software development is that commercial pressures will often drive suppliers to favour rapid delivery above other considerations, according to Michael Azoff, principal analyst for software and IT solutions at Ovum.
“There is pressure on developers as often in a customer-supplier relationship penalties kick-in if something isn’t supplied by a certain date,” he said.
“In those instances it’s easier for the supplier to deliver and then fix known issues later, which had they more time they would have dealt with. From the developers’ point of view it’s unsatisfactory, but that is the reality out there.”
And as another TR reader pointed out, when “big profits are made out small cost savings” there can be an incentive for organisations not to fix poor code.
Given that companies supplying software to large organisations often don’t have the incentive to stop sloppy code being rushed out the door, Azoff said it is up to the customer to fix these issues. Bringing in a third party test the supplier’s code will deal with many of these problems, he said.
“The more mature a customer is and more educated they are about these kind of issues, the more likely they will bring in these testing services to deal with these problems,” he said, adding that sensible customers will also have in-house staff who manage the quality assurance of the software and the external testing service.
Could agile save the day?
Changes in the way that software is developed are also reducing the tendency to ship unsatisfactory code, said Azoff.
As agile software development methodologies become more popular, and the use of waterfall methodologies decrease, Azoff said that the pressure on developers to rush out a sub-par release should also fall.
“Waterfall tended to deal with testing and QA towards the end of schedule, and that’s when things get very pressured and where shortcuts are taken. That’s been a long term problem with waterfall.
“The reason why agile has increased adoption and has displaced waterfall is that agile deals with testing and quality much better.”
As a result of agile allowing developers to do more unit testing and continuous checks and integration “the quality of the product is improved while it is being developed”, he said.
Don’t forget the bigger picture
Even though developers may feel as if managers are forcing unnecessary compromises, it may be the right decision for the business.
“Good engineers focus on engineering and sometimes lack that bigger picture to look at the business - [to realise] that if you don’t ship this then we’re going bust,” said Andrew Clymer, a founder of software consultancy, training and development specialist Rock Solid Knowledge.
“If you’re going out of the door with a security hole, depending on what you’re exposing, that’s a risk I guess the PM feels the organisation should take, and they have access to the bigger picture.
“At the same time I’m sure there are times when the PM doesn’t see the deep engineering side of it.”
Software can never be perfect or 100 per cent secure, and Clymer said that ultimately the decision on when to push the code out of the door needs to be taken by someone who can appreciate the wider commercial context.
“You’re always under pressure to ship and PMs always want it ready to go, I’d say it’s a necessary evil.”
Does this conversation sound depressingly familiar?
Programmer: “There’s a security hole in this code, can I fix it?”
Project manager: “No, we don’t have enough time, just ship it anyway”.
This type of exchange embodies what some readers feel is wider problem in software development - that programmers are not given time to write the code they feel is up to scratch.
A repeated complaint during a recent TechRepublic discussion about security holes in code was that the main concern of managers is to get code out of the door, and nothing short of a show-stopper of a problem will hold back its release.
The reality of software development is that commercial pressures will often drive suppliers to favour rapid delivery above other considerations, according to Michael Azoff, principal analyst for software and IT solutions at Ovum.
“There is pressure on developers as often in a customer-supplier relationship penalties kick-in if something isn’t supplied by a certain date,” he said.
“In those instances it’s easier for the supplier to deliver and then fix known issues later, which had they more time they would have dealt with. From the developers’ point of view it’s unsatisfactory, but that is the reality out there.”
And as another TR reader pointed out, when “big profits are made out small cost savings” there can be an incentive for organisations not to fix poor code.
Given that companies supplying software to large organisations often don’t have the incentive to stop sloppy code being rushed out the door, Azoff said it is up to the customer to fix these issues. Bringing in a third party test the supplier’s code will deal with many of these problems, he said.
“The more mature a customer is and more educated they are about these kind of issues, the more likely they will bring in these testing services to deal with these problems,” he said, adding that sensible customers will also have in-house staff who manage the quality assurance of the software and the external testing service.
Could agile save the day?
Changes in the way that software is developed are also reducing the tendency to ship unsatisfactory code, said Azoff.
As agile software development methodologies become more popular, and the use of waterfall methodologies decrease, Azoff said that the pressure on developers to rush out a sub-par release should also fall.
“Waterfall tended to deal with testing and QA towards the end of schedule, and that’s when things get very pressured and where shortcuts are taken. That’s been a long term problem with waterfall.
“The reason why agile has increased adoption and has displaced waterfall is that agile deals with testing and quality much better.”
As a result of agile allowing developers to do more unit testing and continuous checks and integration “the quality of the product is improved while it is being developed”, he said.
Don’t forget the bigger picture
Even though developers may feel as if managers are forcing unnecessary compromises, it may be the right decision for the business.
“Good engineers focus on engineering and sometimes lack that bigger picture to look at the business - [to realise] that if you don’t ship this then we’re going bust,” said Andrew Clymer, a founder of software consultancy, training and development specialist Rock Solid Knowledge.
“If you’re going out of the door with a security hole, depending on what you’re exposing, that’s a risk I guess the PM feels the organisation should take, and they have access to the bigger picture.
“At the same time I’m sure there are times when the PM doesn’t see the deep engineering side of it.”
Software can never be perfect or 100 per cent secure, and Clymer said that ultimately the decision on when to push the code out of the door needs to be taken by someone who can appreciate the wider commercial context.
“You’re always under pressure to ship and PMs always want it ready to go, I’d say it’s a necessary evil.”
Comments
Post a Comment