March 9, 2011 at 8:44 am
This week I have 16 meetings that I have to attend and I'm also concurrently coding on 4 unrelated applications, managing several SQL Servers, as well as other admin minutae for various servers, answering questions, and debugging & researching crap for apps that I have developed and apps from coders that are no longer with the company.
I've been running like this for just short of two decades and it has just gotten worse -- this year in particular. I don't know if other internal development groups run like this but it's impossible for me to tend to the level of quality that I want simply due to the amount of task switching I have to do during the day.
Amazingly, I have been able to fudge it for a long time now and I have a great set of users that are ok with me getting to 80% of their needs and scrambling to fix bugs that are nearly always because of my lack of attention to details because I have too much to do and too many interruptions, and etc..
Is this my fault? Probably, but it's a systemic relationship issue between me, my boss, his bosses, and our users. The group dynamics support this way of doing things. For this to change we need a company and culture wide paradigm shift. That being said my team is working on a method to address this chaos because it's simply not sustainable.
But one point I would make is that I feel we, as an industry, are just now actually figuring out how to write software. And we should remember that as an engineering discipline our industry is just getting started.
Along with this site, tekpub, cleancoders.com, and others we are finally just starting to get and idea of how to create and maintain software, how to actually use patterns, how to communicate with and manage users. We've been winging it for about 60+ years and we are just being able as an industry to discern what works and what doesn't. We have spent most that time re-inventing the wheel -- we keep solving the same problems with different variations of the same code.
March 9, 2011 at 12:16 pm
More and more I find myself leaning toward a sub version of the "Agile programming methodology", though this kind of thinking works better for somewhat smaller web-based programs than traditional large software releases like SQL Server. As a small independent developer I too have experienced users not really knowing what they want, but if I use a modular "Agile" approach I can mock up a more or less working version of a new feature and put it quickly into production to see if this is really what the users want and if it is I can (hopefully) spend the time to improve the code later to eliminate bugs etc... When you don't know if a feature will really meet the needs of your users because they don't really know what they want themselves, it just makes a lot more sense to focus on speed over quality, since spending a lot of time getting a feature perfect when in the end it won't really meet the business need of the user just makes no sense at all.
March 9, 2011 at 12:31 pm
krowley (3/9/2011)
When you don't know if a feature will really meet the needs of your users because they don't really know what they want themselves, it just makes a lot more sense to focus on speed over quality, since spending a lot of time getting a feature perfect when in the end it won't really meet the business need of the user just makes no sense at all.
I think you nailed it on the head there!
March 9, 2011 at 1:07 pm
Mark W Johnson (3/9/2011)
krowley (3/9/2011)
When you don't know if a feature will really meet the needs of your users because they don't really know what they want themselves, it just makes a lot more sense to focus on speed over quality, since spending a lot of time getting a feature perfect when in the end it won't really meet the business need of the user just makes no sense at all.I think you nailed it on the head there!
Again, this is where I talk with the user because it makes no sense to write code for something the user isn't sure of.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2011 at 1:18 pm
Jeff Moden (3/9/2011)
Mark W Johnson (3/9/2011)
krowley (3/9/2011)
When you don't know if a feature will really meet the needs of your users because they don't really know what they want themselves, it just makes a lot more sense to focus on speed over quality, since spending a lot of time getting a feature perfect when in the end it won't really meet the business need of the user just makes no sense at all.I think you nailed it on the head there!
Again, this is where I talk with the user because it makes no sense to write code for something the user isn't sure of.
Sometimes it is (or at least seems) quicker and easier to simply write up some code to mock up a feature when I have a general idea of what the user wants than to spend another several hours in meetings trying to make the user decide what they really want. There comes a point where you just have to create SOMETHING and then refine from there, rather than trying to gets the specs exactly right the first time.
March 9, 2011 at 2:07 pm
krowley (3/9/2011)
Jeff Moden (3/9/2011)
Mark W Johnson (3/9/2011)
krowley (3/9/2011)
When you don't know if a feature will really meet the needs of your users because they don't really know what they want themselves, it just makes a lot more sense to focus on speed over quality, since spending a lot of time getting a feature perfect when in the end it won't really meet the business need of the user just makes no sense at all.I think you nailed it on the head there!
Again, this is where I talk with the user because it makes no sense to write code for something the user isn't sure of.
Sometimes it is (or at least seems) quicker and easier to simply write up some code to mock up a feature when I have a general idea of what the user wants than to spend another several hours in meetings trying to make the user decide what they really want. There comes a point where you just have to create SOMETHING and then refine from there, rather than trying to gets the specs exactly right the first time.
Exactly, I don't think most (seasoned) coders will code something until they are convinced that the user has something worthwhile in mind but just needs help refining it. That was my take on your post.
Most significant software challenges rarely have a cut-n-dry solution -- especially in the case of UIs. In my experience, the "final" solution is usual grown from a series of mockups and revisions. I don't see my job as writing code so much as solving the user's problem through code; my job is to help them find a solution. I don't expect them to know what the solution looks like.
It seems to me that the process of creating software for an internal user as opposed to a external user lends itself to different levels, degrees, or facets of quality. Since I have direct access to the user, I can get away with lesser quality because I can be quick to respond to bugs or other updates -- plus the "software development" is shared between me and user. The user is a contributer to the product so they have a different expectation and tolerance to the quality of the system. So, in this case, speed is more valuable than quality.
But if I'm writing code for an external customer who I don't have access to and the user is not personally involved in the development of the product then quality become more important. It behooves me then to stonewall my PM and say "it'll be done when it's done" and sacrifice speed for quality, otherwise everybody will look bad after the product is put into production.
March 9, 2011 at 3:01 pm
Mark W Johnson (3/9/2011)
I don't see my job as writing code so much as solving the user's problem through code; my job is to help them find a solution. I don't expect them to know what the solution looks like.
Excellent quote. Often we do need to code/mock/show something for the user so they can decide if it's what they want, and how they might change it to meet their needs.
March 9, 2011 at 3:56 pm
Steve Jones - SSC Editor (3/9/2011)
Mark W Johnson (3/9/2011)
I don't see my job as writing code so much as solving the user's problem through code; my job is to help them find a solution. I don't expect them to know what the solution looks like.Excellent quote. Often we do need to code/mock/show something for the user so they can decide if it's what they want, and how they might change it to meet their needs.
There are a lot of developers who start off by designing a mockup of the report or web form, something that looks like what the client needs, and then assume that they will go back in another iteration and hook up the "database plumbing" after the client signs off on the visual part.
However, I do the reverse. Whenever I get a request for a new report, dashboard feature, etc. that assumes required data will be in the database, the first thing I do is write a basic SQL query that attempts to return the expected numbers. I give the numbers to the business as soon as possible, so we can jump on potential data issues early in the process. There have been times when the request was simply scrapped because the underlying data incomplete for what they need, and that certainly saves a lot of wasted front end work.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 28, 2011 at 4:10 pm
I constantly see our developers slap on a new feature quickly thats poorly spec'd, quickly developed, and inadequately tested. Then the business wonders why they have scalability and performance issues. Or loss of productivity waiting for a bug to be fixed.
And we don't have a seperate bug fix team, so our developers constantly failing to deliver their next projects while fixing the bugs from the last project.
Our developers have such a poor perception amongst the users, they really do despise them thinking they are bunch of muppets, and management will happily blame them when its their pressure to get that new feature in quickly that is as much to blame.
And you see it externally too in every other vendor. I'm sure we've all raised our fist in anger at Microsoft due to some bug in a product.
March 28, 2011 at 5:12 pm
krowley (3/9/2011)
Jeff Moden (3/9/2011)
Mark W Johnson (3/9/2011)
krowley (3/9/2011)
When you don't know if a feature will really meet the needs of your users because they don't really know what they want themselves, it just makes a lot more sense to focus on speed over quality, since spending a lot of time getting a feature perfect when in the end it won't really meet the business need of the user just makes no sense at all.I think you nailed it on the head there!
Again, this is where I talk with the user because it makes no sense to write code for something the user isn't sure of.
Sometimes it is (or at least seems) quicker and easier to simply write up some code to mock up a feature when I have a general idea of what the user wants than to spend another several hours in meetings trying to make the user decide what they really want. There comes a point where you just have to create SOMETHING and then refine from there, rather than trying to gets the specs exactly right the first time.
I guess I've been pretty lucky. Most of the users that I've had to deal with somehow manage to quickly get to the point when I have them on the phone and they follow up with requirements and a scope agreement (think "incremental releases" on bigger jobs) pretty quickly after that. Heh... I strongly suspect it's all because they want me to stop bugging them a couple of times a day. 😀 Of course, I don't have to worry about GUI's nor how many pixels I have to move something to make someone happy because I'm mostly a "batch programmer". I only have to worry about where the data is coming from, what they want to do with it, and where it has to go (sometimes supporting the GUI and Reporting Apps in the process).
--Jeff Moden
Change is inevitable... Change for the better is not.
July 29, 2016 at 3:07 am
Mark W Johnson (3/9/2011)
krowley (3/9/2011)
When you don't know if a feature will really meet the needs of your users because they don't really know what they want themselves, it just makes a lot more sense to focus on speed over quality, since spending a lot of time getting a feature perfect when in the end it won't really meet the business need of the user just makes no sense at all.I think you nailed it on the head there!
We all are so blessed that Steve Jobs did not follow this advice!
_____________
Code for TallyGenerator
Viewing 11 posts - 16 through 25 (of 25 total)
You must be logged in to reply to this topic. Login to reply