I just started in my new job - I am about to work with 3 highly intelligent and competent software developers plus whatever consultants and external ressources we add to our pool of ressources.
I have a few personal goals with this new job. One of them is to try to ask the questions which are impossible to answer correctly but nevertheless make people think. So I took the initiative and gathered our small crew to a little session which was supposed to be a wrap-up of all the things I had worked on in my previous job. What had I been doing, what had I learnt, what kind of personal insight had I gained and so on... Primarily I wanted to focus on the process and not so much on tech-stuff and implementation of projects.
I started out and soon I had wound up all the failures and fuckups of my previous projects... Yes, I have made lots of weird, unmaintainable sicko-code which however had made the business happy and had earned loads of money to the company. I started thinking: "What is quality?". Ooooooohhhhhmmmmmm........ A sudden insight appeared before my eyes and I felt it coming: "Define quality!". I asked the other guys when we came around the subject in our talk and asked them to define quality. They went quite blank and I knew I hit something. When I asked them who should define quality one of them said without blinking: "Well... in this firm we do..."
I have thought a lot about what quality is after we had our talk. What is quality? As a software engineer I tend to focus on issues such as code readability, ability to extend, logging, choice of technology and so on. For a guy working in a sales departement I think quality can be summed up to: "Can I earn a shitload on money on this feature?" He couldn't care less that I use LINQ or NHibernate to fetch data from the database. He only cares that when somebody clicks "Confirm order" the order is stored in a way which makes it possible to invoice the customer.
It makes a lot of sense to me to define quality as the least possible amount of effort spent to keep the sales departement happy. Why should we measure things differently? If they are happy it means they are able to sell - and if they are able to sell you know you will also be payed for your work at the end of this month. I regret that I haven't found any better definition because it actually promotes cowboy-coding to be an legal approach to new software in about 80% or 90% of all new business cases!! Oh my God...
Somebody save me - how can I go to work tomorrow knowing that I am obliged to be writing sloppy, unmainainable code in order to have a short Time To Market which will enable Sales departement to earn a shitload of money because we were first movers on the subject?
This blog contains reflections and thoughts on my work as a software engineer
søndag den 10. februar 2008
Definition of quality
Indsendt af Kristian Erbou
Etiketter: software quality
Abonner på:
Kommentarer til indlægget (Atom)
Opslag
4 kommentarer:
I'll agree with you that the marketing people don't care about the what ORM you use as long as it does what he needs, and what he can sell.
But as with any software, a version 1.1 after that first 1.0 will in most cases be necessary . And in all your code, all you've done is keep on hacking stuff "so it works", then that 1.1 will be a nightmare for you and in consequence it will take allot longer than needed ... and your timeline will go to hell :).
So it really is best to write good software - aka extendable, and having in mind the certainty that it will change :) - so make it as easy as possible when it comes time to change it.
You are absolutely right and your arguments are also the ones I use when I am cornered by sales staff in dark alleys at Midnight ;o)
I really think that we should wait until version 1.1 is on the drawing board before considering tech details such as the ones mentioned - unless the business explicitly mentions that i.e. extensive logging is a key quality metric in version 1.0. (i.e. if legislations require that audit logging and tracing is required) Why bother spending time on something you don't know for a fact will be a success until the product has proven itself to be one?
And if it is a success I deeply believe that you do not as a software developer have to defend a large amount of refactoring hours because "Hey - you sales guys knew you didn't get a first class product in version 1.0 - and now we earned the money possible to pay for a rewrite before releasing version 1.1".
I agree with you in most of your thoughts, but I think you forget something.
The same guys from sales department eventually will ask you to fix\change\expand the code, and then all the money that was saved will be spent and much more...
I see this every day! We have this web app which is based on a great idea, but the code is awful and we spend couple of hours each day in supporting the bugs each time 1 row of code needs to be changed.
I say, if the project is bigger then couple of hundreds rows of code, do it right or you will pay later.
I'm not even a software engineer :)
Thanks for the reply - I just got an idea for a post about technical debt...
Touché: You say "do it right or you will pay later"... That is exactly my point - if you have been firstmover on a new market with a technically crappy product you hopefully have earned the money to pay for bad technical design choices. I hate myself for saying that but I can't find a decent counterargument if I decide to see the world from a non-technical point of view - which in 95% of all cases is how the people paying for the services we make _do_ see the world ;o)
/ Kristian
Send en kommentar