What do you do when one thinks the code isn't complicated enough? [closed]

Question

After six months of development on a project, our stakeholders have had a "gut check" and have decided that the path that we've been walking (a custom designed application framework and data access layer) is holding us (the developers) back from quickly developing the features they would like to see. After several days of debate management and the development team have decided to scrap the current incarnation and start over using ASP.net MVC, with Entity Framework as the bases of the a 'quick and dirty', lets just get it done project.

In days following, our senior developer who has never worked with MVC or Entity Framework has finally gotten into a sample project and done some work. His take on ASP.net MVC, "this is not software engineering".

So my question is this; what do you do, when one doesn't think the code is complicated enough?

Answer 1

That's a ... problematic view.

It's akin to someone saying, "I shall only use flint to start a fire." as you show them a lighter.

The stakeholders are right: They want to see value. As programmers, we're there to provide value -- not reinvent the wheel so we can feel like we're 'roughing it'.

They're paying your checks: If your complicated way isn't going fast enough, un-complicate it. There's enough complication in this world without developers adding more just to feel important.

Answer 2

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. - Alan Perlis

Simplicity is great. To strive towards a more complicated solution just baffles me to be honest.

Answer 3

I can empathize with that senior developer. When I did web development in the late 90's, frameworks were practically non-existent, and starting from scratch was the most commonly accepted practice, unless your company did a lot of the same kinds of websites for different clients.

I recently decided to update my skills (my day job is embedded software), and designed a web site for my sister-in-law's photography business. I started with Drupal, and although I expected the experience to be different, I wasn't prepared for how startlingly different it was. It felt mostly like installing and configuring rather than developing. I was almost done before I wrote a single SQL query, and even then, I only wrote 3 total.

However, rather than view it as a negative, I took it as a good thing. Rather than focus on making the basic functionality work, I was focusing on what made the site unique. After I passed a certain learning curve, when a feature would occur to me, it was often a 10-minute job to put it in, where the old way it might have taken days to get right. As a result, the site is of much higher quality than it would have otherwise been. It's not that I'm not being challenged, it's that my challenges are in the more interesting parts of the design rather than reinventing mundane functionality.

Your senior developer's mistake is in not considering solutions like this in the first place. It might take a little longer to learn to customize up front, but the payoff comes quickly.

Answer 4

"My aim is to make things as simple as possible, but not simpler than that." -- Albert Einstein

"When deciding between two models which make equivalent predictions, choose the simpler one," -- Restatement of Occam's Razor

In other words, there is inherent utility in simplicity and one should not attempt to inject complexity and muck it up.

Answer 5

Complication should be something you strive to stay away from, not encourage or go after.

Answer 6

Given that you are six months into the project, I take it the problem is reasonably complex. So complex in fact that your team hasn't delivered a solution. Do you need more complexity?

Unfortunately, I think your lead is sadly mistaken about what software engineering is about. Good engineers use as many standard components as they can. How they put them together may be unique. When necessary they will design custom components.

I have a few rules I live by when designing and building things.

Steal from the best you can find: You do it every day with all your tools (unless you coded them yourself). The more of the work you get already done the more productive you can be. Its a very strange day, that I don't rely on the work of others.

Stand on the heads of giants: There was a time we did everything in machine code or assembler. Then someone invented language compilers and more languages. We stand on the the shoulders of those who have gone before. Many thanks to those who designed and built the tools we use. Now we have MVC that builds on top of other tools, and simplifies a new range of problems.

Keep it simple stupid: Things you find complex now will become incomprehensible when you have to fix it in a couple of months. (I've been there.) The human mind can only keep track of about 7 things at any one time. When you are programming that includes how you got there, where you are going, what your are doing, and what you need to do. It doesn't leave a lot of room for extra complexity.

Answer 7

Unlike other answerers and commenters, I will not suggest you to leave or to make the lead developer fired. This is normal. Programmers are used to challenges, and they do not like not having them.

The answer to your question "what to do?" is "keep working". Explain your lead that when a task is complex enough, a more powerful tool requires a more powerful worker. Here are a couple of challenges you face using a powerful framework.

• Leaky abstractions. The framework you develop abstracts away a lot of things you liked to play with? Yes, the but what will happen when these abstractions will leak, when something goes wrong—and you won't be able to figure what outright?

  Crushing through all the framework and components code and infrastructure that lies below your abstraction is a challenging task, and does require a lot of experience. Aside from the linked Joel's article, a simple example: a stacktrace in Ruby on Rails web framework may easily reach 50 function calls. Doesn't look so simple, does it?

• Keeping it simple. Yes, sample project doesn't look like a challenging task. A simple program looks simple in any language. You get used to such a simplicity, but when it gets more complex, keeping your code as simple as in the sample project becomes a challenge.

Answer 8

So, what is software engineering according to your dev lead? (-:

Since you're on the "quick and dirty lets get it done" path, you may not have the luxury to worry about code complications or debate the existentialism of software engineering.

If it works, it is good.

Good luck,

KM

Answer 9

Your question is missing the point.

Your stakeholders aren't getting the value they believe they should be able to get. This is normal. Everybody wants more for less.

However, the team should always be looking at getting more for less and figuring out what the stake holders really need. A better question might have been around the needs, how your framework is meeting the challenge of providing those needs and recommendations to better provide the value that is desired.

Answer 10

Your phrasing of the question assumes that the Sr. Developer's only complaint is that the new framework "isn't software engineering" and that he's looking for more complexity. Given this premise you're only going to get answers that reinforce your point of view; of course people are going to say that complexity is bad.

That might be absolutely true but I would say the first thing to do is make sure you correctly understand the Sr. Dev's point of view. He might actually be saying "this isn't going to let us fulfill all the requirements" or "we will quickly hit a wall."

Answer 11

To answer your stated question: Tell them they are crazy, good code should be simple parts adding up to a complex but not complicated structure.

To respond to your situation: I too have been in a similar situation where management could not see that a little bit more time spent now would save much more time later. I overcame it through, what should not have been, a difficult and long meeting explaining this.

Answer 12

I dont know anything about ASP.net or its frameworks, and you dont say what language you are currently using. But in a general sense, I suspect that if you couldnt make headway before, adding a framework isnt going to magically change things. Especially since you are stepping backwards and starting over.

And unfortunately, 5 years from now you'll probably still be maintaining that 'quick -n- dirty' solution.