February 18, 2019 at 9:08 pm
Comments posted to this topic are about the item How Perfect Should Our Software Be?
February 19, 2019 at 1:30 am
One of the gifts of agile development is the concept of continual improvement. If you know that you will have the chance to go back and improve on work you produced to a tight budget/timeline then it is a great enabler.
In my experience people are more rigid in their mindset when they know that delivery is a one time only deal or when they don't trust (based on evidence) that today's tech debt will be addressed tomorrow.
When "business requirements" are understood to be from all facets of an organisation, including IT, then the danger of shiny-shiny always winning the prioritisation battle goes away.
February 19, 2019 at 7:53 am
Ask 10 users what perfection looks like, and you'll get 10 different answers. Ask them again the following week, and you'll have 20 different answers. So, in reality, "perfection" can be nothing more than a solution that satisfies a documented set of requirements that most everyone agreed was good enough at a specific point in time in the past.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 19, 2019 at 8:15 am
I'd say that perfection from the users' perspective is something different. I was writing more in terms of what we'd consider too software engineering or strong, robust architecture or development patterns. Does the software handle loads efficiently and limit the inter-dependencies or technical debt that slow development.
I do think often developers tend to go in one of two ways. They try too hard to make perfect software too early, when there is a lot of flux in how to build the system, or they try to little all the time, resulting in software that becomes increasingly brittle and fragile.
February 19, 2019 at 9:18 am
I choose to believe, and it is certainly my first hand experience, that software developers as a whole are trying hard to produce good work. The whole "break it fast" mindset has permeated the user culture, and they expect things to work but are not surprised when they don't. Even my 8-year old refers to any technological hurdle as a "glitch. " That wasn't in my vocabulary until my late 20s (of course...that was the 90s). I often think about the quality of our data warehouse team's deliverables. Are we spending time making it more robust...or simply polishing a turd? I was listening to a recent episode of the Rabbit Hole podcast in which they discussed whether "programmers" or "developers" should be calling themselves "engineers," given that professional engineers are held responsible if, say, a bridge collapses (episode 87). How responsible are we if our code stinks? How responsible should we be? I agree "perfect" is a point in time, and "perfect" may change over time or audience. Whatever perfect is, we need to be trying hard to get there. As I tell our team, our code may never be RIGHT, but we should continue to make it RIGHTER. (I excel in making up dumb sayings.)
February 19, 2019 at 9:30 am
I like the "try to make it righter" approach. It's what we tend to do at Redgate. We try to build good code. We work quickly, but we constantly try to make the patterns/approaches/code that is done quicker, better the first time by learning. We take some sprints to tackle technical debt and once in awhile we stop work for a period of time to clean up some of the older "less than beautiful" code.
February 19, 2019 at 10:39 am
Oh, WOW, do I have a lot of ideas, in response to this article.
First, I really wish I could work someplace that was even somewhat like Basecamp or Redgate Software.
Second, both my current job and my previous job were very largely slow, plodding, Waterfall based project management. Occasionally, we could experiment on something, but it was never related to a project. It was always something we'd be interested in looking into on the side.
Two-Prime: A consequence of working in slow, methodical, striving for perfection environments has resulted in the vast majority of projects being scraped. This is especially true in my current position. I'm on a team where we're trying to replace really old software (e.g.: MS Access or Excel spreadsheets) with software that could be supported, backed up, etc. The team I'm on has, over the last 3 years, written 4 to 6 applications (I've not been involved with all of them so I'm not sure what the number of projects is.) Of that number, only 1 is in production. The rest have been scrapped. The users could no longer wait for them to be finished, so they told us to stop. They've gone back to using their Access apps or their Excel spreadsheets. They just couldn't wait any longer.
The sad thing is I see this starting all over again, only this time even worse. I'm on a project with 8 people. That includes 2 and a half business analysts. (The half is my boss who likes to do BA work, but hasn't the time to do it full-time.) The BA's are busy as bees, diagramming process flows, interviewing the customers multiple times, writing requirements to the minutest detail, etc. They're in their element, completely enjoying themselves. But I can't figure out why it's taking 2 BAs to do this requirements documentation. And they're also redesigning the database, even though a SQL Server database already exists and is in use. And they know that. I've asked about that, but haven't gotten a straight answer back.
Third, I think that nothing has ever been written about the users expectations. Here's what I mean. Here at work, they've been using Waterfall with voluminous amounts of very detailed documentation for so long, there isn't anyone here who even knows how long its been. I'm guessing it goes back to either the 70's or maybe the 60's; whenever Waterfall became the new kid on the block. With that much time having flowed under the bridge, I'm sure the users now expect extremely long times for software development with copious amounts of documentation. In fact, I'm convinced of it. Recently I was working on a SSRS report against some legacy data that will never be edited again. I was designing the report to look like the screen dump of the application, when it was actually able to work. (It was written by someone else with either Paradox or PowerBuilder. No one around here knows either at this point.) After about 3 weeks I had the beginning of the report done to a point, where I felt I could get feedback from the users, if they like what I was doing, etc. When I got to the demonstration meeting, before I started to show them the report, I told them, "This report is not finished. I'm showing you what I've gotten done so far, so you can tell me if you like how I'm doing this." Then I showed them the report. Immediately, they started saying, "Where's the GI data?", "Where's the diagnostic data?", etc. I told them again and again, that I hadn't finished the report; that I only got it to a point where I knew I could get their feedback; that all I was seeking, at that point, was feedback. It took me 3 times telling them this, before it finally sunk in, that the report wasn't done and I was only seeking feedback. It became clear to me, from that encounter, that because several decades have come and gone where the only thing users ever saw was the completed project, that they literally couldn't fathom what it meant to review an incomplete, but functioning, project.
Kindest Regards, Rod Connect with me on LinkedIn.
February 19, 2019 at 12:12 pm
David.Poole - Tuesday, February 19, 2019 1:30 AMOne of the gifts of agile development is the concept of continual improvement. If you know that you will have the chance to go back and improve on work you produced to a tight budget/timeline then it is a great enabler.
David, I think you are correct about the need for continual improvement. But my experience at my last position in a pretty large IT organization before retirement was 11 years of pretty much rigid resistance to continual improvement. Once code was implemented it was almost impossible to make incremental improvements. If the code was not crashing the systems, but had defects in logic and/or results, there was essentially no chance of improvement. Even during planned incremental version changes one could not get approval for many 'bug-fixes' that had been identified and rectified. If a change was not 'required' for new functionality, there was usually no way unless you took the risk of slipping in unauthorized changes along with formal code changes.
At this particular employer, IT was exactly the opposite of agile. The formality of separating DBAs and SQL developers from application developers from QA testers from project managers essentially ham-strung being agile. In one instance we had even code fixes for eleven related stored procedures which produced proven invalid data that were never implemented due to perceived risk of changing.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
February 19, 2019 at 12:55 pm
Another personal aside to 'how perfect' software should be, I've just pretty much completed ( read that 'code produces accurate results in some initial test data') a ten page stored procedure that incorporates several pages of variables and four pages of complex SQL math computations that 'reverse engineer' detail from lots of summarized and simplified historical data. The goal is to recreate variable unit data from existing dollar data. Nearest that can be accomplished from the existing data is averaging month-level detail to six decimals in order to analyze transactions occurring within the month and then re-summarizing to match to period totals for validation of the calculations. This stuff often requires a certain level of OCD to accomplish the goal. I would estimate that I have at least ten days total of periodic effort into the four pages of calculations.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
February 19, 2019 at 1:49 pm
skeleton567 - Tuesday, February 19, 2019 12:12 PMDavid.Poole - Tuesday, February 19, 2019 1:30 AMOne of the gifts of agile development is the concept of continual improvement. If you know that you will have the chance to go back and improve on work you produced to a tight budget/timeline then it is a great enabler.David, I think you are correct about the need for continual improvement. But my experience at my last position in a pretty large IT organization before retirement was 11 years of pretty much rigid resistance to continual improvement. Once code was implemented it was almost impossible to make incremental improvements. If the code was not crashing the systems, but had defects in logic and/or results, there was essentially no chance of improvement. Even during planned incremental version changes one could not get approval for many 'bug-fixes' that had been identified and rectified. If a change was not 'required' for new functionality, there was usually no way unless you took the risk of slipping in unauthorized changes along with formal code changes.
At this particular employer, IT was exactly the opposite of agile. The formality of separating DBAs and SQL developers from application developers from QA testers from project managers essentially ham-strung being agile. In one instance we had even code fixes for eleven related stored procedures which produced proven invalid data that were never implemented due to perceived risk of changing.
I feel for ya, Rick.
Kindest Regards, Rod Connect with me on LinkedIn.
February 19, 2019 at 3:58 pm
In reply to the question "How Perfect Should Our Software Be", I think we should strive to make it as perfect as time, talent, and budget enable it to be. The details of how that's achieved will vary based on the company, project, and the people involved, including the customer (or prospective customer).
Of course, the software must work. To stop there is setting a very low bar for achievement.
Must meet customer requirements and expectations.
Must follow "best practices" at all levels (database, application, usability, security, scalability, extensibility) to the extent that the project team can implement them.
Must meet the timeline (hope it's a reasonable one...).
Might need to meet performance requirements.
Might need to meet industry regulations.
Might need to be in the cloud - or - must not be in the cloud.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply