Is Agile just a justification for bad business practices?
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question. ;P
-
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question. ;P
dmitri_sps wrote:
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question
Although that might be true, I can only note that the other formal methodologies are almost universally not followed as well. Most companies either do nothing or do so little that no one realistically suggests that they are following any methodology. Other companies claim adherence and yet examination shows that they are in fact not following the methodogies - they implement some of the easiest practices in a ship-shod fashion and completely ignore the harder ones (which actually produce the most bang for the buck.) There are of course some companies that do implement some formal methodology correctly. But the number is so low compared to total developement numbers that it is effectively zero.
-
Yes. There's the short answer. :)
Christopher Duncan wrote:
It seems to me that before you can build something, you have to know what it is and how you're going to go about building it.
I've never worked with any client that new exactly what they wanted. Partly because they're also re-inventing their work processes at the same time. Sort of like mixing gasoline and fire, but that's the nature of the beast. I've essentially been practicing Agile for 20 years, before it was called Agile. The pieces that work for me are: 1. communication between team members in daily stand-up meetings / phone calls 2. putting the app frequently in front of the client so they can alter the course 3. unit testing, if you have the time and the client has the budget (reality bites) What Agile doesn't cover, IMO, is: 1. analyzing the cost of "altering the course" 2. updating the documentation so you have a record of what you changed and why 3. renegotiating the contract when changes occur And in the asinine category: 1. do just the minimum to get the functionality in 2. refactor often (or something like that) [edit] Oh, and the only way I've gotten Agile to really work is to take a declarative approach to programming. Separate the declarative from the imperative, and your development process becomes, by defacto, more agile. [/edit] Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
>And in the asinine category: > >1. do just the minimum to get the functionality in >2. refactor often (or something like that) Just wondering what has led you to this conclusion?
-
dmitri_sps wrote:
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question
Although that might be true, I can only note that the other formal methodologies are almost universally not followed as well. Most companies either do nothing or do so little that no one realistically suggests that they are following any methodology. Other companies claim adherence and yet examination shows that they are in fact not following the methodogies - they implement some of the easiest practices in a ship-shod fashion and completely ignore the harder ones (which actually produce the most bang for the buck.) There are of course some companies that do implement some formal methodology correctly. But the number is so low compared to total developement numbers that it is effectively zero.
jschell wrote:
the other formal methodologies are almost universally not followed as well
I do not see this as a problem. Among successful companies, as you correctly mentioned, there are some who do it by the book, and more are made successful by competent managers and professional developers who do not follow any formal methodology, as they are past a need for a textbook. And similarly different are the loosers in IT world - both who try to follow some methodology on paper, and those who do not have a clue. The later bunch, when they found out that there is such thing as "agile" methodology, gladly jumped on it, just as the Dilbert cartoon (quoted somewhere in previous replies) depicted so well ;)
-
Yes, I think you have to be careful that agile doesn't just become "lets not do any design" like the 'marketing/bad business people' want, but instead agile is recognising that doing all your design up front isn't necessarily the best thing because you discover new things as you go along that you could never have realised from the beginning. I'm not talking about changing requirements, I'm talking about the fact that half way through your project you discover that your design doesn't quite fit and you need to make changes. One of the things about agile that I do really like is the idea of "release early and often". This way you keep your client informed of progress, and get instant feedback so you don't go off in the wrong direction too far if something has been misunderstood. (By release, I don't necessarily mean full access release to the client, but some form of release to testing, or release as a sample of what's been done so far) Fixed requirements are still important, and lots of design is still important. Most methodologies seem to preach "their way" as the perfect path, but ideally I think you need to take the best from all of them without religiously adhering to any one. Different projects have different characteristics and priorities. If you follow any specific one too strictly you won't be flexible when the project isn't going exactly as the methodology allows for.
Simon
I think Simons response is about the most balanced of those I have seen here. No, in itself Agile is not simply a justification for bad business practices. On the other hand, I've seen plenty of organisations that use the term as an excuse not to plan. No-one would spend a million dollars on a new high rise building without a fairly comprehensive plan. Having said that, no-one would expect that plan to go down with the level of specifying where every individual nail will be placed. Plenty of people seem to attempt to write software with those extremes of planning though.
Good advice is always certain to be ignored, but that's no reason not to give it.
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
Agile in its complete form is very far away from "bad business practice", problem is that hardly anyone ever uses it in its complete form (I have never seen it used in its complete form). By definition: - an Agile project does not produce less documentation, it is in fact suppose to produce more (updates & re-iterations MUST be documented well) - an Agile approach is not to complete a project faster, its to ensure that when a project is completed it delivers on the customer's (user) needs, and is important in environments where needs change quickly - an Agile project needs FAR more management time, BA time and User time, and decreases developer time. Managing of changes and scope is crucial for sustainable IT - an Agile project is not cheaper than other approaches (clear from above) - an Agile project needs FAR more dicipline, from all parties involved including management, BA's, developers AND the customer (this is where the wheels usually comes off) - Agile is not intended for massive projects, it can work for massive projects if segmented well though but care should be taken If Agile is done correctly its very effective, just like using a hammer to smack nails with, if the right tool is used in the right way by the right person for the right purpose the results are impressive...
____________________________________________________________ Be brave little warrior, be VERY brave
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
I think it's a bit to simply stated. Admit it, or not, but most software designers either aren't capable to estimate development time accurately if they're given a detailed design. And, even if there is a proper design, the as-built end product is often not really what was designed. There's what I'd call the 'design paradox'. On one hand, you can't estimate costs accurately, if you're design isn't detailed enough. As a result, the details will be designed while coding, design flaws will creep in and that causes a lot of additional debugging. On the other hand, if the design is very detailed, in theory this would lead to less bugs, and a better manageble project, but in real life many "bugs" will be built into the design already, because what looks nice on paper, might not work in a real program. And we all know it's virtually impossible to correctly estimate the time involved in finding the cause of a bug. So having or nog having a detailed design mostly means moving the problem from one end of the project to the other: the 'law of conservation of misery'. So we have to find a compromise between detailed design and hands-on programming. Several things have been proposed in the past. In the mid-'90s, RAD was promoted, now it is Agile. At first sight, Agile looks as if it's just throwing ingredients into the pot, hoping something edible will emerge. But then we overlook a few things. Agile is not only about taking the product the market sooner, it's also about collaboration with the customer and even better, with the end user. To many end users, a detailed design of a complete product is too abstract to comprehend. That's where the communication problem starts and in the end the software turns out not to be doing what the user wanted. Agile tries to address this, by shortening the design/develop/test/deliver cycles. The idea is not to leave out design, but not to design all at once in detail. Personally I'm convinced you'll always need an overall picture, a 'grand design', but that doesn't mean you have to design everything in detail upfront. To some extent, it is what we've been doing all the time already - or rather, should have been doing all the time: start to make a rough design of what we want and then refine it. Tradionally, all of this was done by the designers, but Agile aims to get the end user involved. The way to accomplish this the Agile way, is to refine a basic number of features, build them and present them to the user for evaluation. I don't expect anyone to dispute that if that turns out
-
Jim Crafton wrote:
until it doesn't work, doesn't get built, or doesn't do what you expected it to do
Exactly, that's what I say to my managers all the time. They are constantly saying that "they" don't care about this that or whatever and I always respond with, "Right they don't care... until they do". The point of that response is that later when they do care, it's TO FRAKIN LATE YOU IDIOT!
Manager: I don't care what it looks like, just make it work. Then you deliver the first version and most of the comments are to do with what it looks like! :laugh:
Kevin
-
>And in the asinine category: > >1. do just the minimum to get the functionality in >2. refactor often (or something like that) Just wondering what has led you to this conclusion?
Andrew Napier wrote:
Just wondering what has led you to this conclusion?
Because I see people writing code without any thought to even a minimal amount of abstraction or consideration for good practices (for example, implementing some of the more common patterns.) A little thought ahead of time would save on refactoring later. And it really isn't a balanced equation. Putting the effort up front in writing good code is a lot less expensive than fixing it later. Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
-
In software terms, the only document detailed enough to act as a blueprint is the source code. Any other form of documentation (e.g. design docs) can only express a broad intention - the more detailed they are, the less likely they are to be accurate. A true implementation of an agile process doesn't shun traditional documentation, but doesn't elevate it beyond its station (as Waterfall and other forms of BUFD do) either.
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
I think this is dangerous thinking... that only code can be a complete blueprint, especially for anything that goes anywhere near a database. If you don't take the time to architect and have a shared vision of what the underlying infrastructure will be (in our house analogy here, where you'll place the sewer lines, the water pipes, the electrical, the phone lines, etc.) I have seen entirely too many databases "architected" by procedural programmers who know nothing of how a database works, only to come back months or years later to find out that the entire thing needs to be re-designed in order to perform properly. This generally leads to a significant amount of rework time that could be better spent creating new things and features, based on a good foundation. The bottom line to me is that Agile doesn't give enough emphasis on proper advanced designing (although it doesn't directly preclude it either); waterfall places too much emphasis on design and being code complete before build/release. A combined method that allows for a proper design and architecture up front (especially on apps involving a database, and even more especially if that application/database will have significant amounts of data and users -- something large scale) will be much more efficient than trying to recode thousands of things later. Starting from the same page (document) that says "Where we're starting from" leads to a much better finished product. Changing the color of the roof later doesn't matter, as long as it's still a roof. Joe
-
All of your points with the exception of "deliver working software frequently" and "build projects around motivated individuals" (which is just wishy washy "newspeak" because surely no organization is going to be stupid enough to carry unmotivated individuals are they?) fall firmly into the GOES WITHOUT SAYING category, at least in this shop. I firmly disagree with building any application of any consequence or import piecemeal. All that accomplishes is crappily designed software that makes the gray men in suits happy because it fits the costs into nice quarterly budgets. It's clearly going to be far more expensive to produce and it encourages lazy design. Obviously no big application is ever done so there is always a need to roll out changes but in my world you better have every last bit nailed down on new projects before a line of code is ever written. Then again in my current world we can't pass on the costs to the unsuspecting customer since we sell our software commercially and don't do any contract programming for single customers.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
The only point I disagree with in your e-mail is that no one keeps unmotivated people around... perhaps it's just some of the shops I've been in, but there certainly are "less" motivated people. There are the load-bearers, the superstars who carry 80% of the weight, and then there are folks who carry 2 or 3%... part of it is the superstar who is overdedicated and part of is there are some who just can't be bothered with a sense of urgency, especially in a break-fix scenario (which does happen, regardless of the design methodology). Those people should be (but rarely are) removed from the team to bring in folks with a better fit, but that doesn't always happen. Joe
-
I think this is dangerous thinking... that only code can be a complete blueprint, especially for anything that goes anywhere near a database. If you don't take the time to architect and have a shared vision of what the underlying infrastructure will be (in our house analogy here, where you'll place the sewer lines, the water pipes, the electrical, the phone lines, etc.) I have seen entirely too many databases "architected" by procedural programmers who know nothing of how a database works, only to come back months or years later to find out that the entire thing needs to be re-designed in order to perform properly. This generally leads to a significant amount of rework time that could be better spent creating new things and features, based on a good foundation. The bottom line to me is that Agile doesn't give enough emphasis on proper advanced designing (although it doesn't directly preclude it either); waterfall places too much emphasis on design and being code complete before build/release. A combined method that allows for a proper design and architecture up front (especially on apps involving a database, and even more especially if that application/database will have significant amounts of data and users -- something large scale) will be much more efficient than trying to recode thousands of things later. Starting from the same page (document) that says "Where we're starting from" leads to a much better finished product. Changing the color of the roof later doesn't matter, as long as it's still a roof. Joe
Joe Fox (TiK*) wrote:
I think this is dangerous thinking... that only code can be a complete blueprint, especially for anything that goes anywhere near a database. If you don't take the time to architect and have a shared vision of what the underlying infrastructure will be (in our house analogy here, where you'll place the sewer lines, the water pipes, the electrical, the phone lines, etc.).
First of all, when I say "code" I don't just mean the stuf we think of as source code, but also schemas (XSL, DB, whatever) and any other automated inputs required to produce a deterministic results without significant human decision points (this is pretty much in aggreement with the recent discussion of thesubject by Gilb et all at this year's ACCU Conference[^], but I digress). Given an engineering blueprint for a proven design a hardware design (bridge, building, whatever) can be constructed in a controlled and quite deterministic fashion, without unpredicatable delays due specifically to design ambiguities or shortfalls. For a software project, the problem space has infinitely more variables - far too many to be unambiguously converted from (for a example) a design document into finished product without people getting involved in a myriad of design decisions subsequently. Now, if you have a system in which you can describe the requirement in a completely unambiguous form and convert that directly into the final product you have a different sort of blueprint from source code and schemas. That however, is a problem that does not seem to be anywhere near soluble with present technology (IIRC 4th Generation Languages were supposed to solve this, but they weren't exactly successful). Contrary to what most people think a good agile process doesn't preclude a complete high level design at all, but it does suggest that the design should be "sufficient" and not over-specified (YAGNI[^] can be a good guiding principle here). Issues such as required throughput, schemas (however detailed they need to be for the problem space) etc. are of course part of such preliminary design. I honestly don't see a conflict - knowing what is sufficient to define
-
I think it's a bit to simply stated. Admit it, or not, but most software designers either aren't capable to estimate development time accurately if they're given a detailed design. And, even if there is a proper design, the as-built end product is often not really what was designed. There's what I'd call the 'design paradox'. On one hand, you can't estimate costs accurately, if you're design isn't detailed enough. As a result, the details will be designed while coding, design flaws will creep in and that causes a lot of additional debugging. On the other hand, if the design is very detailed, in theory this would lead to less bugs, and a better manageble project, but in real life many "bugs" will be built into the design already, because what looks nice on paper, might not work in a real program. And we all know it's virtually impossible to correctly estimate the time involved in finding the cause of a bug. So having or nog having a detailed design mostly means moving the problem from one end of the project to the other: the 'law of conservation of misery'. So we have to find a compromise between detailed design and hands-on programming. Several things have been proposed in the past. In the mid-'90s, RAD was promoted, now it is Agile. At first sight, Agile looks as if it's just throwing ingredients into the pot, hoping something edible will emerge. But then we overlook a few things. Agile is not only about taking the product the market sooner, it's also about collaboration with the customer and even better, with the end user. To many end users, a detailed design of a complete product is too abstract to comprehend. That's where the communication problem starts and in the end the software turns out not to be doing what the user wanted. Agile tries to address this, by shortening the design/develop/test/deliver cycles. The idea is not to leave out design, but not to design all at once in detail. Personally I'm convinced you'll always need an overall picture, a 'grand design', but that doesn't mean you have to design everything in detail upfront. To some extent, it is what we've been doing all the time already - or rather, should have been doing all the time: start to make a rough design of what we want and then refine it. Tradionally, all of this was done by the designers, but Agile aims to get the end user involved. The way to accomplish this the Agile way, is to refine a basic number of features, build them and present them to the user for evaluation. I don't expect anyone to dispute that if that turns out
But the overall design still has to have a sensible foundation. I think you say that in your message, but it's being lost in the rest. If there are multiple develoeprs invovled, having a clear picture of where you are going and what the goal is will save time and duplication of effort. I like the concept of short, plannable sprints and being able to get better at time estimation. I think those are valuable skills -- but not without the planning and business analysis first. Joe
-
Christopher Duncan wrote:
Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front.
I think the root of the problem is not a development process (agile or not) but the fact that in many organizations people with no background in software development somehow think they can manage software projects. I am not sure what is it about software development that make everybody think it is easy to manage. I know I would not dare to manage a hospital, for instance, or a bank.
Nemanja Trifunovic wrote:
I am not sure what is it about software development that make everybody think it is easy to manage. I know I would not dare to manage a hospital, for instance, or a bank.
Well, y'see, it's like this. Programmers, bricklayers, carpenters, chemists, etc., actually do things. When one actually does something, one understands the complexities of accomplishment - a mixture of knowledge, experience, and awareness (acceptance) of what they don't know. On the other hand - someone who craves to manage other that do . . . well, everything looks easy to them - they simply decide on it. How hard can it be to actually do? Solving a problem, after all, couldn't be any harder than posing one. . . . and further ramble in this direction.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
-
Nemanja Trifunovic wrote:
I am not sure what is it about software development that make everybody think it is easy to manage. I know I would not dare to manage a hospital, for instance, or a bank.
Well, y'see, it's like this. Programmers, bricklayers, carpenters, chemists, etc., actually do things. When one actually does something, one understands the complexities of accomplishment - a mixture of knowledge, experience, and awareness (acceptance) of what they don't know. On the other hand - someone who craves to manage other that do . . . well, everything looks easy to them - they simply decide on it. How hard can it be to actually do? Solving a problem, after all, couldn't be any harder than posing one. . . . and further ramble in this direction.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
Balboos wrote:
Well, y'see, it's like this. Programmers, bricklayers, carpenters, chemists, etc., actually do things. When one actually does something, one understands the complexities of accomplishment - a mixture of knowledge, experience, and awareness (acceptance) of what they don't know. On the other hand - someone who craves to manage other that do . . . well, everything looks easy to them - they simply decide on it. How hard can it be to actually do? Solving a problem, after all, couldn't be any harder than posing one.
Having been a manager, including being one being tasked with laying people off, I for one certainly consider programming significantly easier. Having witnessed a few (fortunately very few) very personal heated arguments between peers and hearing about others and mediation or lack thereof by management I for one certainly consider programming significantly easier. Having had managers that were willing and often insistent about standing between the developement team and abuse various departments decided that development was responsible for on that particular day I consider programming easier. Especially at one place where the VP ruled by fear and only directed by yelling.
-
Balboos wrote:
Well, y'see, it's like this. Programmers, bricklayers, carpenters, chemists, etc., actually do things. When one actually does something, one understands the complexities of accomplishment - a mixture of knowledge, experience, and awareness (acceptance) of what they don't know. On the other hand - someone who craves to manage other that do . . . well, everything looks easy to them - they simply decide on it. How hard can it be to actually do? Solving a problem, after all, couldn't be any harder than posing one.
Having been a manager, including being one being tasked with laying people off, I for one certainly consider programming significantly easier. Having witnessed a few (fortunately very few) very personal heated arguments between peers and hearing about others and mediation or lack thereof by management I for one certainly consider programming significantly easier. Having had managers that were willing and often insistent about standing between the developement team and abuse various departments decided that development was responsible for on that particular day I consider programming easier. Especially at one place where the VP ruled by fear and only directed by yelling.
Having been a manager - so naturally you feel what you did was hard. However - my basic premise remains: you made nothing physical or intellectual - but rather reacted to what was given to you. Example: Tasked to lay off people - basically, you just do it. Arguments occur - you need to settle them. Protecting your team - what is expected (and also, it improves their creativity and thus makes the manager look better). Wait - before you vote me a "1": All of the above might be irksome, but you can simple declare your intentions (that's what 'just do it' implies). You say such and such will happen and move on. Creating (an application, for example) takes planning of multiple facets that all must integrate correctly - every time you use them. To this, add that they must do so efficiently. Adding a little more to the decoration is making reasonable allowances for extensibility. Assuming you already have 100% of the skills required - which is rarely the case. So, learning is thrown in to this. And, unlike the items you describe in your reply - some or all of what you're doing may have no close prototype upon which to model your solution vs. the event you describe (layoffs, interpersonal interactions, and manning the barricades) - which are all well established (time honored?) scenarios in the world of management. Templates exist for the response - plus, unlike creativity - as a manager, you can declare a solution!
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
-
But the overall design still has to have a sensible foundation. I think you say that in your message, but it's being lost in the rest. If there are multiple develoeprs invovled, having a clear picture of where you are going and what the goal is will save time and duplication of effort. I like the concept of short, plannable sprints and being able to get better at time estimation. I think those are valuable skills -- but not without the planning and business analysis first. Joe
Of course. Running around not knowing where you wanna go means you'll end up running in circles and I've seen that all too often. If a building were built the Agile way - as some people see it, it would probably be something like a sky scraper built on the foundation of a little cottage, with no elevator, because in the beginning we thought just stairs would do, and so on. It would collapse. Every project without a clear-cut vision on what's to be accomplished is bound to fail, whatever development method is used.
-
Having been a manager - so naturally you feel what you did was hard. However - my basic premise remains: you made nothing physical or intellectual - but rather reacted to what was given to you. Example: Tasked to lay off people - basically, you just do it. Arguments occur - you need to settle them. Protecting your team - what is expected (and also, it improves their creativity and thus makes the manager look better). Wait - before you vote me a "1": All of the above might be irksome, but you can simple declare your intentions (that's what 'just do it' implies). You say such and such will happen and move on. Creating (an application, for example) takes planning of multiple facets that all must integrate correctly - every time you use them. To this, add that they must do so efficiently. Adding a little more to the decoration is making reasonable allowances for extensibility. Assuming you already have 100% of the skills required - which is rarely the case. So, learning is thrown in to this. And, unlike the items you describe in your reply - some or all of what you're doing may have no close prototype upon which to model your solution vs. the event you describe (layoffs, interpersonal interactions, and manning the barricades) - which are all well established (time honored?) scenarios in the world of management. Templates exist for the response - plus, unlike creativity - as a manager, you can declare a solution!
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
Balboos wrote:
However - my basic premise remains: you made nothing physical or intellectual - but rather reacted to what was given to you.
As a programmer I code to the requirements given to me. Even when I create the requirements the source is someone else.
Balboos wrote:
Having been a manager - so naturally you feel what you did was hard.
Odd comment. Are you suggesting that either you haven't been manager (not in a significant capacity) or that you were and that you found it easy?
Balboos wrote:
Creating (an application, for example) takes planning of multiple facets that all must integrate correctly - every time you use them. To this, add that they must do so efficiently. Adding a little more to the decoration is making reasonable allowances for extensibility. Assuming you already have 100% of the skills required - which is rarely the case. So, learning is thrown in to this. And, unlike the items you describe in your reply - some or all of what you're doing may have no close prototype upon which to model your solution vs. the event you describe (layoffs, interpersonal interactions, and manning the barricades) - which are all well established (time honored?) scenarios in the world of management.
Well most of the managers that I have worked for in software development and certainly all of the good ones, were responsible and drove such things as planning the deployment, allocation of tasks, tracking and often determination of missing functionality (even unasked for such as user manuals), pushing back on schedules and deferring functionality based on scheduling. There are probably other areas along those lines as well. I certainly consider all of that productive, useful and required for single deliveries and ongoing operations as well.
Balboos wrote:
Templates exist for the response - plus, unlike creativity - as a manager, you can declare a solution!
Getting two ill-tempered yet crucial members to work together after both have declared that they will never work with other person again not only saves a project but is certainly seems creative to me.
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
Christopher Duncan wrote:
In other words, Agile appears to be little more than an excuse to make us comfortable with the fact that we don't get the time we need in the real world to do things the right way in the first place.
I too have been around long enough to see many changes in how computers are programmed. I've noticed a general theme through all this, which is to produce running code faster. Running code is the only salable thing produced, so that is where the emphasis is. Software design doesn't sell products. Writing bug free code doesn't sell products. Neither gets any attention unless they go wrong and prevent software sales.
Christopher Duncan wrote:
isn't Agile just a justification for bad business practices?
Agile is only the latest fad in how to get to running code faster. It isn't about getting to an end result (i.e shippable product) faster, which is what it is being touted as, because everybody knows iterations of rewrites will be slower for a given end result. So, Agile as a process is all about managing the managers -- they can't provide a detailed set of requirements up front, so they lower their risk by asking for iterations of implementation. This way, they can redirect the end result along the way. It also gives them confidence that progress is being made because they get periodic tangible drafts in their hands to evaluate, each one a little closer to the desired end result. Is that bad business practices? It depends on what you need out of the software development process to produce a salable product fastest given what you can (or will) put into it. I see Agile as one of the best design fads to come along because it (finally) recogonizes that software design and implementaiton isn't an ivory-tower sort of effort (tell me every little detail about what you want, I'll go away and give you the finished result when I'm done), but a collaboration between many parties (tell me what you know now, I'll make up a draft and we'll discuss from there).
patbob
-
Christopher Duncan wrote:
Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front.
I think the root of the problem is not a development process (agile or not) but the fact that in many organizations people with no background in software development somehow think they can manage software projects. I am not sure what is it about software development that make everybody think it is easy to manage. I know I would not dare to manage a hospital, for instance, or a bank.
Yes, I don't much care which development methodology is flavour of the month either. As long as it is done properly, it is not the main issue. I agree completely with your point about people with no development experience running projects. <rant>The best they can do is to be book-keepers of the project - filling in task percentage complete reports and updating project plans, critical paths etc. This sort of thing tends to become a joke - I've been on a few projects with clueless managers where the tasks end up 90% complete half way through and stay that way until the last day when they jump to 100%! They can't guide the direction of the project because they have no idea themselves. Obviously they can't offer design advice. Another area where they fall down is where the team disagrees about how something should be done. They can't make a decision based on their own experience; all they can do is hope that the guy who has the loudest voice is right. Or they take a vote. You then tend to stagger from one ill-informed decision to the next. Over time, you get a series of inconsistent, arbitrary choices which produces an badly integrated application. </rant>