November 7, 2013 at 7:51 am
Thomas Abraham (11/7/2013)
bryanellis (11/7/2013)
This reminds me of a programming test I had when in college. The professor gave us a single task: get the top 10 student names alphabetically from the college database. The database was in an unsorted text file and we had to use assembler language. I asked a simple question "Does efficiency count?" to which he responded "No". I promptly left the classroom for the computer lab. 30 minutes later I had the 10 names by running through the list 10 times. While extremely inefficient it gave the answer to the problem. I went back to the classroom and found the professor still lecturing the rest of the students on how to build a merge sort. To my knowledge I was the only one to finish the test in the class period. Many times a business user just needs an answer, not always a solution that can be repeated efficiently in the future.Bet you could have found it by visually scanning the list in 10 minutes or less. Why did you waste 20 minutes?
I'm not picking on this particular poster. This was just the most concrete example of the "hurry it up" at all costs mentality I run into a lot.
I agree with other posters that "it depends". However, slapped together solutions have an annoying habit of living longer than intended. Maintenance costs eat resources.
If I'm doing an ad hoc query, I tend to go for the quick solution, still being mindful of the load I might put on the server.
For anything that gets saved to be rerun, I slow down and try to get it right the first time. Do I always look at the execution plan to squeeze out every inefficiency? No. But I try to be more clever than I would for an ad hoc query. I might be stuck maintaining the beast I created for a long time.
Corners have to be cut on almost every project. But, be careful before you cut.
At college one of the courses I took was split into two halves; one half for those interested in software engineering and the other in business analysis and management. There was plenty of joint modules and everyone seemed to have a leaning one way or the other (and we all - almost all - excelled at times at looked rather foolish at others.
This one girl (for we were all kids then) leaned towards the BA/Management side and struggled with programming. She wasn't stupid at all but programming was not for her. When tasked with printing the alphabet in reverse (in Ada, if I recall correctly) she hardcoded the printing of the alphabet in reverse. She did technically fulfil the task, however, it was part of a module that clearly was to do with looping. I feel that she was too smart to know what she did was what was truly asked of her but didn't have the confidence to pursue one that did.
My point is that a software delivery still needs maintainable for its foreseeable lifetime and performant enough to be usable. Any UI must be reasonably intuitive. It doesn't need to be perfect but it should be developed properly in the context of intended use.
In my anecdote the intended lifetime needed zero maintainability, UI was irrelevant and performance was not an issue but the key requirement of the software was not met (i.e. to demonstrate a technique) so it was a failure. PS I think she did at least OK on the course and has probably been successful in her career - just unlikely as a developer.
Oh and Steve, "a little clunky"? Intentional provocation Mr Editor?
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 7, 2013 at 7:55 am
In the computer world, the call center world, the farming world.....I could go on. But in many lines of work there seems to be this tendency to pit efficient and quality against one-another. I don't want it fast at the expense of quality, and I don't want quality at the expense of efficiency. These two things aren't mutually exclusive, or shouldn't be. Still there is a prevailing attitude that you can have one or the other. I want both. More pressure? Yep. More training? Certainly. More experience? Yes. To quote a popular commercial playing currently in the U.S., "and is better".
November 7, 2013 at 8:16 am
So who has this 'small number of very sophisticated users'? I never did. After I retired the first time, I was asked to come back, and ended up working another three years. During that time, I fixed many faults and improved lots of code that was never implemented by managers who were satisfied with 'good enough', to the detriment of data quality and user satisfaction. If users have to circumvent your system to do their job, you have failed. If your support people are constantly handling quality issues and failures, you have failed again.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
November 7, 2013 at 8:23 am
In some business situations, time is of the essence. If a competitor rolls out a great new offer that requires you to change your systems, and you have to match the offer or lose market share, then you can't wait for perfection. In this sense, business is like war where you invariably go to war with the weapons you have and not the weapons on the drawing board and there is always an insane rush to deploy the next generation of weapons even though the might have teething issues (e.g. the Germans and the Panther tank)
November 7, 2013 at 8:24 am
Tom John-342103 (11/7/2013)
Still, the concept of delivery good-enough (if that is what "a little bit clunky" means) is valid and correct since good-enough today is better than perfection a year from now.The trick for project managers is to determine if good-enough really is good-enough.
Pretty clearly, for something like healtcare.gov which is being made available to potentially millions of users, the quality has to be really good. On the other hand, if you are rolling out an application for a small number of very sophisticated users, they will have some tolerance for quirks and workarounds.
It's really not up to the Project manager or the Agile team to decide what constitutes "good enough". I think we've strayed way off the mark when IT internally gets to decide what "Good enough" is. This is the same failing that leads to talking about asinine concepts such as "perfect"; you're working outside of the requirements and specifications.
It's entirely OK to build something knowing that it needs to do more than what the current phase requires. That said - what is NOT okay is to go off on a tangent and build something outside of any specifications or requirements. So - you probably should build your data layer to perform well at volumes higher than where they will be day one, but you should still have a specific target performance you're aiming for, which is agreed to by the sponsor.
In a project setting, if there is any major deviation on supportability, performance, etc... these concerns should be bubbled back up to the champion and/or sponsor, along with potential costs and risks associated. They make the call on whether to implement or delay.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
November 7, 2013 at 8:33 am
Matt Miller (#4) (11/7/2013)
Tom John-342103 (11/7/2013)
Still, the concept of delivery good-enough (if that is what "a little bit clunky" means) is valid and correct since good-enough today is better than perfection a year from now.The trick for project managers is to determine if good-enough really is good-enough.
Pretty clearly, for something like healtcare.gov which is being made available to potentially millions of users, the quality has to be really good. On the other hand, if you are rolling out an application for a small number of very sophisticated users, they will have some tolerance for quirks and workarounds.
It's really not up to the Project manager or the Agile team to decide what constitutes "good enough". I think we've strayed way off the mark when IT internally gets to decide what "Good enough" is. This is the same failing that leads to talking about asinine concepts such as "perfect"; you're working outside of the requirements and specifications.
It's entirely OK to build something knowing that it needs to do more than what the current phase requires. That said - what is NOT okay is to go off on a tangent and build something outside of any specifications or requirements. So - you probably should build your data layer to perform well at volumes higher than where they will be day one, but you should still have a specific target performance you're aiming for, which is agreed to by the sponsor.
In a project setting, if there is any major deviation on supportability, performance, etc... these concerns should be bubbled back up to the champion and/or sponsor, along with potential costs and risks associated. They make the call on whether to implement or delay.
Definitely.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 7, 2013 at 8:47 am
I have worked for a company, however, where the owner/lead developer (same person) took this philosophy to such an extreme that the architecture of our flagship products were so poorly done that future maintenance/extension was a nightmare. The "quick and dirty" approach was used everywhere because the owner felt that time to investigate better technology, or plan a better approach was wasted when we could be churning out code. To this end, we used COBOL and flat files until our large customers (!?!) forced us to migrate to SQL Server in the early 2000's. The one thing I learned from that job is that taking the time to use the right technology, and then taking the time to carefully plan your architecture makes your life immeasurably easier and (more to the point) more productive in the long run!
Brian Bartsch
November 7, 2013 at 9:05 am
Ask 100 people how they would envision a "perfect" solution, and you'll get 100 different answers, only 10 of which are even remotely feasible. Implementing and deploying IT projects is a lot like public transportation projects. Shutting down 2 lanes of a 4 lane highway for an entire week may be a bit "clunky", but sometimes it's the best solution given the budget and time constraints. In the case of adding a new feature to a website, if it performs it's function and no one complains, then I'd chalk it up as a success, even if it's not a work of art.
In retrospect, I'm sure the guys who developed healthcare.gov now wish they had put more design and effort into making backend work than perfecting the look and feel. First make it work, then make it pretty.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 7, 2013 at 9:35 am
The way I express it is;
Good enough really is.
November 7, 2013 at 9:41 am
Gary Varga (11/7/2013)
Oh and Steve, "a little clunky"? Intentional provocation Mr Editor?
The exact quote from the email I saw. I did not press further as to what "clunky" was, but from my impression of the question and response, it had to do with a somewhat strange way of taking input in a frame instead of some popup that communicated back with the original page.
November 7, 2013 at 9:42 am
skeleton567 (11/7/2013)
If users have to circumvent your system to do their job, you have failed. If your support people are constantly handling quality issues and failures, you have failed again.
Absolutely. You'll note in the piece I said that it has to work and support the users.
November 7, 2013 at 9:42 am
Ideally, providing the best possible solution to a problem should be the goal. However that is not always possible and so 'good enough, for now' is a valid approach.
I have worked in small 'shops' the vast majority of my career, including shops comprising of only me, myself and I. Sometimes you have to compromise to get users what they need.
A couple of years back, there was a need that would save users hours of work and improve performance of our application. Of course they 'needed it yesterday' because some projects that were getting ready to start up. As always there were multiple way to address the issue with the ideal solution costing multiple times the effort of an as effective solution (from the users point of view). Given the lack of resources, time and knowledge to implement the ideal solution we chose to implement the less than ideal solution.
Plans are in the queue for the coming year to readdress the issue by implementing the ideal solution. This allowed us to get the users what they need and bought us time to plan a proper implementation of a solution we know will work but have never had experience with before.
So, 'good enough' is often acceptable even when you know there is a better solution. Just strive to implement the better solution when circumstances allow it.
November 7, 2013 at 9:43 am
Tom John-342103 (11/7/2013)
In some business situations, time is of the essence. If a competitor rolls out a great new offer that requires you to change your systems, and you have to match the offer or lose market share, then you can't wait for perfection. In this sense, business is like war where you invariably go to war with the weapons you have and not the weapons on the drawing board and there is always an insane rush to deploy the next generation of weapons even though the might have teething issues (e.g. the Germans and the Panther tank)
Perhaps, but I've seen this flawed analogy used over and over. Ebay was not the first, nor last, to include certain functionality, yet they succeeded wildly beyond others. Facebook wasn't the first to include many of their features, but they overtook many others.
The "time is of the essence" argument seems to often be based on someone's personal compensation, not the success of the company.
November 7, 2013 at 9:46 am
Eric M Russell (11/7/2013)
Ask 100 people how they would envision a "perfect" solution, and you'll get 100 different answers, only 10 of which are even remotely feasible. Implementing and deploying IT projects is a lot like public transportation projects. Shutting down 2 lanes of a 4 lane highway for an entire week may be a bit "clunky", but sometimes it's the best solution given the budget and time constraints. In the case of adding a new feature to a website, if it performs it's function and no one complains, then I'd chalk it up as a success, even if it's not a work of art.In retrospect, I'm sure the guys who developed healthcare.gov now wish they had put more design and effort into making backend work than perfecting the look and feel. First make it work, then make it pretty.
First para, yes. I agree.
Second, no. There were multiple teams, probably too many, and the UI group likely didn't have much to do with the backend. The integration of the back end, which was very complex, wasn't given enough time, testing, and perhaps support from leaders. Lots of failures in this project, and I can only wish that it would be examined as a way *not* to develop software under contract and time constraints. Perhaps not the way to pick a vendor, either.
November 7, 2013 at 9:47 am
At one point, one of the telcos started to offer billing to the nearest second or something like that where the competition could only do it to the minute. This forced the competition to jump through hoops to try to offer the same thing. Whether or not they would have been better off just cutting rates, I don't know, but they certainly seemed to think they needed to bill by the second as well.
Viewing 15 posts - 16 through 30 (of 82 total)
You must be logged in to reply to this topic. Login to reply