In real business programming, executive-level anything are so out of touch with any sort of programming or scripting that it all appears the same. Our VP of finance described once a project where an excel spreadsheet was modified as a programming project. To him, it was. To me, it was just a spreadsheet, and no more programming than typing a letter in word.
The bottom line should always be -- does the program do the thing that the user needs it to do, thereby making their job easier, or even possible?
People wonder why the state of commercial software is so sad -- I think that this article sums it up.
The fact that one of the largest, if not the largest, commercial software companies needs to be told that "the needs and attitudes of the customers should determine what software Microsoft should produce" denotes a total lack of clue on the whole issue of software production.
Software exists to automate or otherwise make better THE THINGS THAT PEOPLE DO. Thus, these things should be what drive the software. Hence the thrust toward usability, contextual design, the user stories of XP, etc.
You just have to be careful that what you think is junk at the moment will remain junk. From the Y2K shenanigans, I observed a tendency for people to use the date 991231 as a "junk" date. Played hell with converting away from it (telling which dates were the junk EOY and which were the actual EOY was the tricky bit). We now use, in our company, a "junk date" well before the start of the company, '01-jan-1900'.
Re:You know what I think makes the difference?
on
1985 Usenet About Y2k
·
· Score: 1
I agree. Back when Gemstone had a max of 40 people online (about this same time, actually), people were far more civil with each other. The behavior was more representative of a "real" society. Now, griefers log in with throwaway MSN accounts where even the GM's of the game can't tell who the person is behind it, the legacy of which is a much stronger strain of sociopathic behavior around the game.
There was a recent article on this same concept as applied to the recently released "magic online", a transition of the (IMO) barely civil RL Magic the gathering card game into an anonymized electronic version. The author noted a larger percentage of griefers in this arena as well.
Without some structure in place where a potential jackass knows "hey, that will get me smacked in the face", the jollies the potential jackass will get out of being a butthead far exceeds any negative impact that s/he will endure. Online anonymity removes the smack-in-face penalty, and lets them get their full load of jackass-jolly-juice.
I still don't want to paste a serial number or ID code in my processor though:)
It all depends upon which part of the gov't you're talking about, and trust for what purpose. If you're talking about which part can make an operating system more secure, for that purpose, I'd trust the NSA more than Microsoft. Of course, I wouldn't trust them very far when it comes to keyword scanning phonecalls and emails. But that's not what this particular issue is about.
My theory behind why it takes such packages such a long time to develop into useable tools for a large user base is related to the difficulty in getting requirements.
People just don't know what they need software to do. It's hard for anyone to be objective and accurate about just what it is that they do from second to second during their daily processes. It's even harder for people to go up a level from that point and envision how they can improve what they're doing. Most people take the software they're given and just use it, silently cursing the flaws without thinking about what they could do to work better.
Read "Contextual Design" -- the authors make these arguments much more convincingly and completely than I can, and give a potential solution to the problem as well. The only problem (from the perspective of most programmers) is that you have to spend more time with the users, get to know the users, learn their culture and activities.
I disagree. In most companies, trouble comes from people not understanding that the role of business software in a business is to automate the processes of that business where it makes sense to do so.
The processes come first.. from the business process come requirements.. from the requirements a design is formed.. then coding/testing is done, resulting in a deliverable. That's the *ideal*. Businesses typically implement a different approach.
Typically, the processes are broken and misunderstood. It's not clear in a common company why a thing is done a particular way, it Just Is. At some point, a broken process will gather opponents, though these opponents won't be any more introspective into the process space than anyone else is. They just want Change. So they do one of two things -- bring in consultants to Jargonize everything, or buy software to give them new processes.
Either way, the stage is set for what I think is the common paradigm for software in business: "If something seems wrong, buy new software or outsource".
Neither approach addresses the fact that the processes were broken in the first place, and that the way a business operates is crucial in trying to get whatever goals that company has accomplished.
There are things in XP that bother me, but one thing that it brings out is the importance of involving users in the process in terms of their own words, their own thinking. In other words, make them think about their processes. It's a start. Contextual Design is better, but XP is more "hip".
Any exposure of good ideas is, tautologically speaking, good. (maybe I should have capitalized all of those words)
Fast development time with minimal business time investment. They don't care how good it is. They don't care how long it lasts. In fact, they're more than likely going to declare your software as a capital asset and depreciate it over five years, and carry forward the opinion that software -- somehow -- just dies after five years.
What should *you* do? IMO, you should get as solid a grounding as you can in as many core things as possible. Math, physics, liberal arts. Problem solving is likely the best possible skill you could have (read Polya, chant it like a mantra when you're stressed:> ) The liberal arts will help ground your understanding of all sorts of other things. Developing software for people in a business is primarily a people task -- finding out what they want is the biggest adventure in this whole field. Particularly when they have no idea how to put into precise language what they need. The 16 hours of anthropology I took in college have been a wonder to me in trying to determine what my company's requirements are lately. "An Ethnography of the Don'tKnowMyProcesses Tribe".
All of these other studies will also help to provide a fall-back. Never shut yourself out of options.
Until recently, I'd played MUDs for a long time (about a decade). They started out with small groups of people that were mostly tech-oriented (particularly when the internet wasn't a household word).
As the internet spread, and particularly after AOL was unleashed upon us, more and more people started hitting MUDs. I noticed that more of the immature people became noticable -- though I suspect that the proportion wasn't drastically different. The people that didn't annoy me didn't get noticed, so I didn't note an increase there.
This general trend hit a big bump once MUDs went graphical and mainstream. I played Everquest and Asheron's Call for 2-3 months each, long enough to see that it wasn't just a matter of proportion at work. Something else was making these games have a feel to them that was uncomfortably unlike the MUD communities that I had been used to. There are a lot of different elements behind it, and I haven't spent enough time on the problem to identify even a portion of them.
Some sort of societal transformation happened that is tied up in both the change to the game, and the meta-game (meaning the large number of fansites that a big game will have.... some of the forum discussions on these sites have a tangible impact on the game society itself). There are clans now that weren't there before. These clans have an impact on the game society, yet are largely organized outside of the game proper. There are lots of other things that demonstrate the impact of just the change to graphical mainstream games on the genre.
I suspect that the change to the console will cause large changes of its own -- though I won't be watching anymore.
The big problem, as I see it, is that there is a surplus of stuff that needs doing.
If we were to assume a fixed percentage of people that have "the mindset", then tossing more people at the problem wouldn't gain us much. In fact, to a degree it would hurt the situation because those with "the mindset" would be having to help the others, without, limp along.
I don't think that the problem is best solved by focusing on increasing this number. I think that instead, methods of focusing the people we have that can work well are needed. We need to start finding ways that we can "sand off" the rough spots in IT.
One example is the user-analyst interface where people tell you "requirements"... there are a lot of documented requirements problems out there that show that people find it hard to articulate to IT what it is that they need. How is IT supposed to provide those needs if they're unarticulately presented? Or if^H^Hwhen they change? This is the one that's hit closest to home for me, but this one alone could save much of the work that we do over when the perceived need of the moment happens to change.
I suppose in a nutshell, what I'm arguing for is quality over quantity. But like the lead article said, the answer is probably somewhere in the middle. It's hard to find quality, particularly when you can't even find quantity.
IMO, part of the problem in measuring sucess by LOC is that the vast majority of my work is maint coding. I just move the same LOC around. One of the "new" programs I wrote within the last year was a conversion of an existing program from one language into another (actually 2 others). So my net LOC was lower than the work entailed would indicate.
Slashdot Mirror
In real business programming, executive-level anything are so out of touch with any sort of programming or scripting that it all appears the same. Our VP of finance described once a project where an excel spreadsheet was modified as a programming project. To him, it was. To me, it was just a spreadsheet, and no more programming than typing a letter in word.
The bottom line should always be -- does the program do the thing that the user needs it to do, thereby making their job easier, or even possible?
The rest is just fluff.
People wonder why the state of commercial software is so sad -- I think that this article sums it up.
The fact that one of the largest, if not the largest, commercial software companies needs to be told that "the needs and attitudes of the customers should determine what software Microsoft should produce" denotes a total lack of clue on the whole issue of software production.
Software exists to automate or otherwise make better THE THINGS THAT PEOPLE DO. Thus, these things should be what drive the software. Hence the thrust toward usability, contextual design, the user stories of XP, etc.
You just have to be careful that what you think is junk at the moment will remain junk. From the Y2K shenanigans, I observed a tendency for people to use the date 991231 as a "junk" date. Played hell with converting away from it (telling which dates were the junk EOY and which were the actual EOY was the tricky bit). We now use, in our company, a "junk date" well before the start of the company, '01-jan-1900'.
I agree. Back when Gemstone had a max of 40 people online (about this same time, actually), people were far more civil with each other. The behavior was more representative of a "real" society. Now, griefers log in with throwaway MSN accounts where even the GM's of the game can't tell who the person is behind it, the legacy of which is a much stronger strain of sociopathic behavior around the game.
:)
There was a recent article on this same concept as applied to the recently released "magic online", a transition of the (IMO) barely civil RL Magic the gathering card game into an anonymized electronic version. The author noted a larger percentage of griefers in this arena as well.
Without some structure in place where a potential jackass knows "hey, that will get me smacked in the face", the jollies the potential jackass will get out of being a butthead far exceeds any negative impact that s/he will endure. Online anonymity removes the smack-in-face penalty, and lets them get their full load of jackass-jolly-juice.
I still don't want to paste a serial number or ID code in my processor though
It all depends upon which part of the gov't you're talking about, and trust for what purpose. If you're talking about which part can make an operating system more secure, for that purpose, I'd trust the NSA more than Microsoft. Of course, I wouldn't trust them very far when it comes to keyword scanning phonecalls and emails. But that's not what this particular issue is about.
My theory behind why it takes such packages such a long time to develop into useable tools for a large user base is related to the difficulty in getting requirements.
People just don't know what they need software to do. It's hard for anyone to be objective and accurate about just what it is that they do from second to second during their daily processes. It's even harder for people to go up a level from that point and envision how they can improve what they're doing. Most people take the software they're given and just use it, silently cursing the flaws without thinking about what they could do to work better.
Read "Contextual Design" -- the authors make these arguments much more convincingly and completely than I can, and give a potential solution to the problem as well. The only problem (from the perspective of most programmers) is that you have to spend more time with the users, get to know the users, learn their culture and activities.
I disagree. In most companies, trouble comes from people not understanding that the role of business software in a business is to automate the processes of that business where it makes sense to do so.
The processes come first.. from the business process come requirements.. from the requirements a design is formed.. then coding/testing is done, resulting in a deliverable. That's the *ideal*. Businesses typically implement a different approach.
Typically, the processes are broken and misunderstood. It's not clear in a common company why a thing is done a particular way, it Just Is. At some point, a broken process will gather opponents, though these opponents won't be any more introspective into the process space than anyone else is. They just want Change. So they do one of two things -- bring in consultants to Jargonize everything, or buy software to give them new processes.
Either way, the stage is set for what I think is the common paradigm for software in business: "If something seems wrong, buy new software or outsource".
Neither approach addresses the fact that the processes were broken in the first place, and that the way a business operates is crucial in trying to get whatever goals that company has accomplished.
There are things in XP that bother me, but one thing that it brings out is the importance of involving users in the process in terms of their own words, their own thinking. In other words, make them think about their processes. It's a start. Contextual Design is better, but XP is more "hip".
Any exposure of good ideas is, tautologically speaking, good. (maybe I should have capitalized all of those words)
Fast development time with minimal business time investment. They don't care how good it is. They don't care how long it lasts. In fact, they're more than likely going to declare your software as a capital asset and depreciate it over five years, and carry forward the opinion that software -- somehow -- just dies after five years.
:> ) The liberal arts will help ground your understanding of all sorts of other things. Developing software for people in a business is primarily a people task -- finding out what they want is the biggest adventure in this whole field. Particularly when they have no idea how to put into precise language what they need. The 16 hours of anthropology I took in college have been a wonder to me in trying to determine what my company's requirements are lately. "An Ethnography of the Don'tKnowMyProcesses Tribe".
What should *you* do? IMO, you should get as solid a grounding as you can in as many core things as possible. Math, physics, liberal arts. Problem solving is likely the best possible skill you could have (read Polya, chant it like a mantra when you're stressed
All of these other studies will also help to provide a fall-back. Never shut yourself out of options.
So, the dolphins are finally getting the monkeys to learn how to communicate. That's a good sign!
Until recently, I'd played MUDs for a long time (about a decade). They started out with small groups of people that were mostly tech-oriented (particularly when the internet wasn't a household word).
As the internet spread, and particularly after AOL was unleashed upon us, more and more people started hitting MUDs. I noticed that more of the immature people became noticable -- though I suspect that the proportion wasn't drastically different. The people that didn't annoy me didn't get noticed, so I didn't note an increase there.
This general trend hit a big bump once MUDs went graphical and mainstream. I played Everquest and Asheron's Call for 2-3 months each, long enough to see that it wasn't just a matter of proportion at work. Something else was making these games have a feel to them that was uncomfortably unlike the MUD communities that I had been used to. There are a lot of different elements behind it, and I haven't spent enough time on the problem to identify even a portion of them.
Some sort of societal transformation happened that is tied up in both the change to the game, and the meta-game (meaning the large number of fansites that a big game will have.... some of the forum discussions on these sites have a tangible impact on the game society itself). There are clans now that weren't there before. These clans have an impact on the game society, yet are largely organized outside of the game proper. There are lots of other things that demonstrate the impact of just the change to graphical mainstream games on the genre.
I suspect that the change to the console will cause large changes of its own -- though I won't be watching anymore.
The big problem, as I see it, is that there is a surplus of stuff that needs doing.
If we were to assume a fixed percentage of people that have "the mindset", then tossing more people at the problem wouldn't gain us much. In fact, to a degree it would hurt the situation because those with "the mindset" would be having to help the others, without, limp along.
I don't think that the problem is best solved by focusing on increasing this number. I think that instead, methods of focusing the people we have that can work well are needed. We need to start finding ways that we can "sand off" the rough spots in IT.
One example is the user-analyst interface where people tell you "requirements"... there are a lot of documented requirements problems out there that show that people find it hard to articulate to IT what it is that they need. How is IT supposed to provide those needs if they're unarticulately presented? Or if^H^Hwhen they change? This is the one that's hit closest to home for me, but this one alone could save much of the work that we do over when the perceived need of the moment happens to change.
I suppose in a nutshell, what I'm arguing for is quality over quantity. But like the lead article said, the answer is probably somewhere in the middle. It's hard to find quality, particularly when you can't even find quantity.
IMO, part of the problem in measuring sucess by LOC is that the vast majority of my work is maint coding. I just move the same LOC around. One of the "new" programs I wrote within the last year was a conversion of an existing program from one language into another (actually 2 others). So my net LOC was lower than the work entailed would indicate.