I would add to the 2 big components, the ability to iterate. That ability primarily revolves around data tools. As users use the program, they will discover what they knew, but didn't know to mention, despite your best questioning. Having a tool that lets you look over your data structure, and modify it with relative ease, makes a huge difference in the ability to iterate.

>That's a very good point. Seems to me there are 2 big components - Data design and overall app architecture (part of which, of course, is data design)
>
>Since a lot (most, all ? ) of what we do in business apps involves data apps a sound data design is the first requirement. Of course we can come into a situation where part of what we are creating has to use data structures we did not design but which have massive amounts of data that cannot be restructured. Still, designing how we design our use of that data is the first part, and we would probably be creating our own data structures as well. ( having written so many of my own apps from the ground up I had never really thought much about existing data stores I wasn't allowed to fiddle with until I spent time with the South Brunswick crowd :-)
>
>And then the architecture. Again, not a big deal in the past when all I had was a hammer and everything looked like a foxpro app but that part has become much trickier, more interesting and more complex and frankly is what has kept me from getting bored and looking around for something else to point my magic dilettante wand at :-)
>
>But I'm sure you'll agree that whole thing about creating a proper data design is part of that big picture thinking that absorbs the business problem - both stated and unstated - and refines it with questions and requirements gathering and has a pretty good idea where it is all going before ever getting to the keyboard and banging code or creating tables.
>
>The most failed efforts I've ever seen failed in that very first step when somebody fell in love with their own first reaction and never refined their understanding. (for that matter I've seen some first marriages go that way ... )
>
>
>>>>I contend 80% of any software is design
>>Hmm
>>If you mean data design I'd make it more like 90%.
>>If the data design is right you'll never get far off the track and vice versa.
>>
>>I once picked up a vfp system that had been developed by someone who got very ill and had to leave it.
>>
>>The vfp code was primitive and often unwieldy because he hadn't taken time to learn the capabilities of the language in detail, but his data design was truly elegant and still stands almost 10 years later after conversions to SQL Server and .NET.
>>
>>He passed away a year or so after I picked the system up.
>>Because he did such a great job with the data all of the business relationships were obvious and I never had to call him for help, but I did call him once to thank him for doing such a robust design.
>>
>>On the other hand I have worked with several high end accounting systems developed by some well-known VFP people that have major flaws in the data design and invariably they have come back to bite me.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>>>>>>I do it all the time, If you deliver poorly written code that is difficult to maintain, you're doing your customer a disservice and providing shoddy work. As a professional, I would expect to be paid to the job and for doing it right. The nature of software development is that you don't always get it right the first time. Sometimes I do get it right, sometimes not, because it takes time to fully understand the problem and the solution. Sometimes you don't fully understand it until you've gone the wrong path. My customer pays for me to learn about how to fix the problem and for the fix itself.
>>>>>>>>
>>>>>>>>>"When you get the code working, rewrite it so it looks like you knew what you were doing all along"
>>>>>>>>>
>>>>>>>>> then try billing the client for that.
>>>>>>>
>>>>>>>Yes but quite often a client will want function now and rewriting something that works adds zero functionality now. All this rewrite for correctness strikes me as ivory tower stuff.
>>>>>>>
>>>>>>>If you write crap at least comments help.
>>>>>>
>>>>>>There's a school of thought that says "Comments are lies". When I first heard about it I thought it was total nonsense. Now I think there's a lot of truth to it. If you add comments, you have to maintain them just like you maintain the code itself. Far too often, even with my own code, I've run into cases where the code's been updated but the comments haven't - so the comments are lies, or at least misleading or incomplete.
>>>>>>
>>>>>>If code is "crap" then the comments are almost always worse.
>>>>>>
>>>>>>Every experienced programmer knows that the absolute best code is no code at all. One could similarly argue that the best comments are no comments at all. The holy grail is code written such that its purpose and operation is obvious to anyone with a reasonable grasp of the language used, and with no comments required.
>>>>>
>>>>>As Mike Feltman used to tell me, "Great code is self-documenting." :-) That said, comments should be for documenting design interactions that might be helpful if one is looking at the code for the first time. However a document succintly explaining the big picture design is the one that really matters.
>>>>>
>>>>>I think the problem with "Just get it working and get it out the door" is that it creates a mindset where design is considered a time-suck, ivory tower luxury and garbage code is applauded if it is written quickly and doesn't blow up before the check is cashed. It leads to some really intellectually lazy work that may fool managment for while but perpetuates the cycle of bad apps written by hacks later maintained by even less qualified hacks.
>>>>>
>>>>>I contend it is possible to write good code and good apps in a time-efficient fashion if habits of design and best practices have become second-nature and are insisted on as a matter of personal pride. I get tired of hearing people make the excuse that doing it right takes longer. I think knowing *how* to do it right takes a little more professional preparation but the actual doing it right is actually more efficient. The truth is, there are whole lot of people in our business that don' t have the intellectualy curiosity, auto-didactic discipline or mental horsepower to do what this demands.
>>>>>
>>>>>I've had a pretty diverse exposure to other professions and aspects of life and I can say that the most interesting minds I have encountered have been in this field. But I also find that there are a whole slew of people doing this who are completely ignorant of just how far over their heads they are. Writing software is really pretty easy. Writing good software isn't.
>>>>>
>>>>>I like this :
>>>>>
>>>>>http://m.techrepublic.com/blog/programming-and-development/seven-traits-of-effective-programmers/6750
>>>>
>>>>Maybe your thinking of software as a polished tool. I'm thinking of it like popcorn :-)
>>>
>>>Actually, I think of software entirely in terms of business. Like the personal relationships, if they aren't sustainable they are more trouble than they are worth. I've written apps (especially in the closing days at Dow Jones as the merger with S&P got closer and closer ) that were defined up front as "throw-aways" and we wrote them very fast under very tight deadlines. I'd like to think they would have lasted 10 years if they'd had to. And I don't think they took any longer for that.
>>>
>>>I contend 80% of any software is design. Writing code is fast and easy if the design is right. If it's not you will never have a good piece of software or software system. That is why so much outsourcing is a failure, even though the programmers in Mumbai or wherever are actually quite good at writing code. The trick is in knowing what you want the code to do. Doing the wrong thing well is never faster or cheaper.
>>>
>>>And the design is a gestalt thing in the head that takes a certain turn of mind, not a big ol' spec spelled out in 300 pages of stuff for managers to read. Sometimes the subtlest decision at the inception of a project has implications for years to come and if it is never questioned or seen as a flaw early on no amount of agile scrums or whatever the buzzword of the project-"manager" week is will correct that or compensate for it.
>>>
>>>Very smart, experienced people with a big-picture design mindset who hold themselves to a very high standard for their own internal reasons will have a good chance of succeeding if they are not interfered with by the "managers" who have no clue about the art of solving business problems with computers.