6

I apologize in advance if the question is not directly involved in programming but I could not find a forum of programmers who deal with general questions.

I am developing a cross-organization application. For a person that has no programming knowledge at all, the final product looks fairly simple - a desktop application with a business dashboard.

But the App is much more complicated than that.

  • the database is "fed" by users who use the application (a lot of forms to enter validated data).
  • all company structure objects are modular and must be flexible to all changes in the company units hierarchy.
  • business logic is very complicated - there are complex parameters to show like sales or revenue goals that are affected by multiple parameters and calculations.
  • GUI must be good-looking and good UX design is a must, including a lot of multithreading stuff, also because its Winform platform, there are not many libraries to use so i am writing all the graphics and animation by myself.
  • a lot of other stuff like connecting to company AD, modules that print data to excel files, bugs, QA, memory and efficiency issues..you know the business..

I am developing the project by myself including the environment of servers, communication to all users IPs etc.. I believe I am an agile programmer but as you know development takes time...

ok after all that heart-rending story here is my question:

My manager doesn't have any programming knowledge and she thinks that I am taking time and not working hard enough.
I tried to explain her why it's taking time, why I should not hardcode a program in order to reduce development time, how structures are translated to OOP objects and the time it consumes.
But she wouldn't understand and thinks I am not telling her the truth about the real development time needed.

Please give me advice, how can I explain all of that to a layman in plain English?

  • 2
    What was the business question you got to develop this app? I suppose you did not make up all those features by yourself so there will be some kind of list of functionality like a kanban board, a plan or even just a meeting upfront? It feels a case of expectation management where the project may have been getting bigger for example. – Luc Franken Sep 23 '16 at 13:49
  • 1
    you may also want to ask your question on Workplace stack exchange site (workplace.stackexchange.com), with question focus more on how to work through this with your manager. Your issue is you have a skilled trade that is not immediately apparent to the onlookers (your manager) and you are seeking ways of how to convey that you are indeed working – Dennis Sep 23 '16 at 13:56
  • 6
    Your manager not having any programming knowledge and on top of that not trusting you is a huge red flag. I don't know much about your current situation but these situations rarely end well.. – Alternatex Sep 23 '16 at 13:56
  • 2
    First of all, don't offer the layman "hard-coding" as a way of speeding things up! You're already doing agile, so of course you are not doing any YAGNI, and you are doing refactoring as needed. But no need to explain these things to a layman, instead concentrate on the rich features they want and show that they are more complex than simple hand waving words. – Erik Eidt Sep 23 '16 at 15:31
  • 4
    I don't think it's necessary to even mention OOP. What you want is robust, maintainable software (I hope your manager knows what those words mean). OOP may be a way to achieve that, but introducing technical jargon is not going to help your case. – gardenhead Sep 23 '16 at 15:40
7

Organize a meeting. Involve a few more people than just your immediate manager just as 3rd party observer.

Explain in very conceptual terms what you are doing and how long it will take, and explain options.

For example:

Dear Manager & Co, you have expressed that you are seeking to build a Business Dashboard and to you the end product look simple. But to build it it is not so. I need parts A, B, C, D, and they take respectively 1 month, 2 month, 4, month and 8 month to build.

There are also 2 approaches to building software: Hardcode and OOP.

Hardcode will make it work sooner but it will create a lot of problems for me and other programmers down the road. This phenomenon is so frequent it got a name of Technical Debt.

OOP will get you the product in X amount of time longer, but it will be much easier to modify and change it to your needs over a longer period of time.

Use analogy, for example .. it may take you faster to build a ladder to climb on top of 2nd floor building, but ladder cannot hold two persons at once and will break. It will take you a lot longer to build stairs to the 2nd floor, but many people will use it for a long time. It is a lot easier to maintain stairs in the long run, because the structure is sturdy, while ladders have to be fixed more often from wear and tear because they are just planks hammered together with nails.

Now with that information what product do you want and how well-built do you want it?

In the end, manager will have to

  • trust or not trust your judgment (you are the expert, she's not)
  • make a choice (Hardcode with technical debt or OOP)
  • hire or not hire more programmers to help you

To summarize you have to

  • explain in conceptual terms (without too many details) what you are tasked with to do
  • trust your manager to trust you (or get out)
  • ask for what the manager wants you to build, once they have knowledge of their options

Also, have a good idea on time estimates of how long it will take you to build parts of software using this or that way, and why, and be prepared to answer questions about it. It may help you to put together a document on proposed software features and approximate time and complexity that is involved into making them happen.

And also, you are the expert and you can refuse (or not even mention) that there are deficient ways to do the job. You can refuse to do bad work.

  • 1
    This a billion times ! The part about giving time estimation is crucial. OP should be 100% honest with this even if truth is hard to hear sometimes. It's his role as a professional developer to say what needs to be done and how long it will take. By the way, OP should really insist that the procedural way is simply a bad idea. There should be the option of giving a MVP that will work soon, but will only be an alpha version. That helps managers handle the customers easily. – Steve Chamaillard Sep 23 '16 at 18:50
  • 1
    thanks! and good point! you can actually refuse work when asked to do it incorrectly for a particular task (and you may have to be prepared to find other places of employment when you do). But you also need to be flexible, and work with the goals and realities of the business. – Dennis Sep 23 '16 at 19:17
  • 4
    Is hardcode the opposite of OOP now? – Tulains Córdova Sep 23 '16 at 20:59
  • 1
    One more thing: mention that the better coding approach will not make all future work magically disappear.Don't create false expectations. Instead, sell the ability of the better approach to adopt to new thingsIf the stairs are built and there's a new employee in a wheelchair, he will not be able to get into the second floor. However, while it requires further work, attaching a lift thing for wheel chairs to regular stairs is actually possible. Then stop talking. Switch to your last slide which shows a guy in a wheelchair next to a ladder leaning against a building. Then end your presentation. – null Sep 24 '16 at 18:12
  • This answer assumes the boss wants the "hardcoded" solution (whatever that means) and the OP have to convince the boss to chose the "OOP"-solution. But it is not clear from the question that the boss have said anything like that or even knows there is an option. It might well be the boss wants the maintainable solution with low technical debt, but just want it delivered faster with fewer frills, or want more transparency into the schedule. – JacquesB Sep 24 '16 at 21:36
6

Don't try to explain or justify technical design decisions for a non-technical manager. You should not bring up terms like hard-coding or OOP. Trying to explain OO design principles and so on to a layman with no technical background will get you nowhere.

It is not even clear from your question if this is about "OOP" versus "hardcode" (whatever that means) at all. For all we know she might still think the "quick and dirty"-solution would take too much time, or maybe she wants the maintainable solution, but thinks your are not working enough hours and spending your time on Facebook.

You need to listen before you start teaching. It is typical developer mentality to think any disagreement must be because the other part simply does not understand, hence "how do I explain..". But it is not clear you have made enough effort to understand the reason for your boss dissatisfaction.

Before anything you need to understand why she don't have trust in you. Since you are the sole technical person she need to trust you with technical decision, so you need to figure out why you have lost this trust and what you can to to gain it again. An organization simply cannot work if a non-technical boss does not trust the technical lead with technical decisions.

You need to ask her. What is her grounds for thinking you are taking too much time? Does she think you are slacking off, or does she think you are over-designing and need to do less work? What is her frame of reference for how long she believe a task should take? Does she have experience with other developers on similar projects? You need to understand this before you can respond.

It is possible you have a manipulative boss who is trying to shame you into working harder or take unpaid overtime. It is also possible she have legitimate concern due to bad communication or lack of transparency in your development process.

  • You're right in the sense that non technical business managers are interested in business language and business case. Advantages/Inconvenience/Benefits/Risks. I can't however agree on the lack of transparency that you promote in the first sentence. Not explaining just creates lack of trust. A business manager might not understand all the technical arguments and not be interested in too many technical details. But they appreciate the effort, and will very well understand that there's a founded reasoning behind your suggestions. – Christophe Sep 25 '16 at 13:42
  • 1
    @Christophe: I don't consider it actual transparency to spout technobabble at a non-technical manager. Doing this could actually lead to the manager losing trust because it indicates the technical person is not able to rise above the purely technical level and does not understand business concerns. – JacquesB Sep 26 '16 at 6:52
  • i think the goal of this question is exactly to find the words that manager could understand – Christophe Sep 26 '16 at 7:06
  • @Christophe: Agreed, this is how the question is formulated. I just consider the question an "XY problem", because I don't think the solution to the OP's problem is to explain technical concepts to the manager. I suggest it is at least as important the OP try to understand the reasons behind the managers concerns. – JacquesB Sep 26 '16 at 7:53
  • 1
    ok, with that i can agree also :-) – Christophe Sep 26 '16 at 12:39
5

Firstly I do not see this as a conflict between hard coding (or rather quick-and-dirty) and OOP.

I am a proponent of OOP, but sometimes what is called for is not a long lived solution, sometimes quick-and-dirty is exactly what is called for.

Are you sure that your manager wants everything to be perfect? You really need to discuss what your managers expectation is, before you can discuss how best to achieve the goal.

Maybe your manager have been tasked to make a quick throw away prototype as a proof of concept.

If the goal is a long lived solution, then it is time to discuss how to avoid technical debt. For that a manager often needs to know about best practises not OOP.

  • In some situations, a manager needs to get the project "done" initially and will be able to push back on later requests that will take longer to complete due to technical debt. – JeffO Sep 23 '16 at 17:18
  • If I am the dev in charge of the development, I just don't want to be forced to throw stones on my own head. I know very well what is going to happen in a near future. I'm going to be asked to maintain the mess I have been forced to do and go crazy trying to hold a sand castle. Then I'm going to be again the "unflexible guy" that does not understand the company needs. And so on. There's no only a technical debt here. There's also a "career debt". My career is priceless no matter the company where I'am. Every time you accept to do things against your principles the only one in debt is yourself. – Laiv Sep 25 '16 at 17:45
3

I'm going to talk about some changes you may be able to make, not because I think you are in the wrong here, but because yours is the only behavior you have control over. I learned a long time ago that better arguments rarely convince someone. You need to change something in order to show them.

You mentioned you believe yourself to be an agile programmer. I don't know if that means you are practicing "agile," but I would recommend:

  • Making a user story backlog and sitting down with your manager to prioritize it.
  • Delivering incremental improvements every two weeks if not more frequently/continuously.
  • Having a demo of those improvements every two weeks.

In my experience, this feedback cycle and especially the demo can really change the dynamic. It shows that you are getting things working. You can showcase why it is an important step. It keeps you focused on actually finishing things. You get better at explaining the need for things in a way management understands. And management typically gains a better appreciation for the amount of work that goes into keeping the quality high.

It becomes sort of, "I'm proud of the work I did the last two weeks, so I'm inviting you all to a meeting to show it off," instead of the manager thinking, "I have to get status from him again. It feels like he's hiding something from me." Managers worry less about "behind" schedules when there is more transparency.

2

I'm going to make the assumption this question is just looking for a metaphor/explanation to someone who is not a programmer. Also, you drove this answer to work this morning.

I would explain to your manager that building a program is a lot like assembling a car. Most cars get built in factories by a team of folks, all using a similar set of patterns and conventions to arrive at the final product. Each of the parts of the car also made a certain way, so if its cheaper to get them from another place, you can without affecting the final function of the car (refactoring). Doing things this way makes it easier put on a body kit (change how the car looks), make it go faster (optimizing the engine), or put things like rocket launchers on it (weird, but adds a new function).

The other benefit to building the car like this is that if the car breaks down or gets in a wreck, you can take it to a body shop (front end developer) or mechanic (back-end developer) or the dealer (full-stack developer) to work out what broke and replace it easier or do easy things like change the oil (maintenance). Its worth emphasizing that the time put in up front during initially building the car is paid back in less time that you're stuck fixing - or worse rebuilding - the car after someone crashes it.

Compare that to a car that had entirely custom parts built very fast by a car builder who used custom parts and died all of a sudden. If he didn't follow rules or accepted conventions anyone else does, it could take years to unravel how the car's put together before you can even fix it when it breaks down.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.