IT Departments :: Behind the beards

[ZX9RCAM]

I like coconut pie....

 

[cdb]

I blame the fanatically religious following of Agile (virtually zero actual design process) software methodology, and massively bloated "frameworks" that add 100's of megabytes of code so some lazy ass developer can accomplish a task with 1 line of code instead of 2-3. :/

The presence or lack of design is largely orthogonal to the process. It's much more a characteristic of the values of the business and the abilities of the development team, in my opinion. Well run Agile necessarily will incorporate design as part of the process, just as poorly run traditional process can neglect it. On the other hand, there should be pressure against over-design built into the process, which is more inherent in Agile processes.

I think the same of minimizing written code; most developers in my experience are more than happy to rewrite every available library to suit their particular tastes. It's typically the business that doesn't want to foot the cost of development and maintenance for all that code. Usually that's the right choice.

 

[cdb]

Do you know embedded systems well? If you do, may I contact you next year with a firearms-related project I'm working on? I will soon reach the stage where I need a formal meeting with an embedded systems expert who has some basic knowledge of shooting.

Sounds interesting, please share more about it if/when you are able to.

 

[Brains]

The long and short of the "Agile" buzzword, is that it's really the same thing businesses have been doing forever anyway. Used to be called "just get the shit done" though. Some people work very well in an "Agile" environment, some just can't do it. Probably why in modern buzzworld it's such "a big deal."

One of my past developers just couldn't be Agile. This person was a VERY slow developer to begin with, but without clear limits and guidelines would feature or code creep projects into never being released. What was worse, is when presented the opportunity to work using an Agile methodology, the code quality was atrocious (e.g. 7 method calls across 3 classes to do something as simple as email an already populated invoice instance). This particular dev could not handle full projects well at all, yet would get resentful when work was assigned in smaller, more clearly defined tasks.

Another current developer I have, works incredibly well with nothing more than a concept. This person can gather end user requirements, digest them, apply them to business processes, identify areas for improvements, design, develop, test and deploy a complete app in very short order. This person's end user followup is also incredibly good. A unicorn.

 

[CyberWolf]

Another current developer I have, works incredibly well with nothing more than a concept. This person can gather end user requirements, digest them, apply them to business processes, identify areas for improvements, design, develop, test and deploy a complete app in very short order. This person's end user followup is also incredibly good. A unicorn.

That is indeed rare, particularly if they're able to incorporate solid defensive capabilities & security/bug testing (including proactive avoidance/remediation) into their process...That's rare stacked on top of rare.

 

[benenglish]

This person can gather end user requirements, digest them, apply them to business processes, identify areas for improvements, design, develop, test and deploy a complete app in very short order. This person's end user followup is also incredibly good.

Where process analysis and design fail, money gets wasted no matter how good the developers are. Along the lines of your guy -

My former employer had a project going to automate the work processes of a particular field position. After three tries and three miserable failures spread over more than a decade and wasting 10s of millions of dollars, the powers-that-be did something that seemed radical to them. They, quite literally, polled the user base for Officers who liked computers. They pulled a bunch of field enforcement Officers out of the field, put them through coding classes, then let them write the software. After 3 years of testing, the rollout to every employee took another 3 years.

Again literally, using the correct definition of that word, the user base was so happy with the software that many Officers on the cusp of retirement withdrew their paperwork and stayed on the job. The new working environment automated so much drudgery that the increase in productivity made it look like we had tripled our staff.

If you have a developer who can do all the stuff you listed, you're lucky. We found out the hard way that without the first few steps you listed, the best developers in the world will produce garbage. And if you have those things, new developers can (at a slow pace, I admit) produce functional art.

 

[Brains]

You scored a direct hit on a point I didn't actually make - experience in the process itself did play a role here. The two people I outlined had very different approaches and experiences with regards to the processes they were writing software for. The first dev took a "poll the users" approach, attempted to understand, and wrote the apps from their own point of view. The second dev took a "first, I'll insert myself into the work" approach, and learned what it was like to actually perform the work using the current methods. Both felt they "understood" the process, but clearly the second one understood it in a much more intimate and thorough manner. Personality wise, the first was quick to proclaim themselves as an expert. The second, as ignorant and open to learning.

 

[DD130]

The long and short of the "Agile" buzzword, is that it's really the same thing businesses have been doing forever anyway. Used to be called "just get the shit done" though. Some people work very well in an "Agile" environment, some just can't do it. Probably why in modern buzzworld it's such "a big deal."

I've only had experience with Agile since 2005, spanning several industries and organizations (from public health to start-ups), so I'm not any sort of export (although I did say at a HolidayInn Express).

IMHO, the traditional Agile as taught by it's "creators" is very light on design, and heavy on "stories" and narratives. The "Just get it done" franetic throttle-to-the-firewall, nature of startups is the antithesis of Agile and all it's overhead (aks ceremonies). Management told me to stop keeping track of how much of our sprint was spent talking about our sprint, not actually producing any work.. LOL.. ignorance is bliss I guess).

Just for kicks, a couple of years ago, when the F-35 was in the throws of major software problems and delays.. I decided to look at Lockheed's job descriptions for software engineering. The *first* item on the skills like as Agile experience (is that really a skill??). LOL.

I guess you can categorize me as one of those people that "doesn't work so well in the Agile methodology" (it's not a framework.. right?). I prefer to have actual specs, real use cases, dedicated designers and architects and not have to stand around every day for 15 minutes when a simple e-mail would have accomplished the task of keeping people abreast of the projects (we of course have project tools that anyone in management can open and see where things at). I'd weird that way; I'd rather be getting the work done that standing around talking about getting the work done.

 

[ZX9RCAM]

I'm not very agile, I have bad knees, and screws in one ankle....

 

[cdb]

The long and short of the "Agile" buzzword, is that it's really the same thing businesses have been doing forever anyway. Used to be called "just get the shit done" though. Some people work very well in an "Agile" environment, some just can't do it. Probably why in modern buzzworld it's such "a big deal."

Ah, you been mislead. That ain't what Agile is.

 

[cdb]

I've only had experience with Agile since 2005, spanning several industries and organizations (from public health to start-ups), so I'm not any sort of export (although I did say at a HolidayInn Express).

IMHO, the traditional Agile as taught by it's "creators" is very light on design, and heavy on "stories" and narratives. The "Just get it done" franetic throttle-to-the-firewall, nature of startups is the antithesis of Agile and all it's overhead (aks ceremonies). Management told me to stop keeping track of how much of our sprint was spent talking about our sprint, not actually producing any work.. LOL.. ignorance is bliss I guess).

There's a lot of truth to that. Most early-stage startups don't have the development team maturity (or size for that matter) for even a lightweight process to make sense. But once there's a defined product and customers a business need for visibility and predictability in development work that's where a lightweight Agile process helps.

It's a shame that Agile has gotten a reputation for being high-overhead and cermonial, though. It wasn't so in the old days (around '99). What passes for "modern" Agile process now seems to have given up most of what originally made it effective, apparently in order to make it easier to do. Which is great for the consultants selling it but not so much for the business or the development team.

It doesn't have to be light on design though; there's still a place for architecture planning and design at lower levels. But the design tends to be more evolutionary, which is a good fit in environments with changing requirements.