How to provide value? [closed]

Question

Before I became a consultant all I cared about was becoming a highly skilled programmer. Now I believe that what my clients need is not a great hacker, coder, architect... or whatever. I am more and more convinced every day that there is something of greater value.

Everywhere I go I discover practices where I used to roll my eyes in despair. I saw the software industry with pink glasses and laughed or cried at them depending on my mood. I was so convinced everything could be done better.

Now I believe that what my clients desperately need is finding a balance between good engineering practices and desperate project execution. Although a great design can make a project cheap to maintain thought many years, usually it is more important to produce quick fast and cheap, just to see if the project can succeed. Before that, it does not really matters that much if the design is cheap to maintain, after that, it might be too late to improve things.

They need people who get involved, who do some clandestine improvements into the project without their manager approval/consent/knowledge... because they are never given time for some tasks we all know are important. Not all good things can be done, some of them must come out of freewill, and some of them must be discussed in order to educate colleagues, managers, clients and ourselves.

Now my big question is. What exactly are the skills and practices aside from great coding that can provide real value to the economical success of software projects? (and not the software architecture alone)

Answer 1

Agile Methodologies are so popular because they are so successful at delivering only those things that provide business value as quickly as possible. Anything that is done that does not provide business value, regardless how nifty, slick, cool or clever is a waste of money.

Focus on what is important

Developers aren't concerned with business value because they aren't business people, if they were they would have gotten an MBA not a CS degree. What the Agile Methodolgies like SCRUM for example is provide transparency, priority and direction to developers on what is important to the business while still letting the developers have control of the how part of development process, it cuts out all the time lots of developers waste doing and re-doing just for the sake of "hacking" or "it would be cool if" coding.

Engineer for the LifeCycle

Maintenance on Agile projects is much much much less costly than waterfall projects, because, maintenance is built into the process through the concept of Technical Debt, things that might not be ideal but expedient are documented and listed as potential work to be done later in the backlog, it is all tracked, prioritized and accounted for. Needless premature optimization, and writing code for features that are not requested by the product owner , thus don't add business value and don't get used or adds complexity for the sake of "design" cause more horrific maintenance problems than anything else. The great thing is if you get it right enough the first time there isn't that much maintenance to do later on.

Adding Value as a Legacy

Improving the process and culture is the only thing you can "leave behind" that will be of any lasting value. "Clean Code" that is the paragon of Design isn't going to survive first contact with a Junior maintenance developer, or even a Senior one in most cases. All code bases of any non-trival size devolve into a Big Ball of Mud through entropy eventually, this is inevitable. But changes in thinking, and process last from project to project.

Answer 2

I am not sure I fully understand your question (it is phrased a bit complicated), but I believe the most important is customer oriented attitude. It may be even more important than great technical knowledge and coding skills. A great programmer lacking customer orientation can easily put together a technically amazing, performant and rock-solid app - which just happens to do something completely different from what the client really wanted.

Programming is basically about translating fuzzy, unclear human wishes and ideas to machine-understandable - thus necessarily rigorous and constrained - form. A large part of this process requires people skills like communication, empathy, conflict management etc. Not necessarily all of us developers need these skills, but the more the better.

Answer 3

This is something I've rarely seen from consultants for obvious reasons. The best way to add value is to make themselves expendable for good reasons. e.g. Make their work understandable. Keep co-developers in the loop. Teach the co-developers proper techniques etc...

Answer 4

First the client has to be fully invested in the idea for any real value to take place. As developers we should be looking to solve the problems the clients are facing, or finding ways to enhance what they do. My view is that the average user spends too much time gathering data, whereas their real job should be using, or analyzing that data, not collecting it.

A problem in getting the client invested is the "field of dreams" effect. Often the clients don't know what they really want until something is built for them. That is why there are often so many requirement changes after the fact. The client doesn't get a grasp of what is possible until they see something concrete that they can understand.

A good developer will understand this, understand the client's needs, and try to anticipate what features will bring value that the client hasn't envisioned yet.

Answer 5

At my job, there are times to code(because the feature really needs to be put in), and times to justify not changing code(when the risk is no great).

It sounds to me like what has happened to you is that you changed from a programmer into an engineer. An engineer is not a code monkey. An engineer realizes the impact of what he does, and takes them into account before acting. I should say "good" engineer, I suppose.

Regarding the "secret" features/work. There are indeed times (and work cultures) where you know that Something Needs To Be Done to fix this, and you've spent a lot of effort getting the decision makers to buy-in that this work is needed. After first listening to you (or pretending to listen, anyway), they agree that they see your point of view, but they cannot justify the expense and risk of whatever it was you wanted to do.

You then go and do it anyway. Once you get it prototyped and 80% functional, you then reveal it to your colleagues and managers and decision makers, who, thinking of it as "mostly done, just needing a few tweaks" tell you to go ahead and finish it. Typically this sort of thing is done off-hours, and is pretty much about the only way that things normally improve.

Answer 6

"...it is more important to produce quick fast and cheap..."

More than just being a statement about the programming industry, I think you've pretty much nailed the mantra of our modern society.

Answer 7

The most important way to add value to a software effort is communication, not code.

Written Communication

• Does the project have a wiki? Is the first page of the wiki good, with a nice high-level overview?
• Has anyone talked to real users, and written down a summary of what they said?

Verbal Communication

• Can you serve as a technical sales engineer for the product, accompanying the sales team to answer technical questions?

Note: marking this as community wiki so other people can add examples.

Answer 8

Domain Knowledge

Working knowledge of the domain you are writing software in helps bring a great deal of business value.

• A developer at NASA having a background in Aerospace Engineering.