Where did software quality go ?
A while ago I met with an ex Technical Director of a very large game company here in Vancouver. I was working for a local company myself, and we met about a possible project between the two companies.
While going over the details we reviewed some legacy systems that they would be working with, the software quality was less than ideal.
The statement he made quite a few times that got me thinking was - "all software is messy and usually bad, and that's just the way it is".
To which I instantly thought :
I'm not sure if this was just his defeatist attitude, or one that had been fostered from coming from a corporate environment that was steeped in technical debt and that usually worked to the lowest common denominator.
Though it did make me think - as I don't accept that, at all, so why do so many others?
In my experience people who create technology typically attempt to do the best they can in the environment they are in, with the skills, information and support they have. We all have bad days, and inexperience can trip up neophytes as they learn. Though the vast majority of developers I've worked with want to create quality, something to be proud of and to be seen on TechCrunch and the like.
So why does it "go wrong" so much?
Why is a lack of quality :
A) accepted as the norm (by a truth by constant assertion I believe)
B) supported by attempts to do a decent job signed off as "over engineering", "wasting time" and my favourite ........... "taking too long" (as if technical debt is cheap to work off)
---
I'm happy to say I've worked in both kinds of places - though sad to say the poor attitudes to the approach of creating software are still very prevalent.
Lots of places want the rewards of success of doing a quality job, so why are so many companies avidly avoiding actually doing a good job by choice? Partially senior management ignorance & lack of quality management, though mostly a short term view I think.
I was happy to see Mark Zuckerberg speaking a while ago about longer term view of technology - basically how so many failed dot coms were thinking build junk and sell it quick, and got what they deserved.
I also find that a large and worryingly growing section of business believe that "agile" is a one stop shop to assuring quality in software and that it will cure all ills - it wont. It is just a process, and therefore an organisational tool. It organises work flow and tries to support communication, but it isn't going to assure McLaren levels of quality.
You can apply all the tools (process or tech) you want, though if the mindset and approach is the same it's nothing more than a thin veneer.
I think there is a collective answer to this, and one that developers themselves must be a part of, opposed to finger pointing at "the suits who just don't get it". If they don't "get it", then we have a responsibility to show how and why, as well as learn the bits we don't get in business.
---
Firstly I think that there is a lot of confusion as to what a prototype is and what it purpose is. If it's just to show mocked up functionality of put in front of a VC, then that's it's purpose. Not to be given to a development team the day after funding and told to "make it work". It was a tool to show concept to get money ..... then let it be that, just a prototype.
Defend against the "Oh it's built using agile we can just improve on it", if it was and architected correctly then fine, but if it was hacked together over a weekend to have some buttons that work, then that's what it is, a hack job. You take some UI or content, but be very aware that a demonstration on a laptop and serving tens of millions of users a day in a distributed scaled system manner are about as different an environment as you can get.
Having someone who understand architecture is vital, i.e. the most senior technical person. Look at the vast majority of successful tech companies leaders and their levels of technical knowledge, opposed to just business acumen.
Secondly I think a lot of developers know the difference in quality, though they don't communicate that though fear of reprisal and the demoralising put down of "Oh it's just a 5 min hack, put it in". Leaning how to manage that communication and finding a suitable process for change management is also vital.
I enjoy cowboy coding, when it's just me and for hobby projects, even then I follow some process ........ but when it's a company and/or team environment, the benefits and speed of quality far out weigh the midnight hacker mentality. Especially when capturing the logic of the solved challenge (i.e. design and code comments) and sharing that amongst the team, which is the essence of what developers should do (fire people who don't comment code and can't explain it 2 weeks later, seriously !!).
A business & sales mind (or any mind for that matter, we all do it) will see a "product" and make assumptions as to it's purpose, fitness for market and all manner of things. That needs to be clarified amongst all parties and especially understood by the product owner. Manage expectation and focus on clarity of communication.
Third is the quality of engineering, education and knowledge, or the lack there of. A piece over on supercoders.com.au covers this nicely, talking about Design Patterns and why there is a difference between a 3 week scripting course and a 4 year software engineering degree .... I've seen so many wheels reinvented, or problems misdiagnosed or not even seen that a band aid is applied (i.e. accruing technical debt) that it's shocking.
We need to do better, and to do so, we need to be better ........ we also have to prove why we should be building quality then speed, any by proof. That being quality software that you can build on opposed to spending the future "fixing". Self discipline comes into this as well - as does our professional approach - as that quality will make it's way into the project and software.
I'm not arguing for over engineering or huge out of control development cycles, quite the opposite. The main outcome of building quality software that I've seen is the (accelerating) speed at which new development can be performed. When you are spending 90% of your time build and 10% fixing well isolated and architecturally designed systems (and not the other way around), you build quality and faster.
Fourth would be process. There is a huge amount of knowledge and experience available on how to "do it", as with design patterns and code, it is with buisness and teams, don't reinvent the wheel. I see 37 signals selling books that people call revolutionary thinking ..... alas Tom DeMarco explained most of it decades ago in Peopleware. A lot of project measurements are quite out of date as it is, and the organisation as a whole has a responsibility to focusing on learning and self improvement, as much as the individual.
It's this thought to building quality foundations that agile usually throws out the window, much like the short term view of finance the western world has taken over the last 30 odd years ....... and how did that turn out.
----
So ultimately - quality leads to, more speed & less haste. Don't take your time but use your time wisely to build something of quality that is fit for purpose.
While going over the details we reviewed some legacy systems that they would be working with, the software quality was less than ideal.
The statement he made quite a few times that got me thinking was - "all software is messy and usually bad, and that's just the way it is".
To which I instantly thought :
“The constant assertion of belief is an indication of fear”
~ Jiddu Krishnamurti
I'm not sure if this was just his defeatist attitude, or one that had been fostered from coming from a corporate environment that was steeped in technical debt and that usually worked to the lowest common denominator.
Though it did make me think - as I don't accept that, at all, so why do so many others?
In my experience people who create technology typically attempt to do the best they can in the environment they are in, with the skills, information and support they have. We all have bad days, and inexperience can trip up neophytes as they learn. Though the vast majority of developers I've worked with want to create quality, something to be proud of and to be seen on TechCrunch and the like.
So why does it "go wrong" so much?
Why is a lack of quality :
A) accepted as the norm (by a truth by constant assertion I believe)
B) supported by attempts to do a decent job signed off as "over engineering", "wasting time" and my favourite ........... "taking too long" (as if technical debt is cheap to work off)
---
I'm happy to say I've worked in both kinds of places - though sad to say the poor attitudes to the approach of creating software are still very prevalent.
Lots of places want the rewards of success of doing a quality job, so why are so many companies avidly avoiding actually doing a good job by choice? Partially senior management ignorance & lack of quality management, though mostly a short term view I think.
I was happy to see Mark Zuckerberg speaking a while ago about longer term view of technology - basically how so many failed dot coms were thinking build junk and sell it quick, and got what they deserved.
I also find that a large and worryingly growing section of business believe that "agile" is a one stop shop to assuring quality in software and that it will cure all ills - it wont. It is just a process, and therefore an organisational tool. It organises work flow and tries to support communication, but it isn't going to assure McLaren levels of quality.
You can apply all the tools (process or tech) you want, though if the mindset and approach is the same it's nothing more than a thin veneer.
I think there is a collective answer to this, and one that developers themselves must be a part of, opposed to finger pointing at "the suits who just don't get it". If they don't "get it", then we have a responsibility to show how and why, as well as learn the bits we don't get in business.
---
Firstly I think that there is a lot of confusion as to what a prototype is and what it purpose is. If it's just to show mocked up functionality of put in front of a VC, then that's it's purpose. Not to be given to a development team the day after funding and told to "make it work". It was a tool to show concept to get money ..... then let it be that, just a prototype.
Defend against the "Oh it's built using agile we can just improve on it", if it was and architected correctly then fine, but if it was hacked together over a weekend to have some buttons that work, then that's what it is, a hack job. You take some UI or content, but be very aware that a demonstration on a laptop and serving tens of millions of users a day in a distributed scaled system manner are about as different an environment as you can get.
Having someone who understand architecture is vital, i.e. the most senior technical person. Look at the vast majority of successful tech companies leaders and their levels of technical knowledge, opposed to just business acumen.
Secondly I think a lot of developers know the difference in quality, though they don't communicate that though fear of reprisal and the demoralising put down of "Oh it's just a 5 min hack, put it in". Leaning how to manage that communication and finding a suitable process for change management is also vital.
I enjoy cowboy coding, when it's just me and for hobby projects, even then I follow some process ........ but when it's a company and/or team environment, the benefits and speed of quality far out weigh the midnight hacker mentality. Especially when capturing the logic of the solved challenge (i.e. design and code comments) and sharing that amongst the team, which is the essence of what developers should do (fire people who don't comment code and can't explain it 2 weeks later, seriously !!).
A business & sales mind (or any mind for that matter, we all do it) will see a "product" and make assumptions as to it's purpose, fitness for market and all manner of things. That needs to be clarified amongst all parties and especially understood by the product owner. Manage expectation and focus on clarity of communication.
Third is the quality of engineering, education and knowledge, or the lack there of. A piece over on supercoders.com.au covers this nicely, talking about Design Patterns and why there is a difference between a 3 week scripting course and a 4 year software engineering degree .... I've seen so many wheels reinvented, or problems misdiagnosed or not even seen that a band aid is applied (i.e. accruing technical debt) that it's shocking.
We need to do better, and to do so, we need to be better ........ we also have to prove why we should be building quality then speed, any by proof. That being quality software that you can build on opposed to spending the future "fixing". Self discipline comes into this as well - as does our professional approach - as that quality will make it's way into the project and software.
I'm not arguing for over engineering or huge out of control development cycles, quite the opposite. The main outcome of building quality software that I've seen is the (accelerating) speed at which new development can be performed. When you are spending 90% of your time build and 10% fixing well isolated and architecturally designed systems (and not the other way around), you build quality and faster.
Fourth would be process. There is a huge amount of knowledge and experience available on how to "do it", as with design patterns and code, it is with buisness and teams, don't reinvent the wheel. I see 37 signals selling books that people call revolutionary thinking ..... alas Tom DeMarco explained most of it decades ago in Peopleware. A lot of project measurements are quite out of date as it is, and the organisation as a whole has a responsibility to focusing on learning and self improvement, as much as the individual.
It's this thought to building quality foundations that agile usually throws out the window, much like the short term view of finance the western world has taken over the last 30 odd years ....... and how did that turn out.
----
So ultimately - quality leads to, more speed & less haste. Don't take your time but use your time wisely to build something of quality that is fit for purpose.
Comments
Post a Comment