Because you need to understand these things.. Too many programmers are considered incompetent because they do not understand the process (business process)
Just as a doctor would need to spend 6 or more years learning their trade and then another 6 or more years being mentored by the senior doctors before being turned loose on their own, so must our people or we will continue to have incompetent programmers. I myself have been in situations where I was the only developer, or I hired and mentored teams and I can guarantee you that in most cases when I came onboard, the MIS dept was clueless about the basic functioning of their company. For us to develop anything, we need to understand two things: 1. How the business process flows from beginning to end (without computers) when they receive raw materials and they are turned into finished goods, and 2. How the business process flows from beginning to end (again without computers) when they receive a order until it is shipped and also any problems received after it has been sold. Until you understand these processes, you are only a bandaide installer in my opinion, or down here in the south, a bailing wire fixer-upper.. The reason I bring this up is because if a programmer is incompetent, it actually is the team lead's or the managers fault because they are not doing their job of being the mentor. I know ed doesn't agree, but until we take responsibility for our own people, we have nobody to blame but ourselves Think about this. How many jobs have you been on where there might be 10 or even 50 developers working on projects, but typically two of the superstars are doing the majority of the work and the rest are only doing bits and pieces. This is because: 1. The superstars won't or don't have the time to mentor the junior members, and 2. Job security for the superstars. My belief is that if we would spend the time mentoring the junior members and get them all up to speed and cull out the ones that can't come up to speed, the sum total of 50 programmers that are outstanding would far achieve the sum total of two superstars. For those that are still with me, hopefully you realize that it is up to you, the superstar or the team leader, or the manager to build or mold your team so that they can have the skills that are necessary for your company to be the superstar. Professionals or not, just as there are good doctors and bad doctors and the same for attorneys, no process will work correctly without the manager working on the big picture and focusing on the details of making sure that their team has all of the skills (programming, business, etc) necessary and I've seen far too many managers that refuse to participate in the development of their teams because they were worried that one of the memembers would take their job. I have always believed that if I teach you the skills so that you can take my job, it frees me up to go to the next level. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ricardo Aráoz Sent: Sunday, February 14, 2010 7:08 AM To: ProFox Email List Subject: Re: .NET and other languages for a VFP developer Virgil Bierschwale wrote: > Nope it is not a waterfall model because it has absolutely nothing to > do with software. > You are not being consistent here. It it has *absolutely nothing* to do with software, then why are you exposing it as an argument for certain software development models? > That is the department layout for a company I worked at. > > For instance, lets say that the software group was raring to go and > they developed the software before the artwork and the math > calculations were done. > > Then you would end up redoing the software portion. > True, the origins of waterfall model are in construction and other similar activities. You should take some time and read about it, you'll like it. As for redoing the software portion. Are you aware that resources are limited? And that sometimes a system will take several years before being finished? And that business requirements, hardware requirements, back end requirements (that would be databases), will certainly change? Well, there are methodologies that take this into account not as an unwanted event but as a normal and expectable event. To redo a software portion (and notice I don't say *the* software portion, but just one of them) is just normal. It makes no sense arguing about this, there are books written on the subject and you are talking as if it is something no one ever addressed. > The same thing applies to making a 50 story office building. > Until the architect has completed his bluleprint, you would be foolish > to purchase a single door or even a brick. > But you won't be using the building until it is completely built. You *must* know the size of the building before doing it. Specifications won't change along the way. And the terrain in which it stands will not change either. None of these things are true for many software projects. So you see the problem. > See, that is the biggest problem I have in the software business. > Not saying you guys, but software people tend to think the business > revolves around them and they are so wrong on this. > What you say is true. I've seen it oh so many times. Once I heard a developer being told that a series of actions performed by the user in his system would provoke an error, and the answer was "But the user should not do this". But that has nothing to do with the development methodologies. > For instance, at that same manufacturer in vegas, I was able to stop > one of the higher ups from creating his own MIS group because the > existing MIS group was bogged down in their own work and totally > unresponsive to the business side. > I worked several years for an airline's department because they could get no response from the, really large, software department. But that is anecdotal and has nothing to do with the development methodologies. > Even though I can no longer find work in the software business, I > still see those battles being fought daily in the trade journals. > > Bottom line, if you're a software developer and you cannot draw a > block diagram of your companies business process flow from memory, you > do not understand your business and you have some bridges to mend. > I'm currently working (under a full time contract) for a company that manages all the side businesses of the main milk company (that is, trucks, insurance, gas stations, cold providing systems, etc). I only understand some of the software systems involved (some are even developed outside the company, no access to source code), let alone have the company's business process flow, let alone the main milk company's one. I don't think anyone can have in mind the whole data flow model, it's too big. That does not mean I cannot do my job. [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/108cb084c7d84789802ceaf96b48d...@bierschwc0bba6 ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
