Source Code is the Design|Future of Agile

This article is mere attempt to visualize the potential of technology if handled right way .

Leadership is a skill which can be accumulated by someone who code or someone who design small piece of software or overall enterprise architecture .From west to east we developed stereotype that someone who is leading or managing doesn't need to code or configure so they are not supposed to either talk technical or do technical .

That stereotype is the actual cause of cash burn in your technical budget ,those who have potential to create things ,modify things can also sell things for you and eventually lead you business vertical with better returns ,what we need is to train them if needed and assure that everybody who is dealing with customer is working on core product rather than speaking powerpoints .

Coming to actual context of the article :

When we hire a professional to do something for our business, it's a mistake to assume he that need to justify his techniques with us , frankly, if we have the competence to recognize the ones matters, we wouldn’t have wanted him inside the first place. The problem isn't always builders now not communicating, it's commercial enterprise humans questioning they can recognise the ones matters by analyzing a few documents and heading off the fact that they don't have the necessary context to have the ability to speak with the developer to make technical selections. Technical selections, architecture, etc, aren't their choices to make, they're the builders and they can’t sell or do management tasks .

If we ought to draw an analogy among a manufacturing product cycle and a programming product cycle, the programming activity has similarities to the Design Phase, even as the compilation is analogous to the manufacturing phase. Note that compilation is practically free, as opposed to the manufacturing segment in a production product cycle.

A software developer is eventually an artist than assembly line worker, since they're designing, writing and delivering code which is most critical aspect of technology they can manage to partilly work on code. It takes time, consideration, and in some cases, a bit of skill. Creation cannot be rushed. Throwing extra humans into the design mix may be counterproductive, unless one of them takes the reigns and becomes the architect. More people may be helpful to get the work finished, however first you must determine what desires to be finished in phrases of the layout.

The synthetic line among programming and design causes top notch waste. Everyone thinks that software is intrinsically different. That it requires a totally different technique from some thing else in engineering. It isn't different, we simply misunderstood it. We believed that coding and testing were not part of layout. They are much like prototyping on a breadboard. Part of design.

Actual trouble is that layout isn't truely a beneficial hobby in software program development, and to say "The Source Code Is The Design" is making an attempt to apply semantics to gloss over the problem.

I feel that is an critical difference if the intention is to put off the "layout" level from the software development process. Rather than being fearful of being accused of "no longer doing layout", we need to turn the debate round to be "Why should we do design?"

Some developers truly like to "design" and document - and there's cost in that. Design is the sanity check and collaboration that happens on a white board, the reduction of logic from a big K-map(yes - these apply at times - does absolutely everyone remember what they may be?) to a code method, and the element you do whenever you get out pencil and paper to paintings a hassle because the IDE in front of you doesn't allow for it. There is also value in moving fast to code for an experiment.

Overall conclusion of entire story can be drawn from below points :

1.    We are shifting in age of Holacracy and whatever core business we are into ,we should try to have people involved in technical aspects of business positioned in customer centric and management role rather than having developer who don’t know management ,IT worked who don’t know coding and management who is not active in technology .

2.    Break existing silos that people in management is not supposed to be handson or handson folks can’t contribute to management .

3.    More layer we establish more frugal the scenario will become .

4.    In most of the scenario we get delivery limited upto the extent where management can visualize because view of original creator mostly get either ignored or not heard.

5.    Experience is required to create better things not to manage people 

When we hire a professional to do something for our business, it's a mistake to assume he that need to justify his techniques with us , frankly, if we have the competence to recognize the ones matters, we wouldn’t have wanted him inside the first place. The problem isn't always builders now not communicating, it's commercial enterprise humans questioning they can recognise the ones matters by analyzing a few documents and heading off the fact that they don't have the necessary context to have the ability to speak with the developer to make technical selections. Technical selections, architecture, etc, aren't their choices to make, they're the builders and they can’t sell or do management tasks .

If we ought to draw an analogy among a manufacturing product cycle and a programming product cycle, the programming activity has similarities to the Design Phase, even as the compilation is analogous to the manufacturing phase. Note that compilation is practically free, as opposed to the manufacturing segment in a production product cycle.

A software developer is eventually an artist than assembly line worker, since they're designing, writing and delivering code which is most critical aspect of technology they can manage to partilly work on code. It takes time, consideration, and in some cases, a bit of skill. Creation cannot be rushed. Throwing extra humans into the design mix may be counterproductive, unless one of them takes the reigns and becomes the architect. More people may be helpful to get the work finished, however first you must determine what desires to be finished in phrases of the layout.

The synthetic line among programming and design causes top notch waste. Everyone thinks that software is intrinsically different. That it requires a totally different technique from some thing else in engineering. It isn't different, we simply misunderstood it. We believed that coding and testing were not part of layout. They are much like prototyping on a breadboard. Part of design.

Actual trouble is that layout isn't truely a beneficial hobby in software program development, and to say "The Source Code Is The Design" is making an attempt to apply semantics to gloss over the problem.

I feel that is an critical difference if the intention is to put off the "layout" level from the software development process. Rather than being fearful of being accused of "no longer doing layout", we need to turn the debate round to be "Why should we do design?"

Some developers truly like to "design" and document - and there's cost in that. Design is the sanity check and collaboration that happens on a white board, the reduction of logic from a big K-map(yes - these apply at times - does absolutely everyone remember what they may be?) to a code method, and the element you do whenever you get out pencil and paper to paintings a hassle because the IDE in front of you doesn't allow for it. There is also value in moving fast to code for an experiment.

Overall conclusion of entire story can be drawn from below points :

1.    We are shifting in age of Holacracy and whatever core business we are into ,we should try to have people involved in technical aspects of business positioned in customer centric and management role rather than having developer who don’t know management ,IT worked who don’t know coding and management who is not active in technology .

2.    Break existing silos that people in management is not supposed to be handson or handson folks can’t contribute to management .

3.    More layer we establish more frugal the scenario will become .

4.    In most of the scenario we get delivery limited upto the extent where management can visualize because view of original creator mostly get either ignored or not heard.

5.    Experience is required to create better things not to manage people .