In software development there is always the trade of between get X coded immediately fast and get X coded so that it has properties like -- it deals properly with possible inputs, it handles errors properly, it has tests, it follows standard code conventions, its legible, it has normal usability characteristics...
Most of the time though people seem to be impressed by speed -- 'wow! you all got that done really fast.' Last week Thursday my boss was explaining to the big boss that we had a new application request from San Jose. We could understand about 80% of the initial spec and that was probably enough to get started working on the code design ideas, maybe some database design, put some infrastructure in place...The big bosses reaction was 'Great! Ill come by next Wednesday and you can demo the application for me'. And so demo preparations ensued with, naturally, a great deal of energy and in the end we put together a little dog and pony show for the dude.
It's surprising to me that a senior executive at a well know software technology company would have so little knowledge of what an application consists of (especially for Java) that he would think to himself 'Lets see Friday, Monday, Tuesday -- three days should be enough to write an application.'
My own boss should know better. He has been a developer, but I found out during the pre demo coding efforts that he didn't have any conception of time himself. There were several times during the three coding days where I got requests for additional features. My response was 'Fine, that will take about an hour to code; here are my current feature priorities; you know how much time I have; where do you want to fit that in?' 'An hour? cant you do that like right now, like, in 1 or 2 minutes?' People who haven't worked with the code of an application seem to have very little ability to judge times even when they have coding experience....Still, I can help but expect a bit more in this case.
And the results from the demo....the big boss thought that 'it' was really great. He said a couple of times during the demo 'That was built really fast'. Evidently that speed was important. And his advice to us was to 'continue to add stuff fast and get the application out there'.
There is a balance to be struck here in making applications. There has to be long term thinking and short term thinking. At any point in time one has to have a long term design - or maybe its better to call it a long term philosophy for the application. What will it do /not do? How will it do that? What's the applications mission? What is best for the users? That long term philosophy guides the overall focus of the work. And then there are the short term needs like 'I need to get the login page working now. Let's just get that working the simplest way possible and make it perfect later.' As one develops an application one works back and forth between the long term focus and needs and the short term ones. And as one moves forward the long term philosophy changes which changes the short term focus. Each feeds back to the other in a long learning process. Most importantly that learning process takes time, and there is no way to short circuit that.
So looking back, at the end of the week, I have an 'application' written with no overall coherent philosophy of what we are building. But 'it' was built really fast. And the big boss says that is good. And it has also been a horrible waste, part of which we will throw out and part of which we will rewrite. So how good is that now?
Most of the time though people seem to be impressed by speed -- 'wow! you all got that done really fast.' Last week Thursday my boss was explaining to the big boss that we had a new application request from San Jose. We could understand about 80% of the initial spec and that was probably enough to get started working on the code design ideas, maybe some database design, put some infrastructure in place...The big bosses reaction was 'Great! Ill come by next Wednesday and you can demo the application for me'. And so demo preparations ensued with, naturally, a great deal of energy and in the end we put together a little dog and pony show for the dude.
It's surprising to me that a senior executive at a well know software technology company would have so little knowledge of what an application consists of (especially for Java) that he would think to himself 'Lets see Friday, Monday, Tuesday -- three days should be enough to write an application.'
My own boss should know better. He has been a developer, but I found out during the pre demo coding efforts that he didn't have any conception of time himself. There were several times during the three coding days where I got requests for additional features. My response was 'Fine, that will take about an hour to code; here are my current feature priorities; you know how much time I have; where do you want to fit that in?' 'An hour? cant you do that like right now, like, in 1 or 2 minutes?' People who haven't worked with the code of an application seem to have very little ability to judge times even when they have coding experience....Still, I can help but expect a bit more in this case.
And the results from the demo....the big boss thought that 'it' was really great. He said a couple of times during the demo 'That was built really fast'. Evidently that speed was important. And his advice to us was to 'continue to add stuff fast and get the application out there'.
There is a balance to be struck here in making applications. There has to be long term thinking and short term thinking. At any point in time one has to have a long term design - or maybe its better to call it a long term philosophy for the application. What will it do /not do? How will it do that? What's the applications mission? What is best for the users? That long term philosophy guides the overall focus of the work. And then there are the short term needs like 'I need to get the login page working now. Let's just get that working the simplest way possible and make it perfect later.' As one develops an application one works back and forth between the long term focus and needs and the short term ones. And as one moves forward the long term philosophy changes which changes the short term focus. Each feeds back to the other in a long learning process. Most importantly that learning process takes time, and there is no way to short circuit that.
So looking back, at the end of the week, I have an 'application' written with no overall coherent philosophy of what we are building. But 'it' was built really fast. And the big boss says that is good. And it has also been a horrible waste, part of which we will throw out and part of which we will rewrite. So how good is that now?
RSS Feed