Welcome to the Lounge

MSBassSinger wrote:

A team of this design would retain the benefits of agile without becoming mired in the bureaucracy that plagues many agile teams and processes today.

MSBassSinger wrote:

the bureaucracy that plagues many agile teams

MSBassSinger wrote:

Less time spent in meetings.

MSBassSinger wrote:

by a senior-level software engineer with the business, management, leadership, and people skills necessary (as well as hands-on coding) provides these benefits:

Quote:

developers with all those skills are pretty rare

I could not agree more with the author.I have over 20 years of experience in IT, and consider myself as such a senior-level software engineer.
Although some recruiters don't consider me as being a senior-level engineer, as I am not up to date with all latest "hypes",
I am quite successfull in almost all my projects.
Part of the secret is my project time distribution:
- I first spent quite some time with the customer and let him explain - in his own way - what he expects.
As I can actually code myself, I immediately can match the customer expectations with the budget and the possibilities.
In my experience this saves an enormous amount of time and money, and prevents the customer from having irrealistic expectations.
- At startup of the project, I prepare the different environments(dev/QA/testing), or let it be done by some experts
- then I spent 20% of my time to real coding. No diagrams, schemes, or other time consuming operations: 
this code setup is going to be actually used by my collegues "junior/medior" developers later on. 
(by god, I hate that distinction Junior/Medior/senior/Lead Developer)--> consider this as setting up the code structures (Interfaces)
- I present this code setup in a POC to the customer and have some feedback.At preference, I like to do this with some keyusers of the client.
If this is not possible, I warn the client about the risk that the users might eventually not be happy with the end result.
- Once this is done, my collegues start working out my code structures, and I spent time on making analysis,estimations,some raw documentation and presenting the plan to the customer.Here the customer gets another chance to express any wishes he has.
He can also still alter some stuff with very little overhead.Once again, because I know the code, 
I can make good estimations on the possible impact of this changes.I also warn the client if some modifications would impact the budget.
- After this phase I go in "support" modus:
	- I help my collegues with the code if they have issues
	- I revise code
	- I write documentation
	- I keep in close contact with the customer
	- I prepare the test scenario's
-	
- And also after project is finished, I reserve some time for feedback/follow-up/maintenance

When I am overloaded/incompetent on a task, I ask help from specialists.
In my experience, meetings are necessary, but only when there are issues or feedback is needed.
When there is significant progress, you can also have follow-up meetings.
And meetings should not take more then 1 hour- never...
You don't really need Agile methodology.
-	You need continuous feedback from your client(and he is allowed to express it in any way he wants)
-	You need to give continuous feed back to the client about budget and progress.
-	You need a well crafted design.(=motivated, skilled professionals)
-	You need flexibility as different skills are required during the whole project life cycle : as you can see, I do lots of different things.
And yes, some people are better in one or another niche, that's why I call professionals when I need help.
-	You need to be able to make proper time/budget estimations: In my humble opinion, 
only the people who can actually do the coding, are able to realistic time estimations
-	You need your applications to log as much as possible in Dev phase, but in production you only need an extensive log when errors occur(buffered logs are your friend;)
-	You need to cut on time consuming operations as much as possible, as there are:
	-	No scheduled Meetings, only when needed
	-	Schemes, designs : make them once you really grasp the needs of the client
	-	Documentation: is necessary, but inline documentation (like XML style in VS), is far more efficiënt.
		For instance: screenshots are very explanatory, but also very time consuming, and when the GUI changes, you need new (time consuming) screenshots
Sorry for the long reply, but the author really is expressing my sentiment, and he hit a nerve ;-)

Gary Wheeler wrote:

This is where it got really old school: I actually printed four pages of code to look at, all at once, on my desk. I haven't done this in years. I wish we had some green bar[^] for our office laser printer to make my nostalgia complete.

Gary Wheeler wrote:

I actually printed four pages of code to look at

Gary Wheeler wrote:

This is where it got really old school: I actually printed four pages of code to look at, all at once, on my desk.

Marc Clifton wrote:

that was one C# method

Marc Clifton wrote:

flowchart