|
I have been (and still am) in a very similar situation, and I suggest that you avoid being "subversive" - I get the impression from your post that your boss likes to have his fingers in all the pies - so if he feels you are undermining him or taking your own path on this, he will move to block you, and you will find the whole experience even more frustrating.
If you can, find someone who has the boss's trust, convince them of the merits of your approach and the reasoning behind it, and use their support to convince the boss to allow you the leeway to get moving.
Once your champion is on board, pull together a small team, which includes this person, you, the designer, and at least one representative from the end users (you can change the representative(s) at different phases of the project). Start with the designer's layout, and start chopping it into discrete functions - as others have suggested, it's best to take an educator's role on this and let the users and the designer figure out the bulk of the issues, while you take notes, provide technical guidance and ask leading questions, when appropriate.
Most of all, provide the boss with regular summaries of progress, without too much detail, and at the same time without being evasive.
Good luck!!
|
|
|
|
|
Your bos is right. It's your opportunity to learn something most if not all programmers do not understand: That "normal" (the majority of) people do not think like programmers.
The opportunity and reword can be significant -- way beyond this project.
Here are the exact step to take.
1. Using GUI tools (as an example Win API based tools) recreate the DOS program interface, display and functionality to GUI. Provide identical functionaly and interface but convert the infrastructure such as database to your final platform -- as an example a relational database such as MYSQL or MS SQL instead of a DOS based databse system.
2. Get the users and owner to "test" the new system -- do not add features at this stage - but list notes, comments, criticism and requests for new functionality.
3. Implement regression and intrval backup as well as the web infrastructiure for exapnsion.
4. After testing move to parellel usage of both the old and new systems.
5. After testing comleted move the entier operation to the new system.
6. Start your designe process for new features based using what you have leanred.
7. Start adding new features, one by one with incremental regression.
Feel free to contact me for tools that were designed to do just that. m@views.com
Thank you.
|
|
|
|
|
A possibility is to try and have responsibility for the detailed design delegated down to one of the staff who actually use the system. This might be possible by agreeing with the owner that you understand fundamentally what he wants, but it would help to discuss the details with the users. This could be pitched as freeing up his time.
It sounds as if he is a bit of a control freak, so there may always be an element of needing to do things under the radar. I have worked occasionally where a project succeeds in this way despite the management!
I suspect the graphic designer will be too junior or worried about future employment to do anything that is even slightly different to what the owner says, so may be tricky to handle. They could end up feeling like piggy-in-the-middle of yourself and the owner. The ideal here may be to try to make them part of the dev team or for you to become their boss.
|
|
|
|
|
A rapid prototyping development process is probably going to work better for this guy.
|
|
|
|
|
First of all, remember who you work for. There is no need to be subversive.
From your description, it is clear you have a very incomplete understanding of the business domain/problem domain. I suspect your boss also lacks a practical understanding of how the business operates as well.
All of this is OK. It happens.
You need to turn this situation so it is not a power struggle between you and the boss, but a discussion on the correct business process between you and the organization as a whole.
There is nothing wrong with proceeding as he requests as long as you create a feedback loop that is open and transparent. Go ahead and design that monstrous screen. Give it to some of the experienced users and watch them use it in action. (You must spend time with them as they use it. Make your own observations. By watching them, you learn the business domain and create personal credibility with the users.)
Document what the interaction is like (the bad parts and the good parts) and their feedback. Get the feedback "on the record" so it can be presented to the organization. You might be surprised that it is better than you thought. If it is, you have learned a lesson. If it is not a good interaction, then focus on the user feedback when discussing the problems with the owner. It is not you with the objections, it is the users.
No matter what you design/code, there will always be an iterative process. The monstrous screen may be the end result of a coding phase, but it is simply a starting point for the iterative development process. Focus on the process more, less on the personal conflict with the owner. If you focus on the conflict, you will more than likely lose.
Good luck
|
|
|
|
|
I usually work on the communication problem. I come straight out and tell them we are not communicating, and we have to get through that problem to nurture a long-term relationship.
I also like to identify if the person is a Visual, Kinesthetic, or Auditory person (how they process information). This helps me to pick the right example.
Then, I stop talking about software. I use the building analogy. Here is the analogy I use to start the conversation.
Lets assume you have a private lot in the woods. You come to me, and tell me you want a cabin that looks like X (some photo), with 3 bedroom, etc.
I come back, show you the blueprints. You ask "Where is the deck?" What about the A/C?
I come back, show you the updates, You say "Why is the deck so small, we will have a terrible view of the lake!"
Now imagine that I never showed you the blueprints, and I just built the entire thing! What would the cost be of changing those things?
So, when I ask you to walk me through a diagram, and to work through a screen, or the process. Please understand that I am trying to make sure that we both have the SAME vision for what I am building.
Once you know I can describe this place to anyone and you would not change the description, it is time to start building.
And honestly, the final level of detail to me is:
You walk in to the cabin, you have a bag in your left hand, keys in your right hand. The door opens to the left. Close your eyes and reach for the light switch. Ah, with your elbow... Perfect, we will use the fancy touch toggle light switches. (Oh, you want a motion sensor to turn the light on if the door opens. Great idea).
anyways, I have found it is much much easier to explain the design process using ANYTHING BUT software. People think it is "soft" (no idea where they get that idea), and that makes it EASY to change.
When they realize you are building something that has to be designed, and having it work correctly is not a LUCKY ACCIDENT, suddenly, they realize that the conversations are what is MOST important at this stage...
Also, it might help to find his motivation for his current thought process. He may have had a failed project where they did a LOT of analysis so it triggers a "don't go there" response for him at a subconscious level.
HTH
|
|
|
|
|
I would install an off-the-shelf solution and get the hell out ASAP.
|
|
|
|
|
I've had a similar experience at my last freelance job. The only difference being that my "boss" thought he was quite the developer himself. It was dreadful, but I know now that (since you answer to him directly) you've got a golden opportunity.
The advice of trying to make him see that he has to care, I would have given a few years ago. I had a clear vision of how software should be built and I wanted everybody around me to fit into that process precisely. What I've learnt is that some people just don't care for a structured approach, because it involves thinking ahead and in detail, which conflicts with how their brains work. Upper management (in its worst form) is used to making yes/no decisisions based on bite-sized information.
BECOME THE PROJECT MANAGER! Your boss probably likes nothing better than not having to care about the internals of his ERP system. Odds are he's only interested in the statitics page anyway. So get to know the current system and interview your colleagues to find out what can be improved upon. If at all possible (not every boss likes it if you're seemingly unproductive, you might have to sneak around), try to do their job with them for a few hours, to get a feel of the system and where it stops being adequate. Turn this analysis into requirements and a functional and technical design for the new system.
After that, you're the de facto specialist, which makes you the person to make most decisions. Act like it. Run only the biggest questions by your boss (basically everything that involves spending money) and present him the options in such a way he only has to say yes to plan 1, 2 or perhaps 3.
Along the way he's going to want to see some progress of course. Trust me: it'll look good if it's designed well graphically. Beautiful interfaces are more important to the ignorant than functionally briliant ones. Also make sure you get some click through screens asap to satisfy his needs and don't forget his beloved statistics, even if all is not interactive yet. Most of the screens will be quite easy to come up with after the forementioned interviews. Behind the scenes, you're free to run the project as it pleases you. Go nuts with every development methodology you think works for you.
It might seem frightning to take on this role, but think of it this way: In the end you'll be the one that your boss can rely on to get major development done. You won't bother him with the details and deliver a great product on time. And if all fails (which probably won't be your fault, I foresee a lack of resources), you've got a great story of how you stepped up when guidance was needed. Tell it at your next job interview.
If you want broccoli, what the hell is broccoli anyway? Shut up with the broccoli!
|
|
|
|
|
I agree with this, but would add:
Start with a quick (and possibly ninja-like) run through of the data and business process (input from A, B, and C, goes to E, checks with E, and gets dumped into reports and screens F-Z).
Then, if you think you have a good enough sense of the system, pick a small piece of the system to replace--one that can be swapped in with a better looking UI or more efficient transfer/transform. If you can hook into the right fields individually, maybe a particular user just needs to be able to check a box or set a status. Maybe the output reports are old and stale, and there is a little more data or a better layout that will help the business.
Because he wants to see results now, I imagine that he also won't accept downtime. I've worked on quite a few of these (vague "make it better" requirements, system is seen as absolutely vital, etc), and this approach has generally worked to win over the stakeholder and the other users. The one who gets the first improvement--if they like it--usually becomes your friend and unofficial advocate. If it goes well, people will come by to teach you both how it works and what they need to run better. All you have to do is keep the current and improved parts straight in your head while you adjust.
At some point, you'll probably reach a time where a fundamental aspect will have to be upgraded--new database, move to a different server, whatever. By then, you should have a track record that will carry weight, and enough happy personnel to back you up.
It's dangerous--like modifying an airplane while it's still in the air--but when given impossible demands, you have to start with the small possible bits.
|
|
|
|
|
David Days wrote:
It's dangerous--like modifying an airplane while it's still in the air--but when given impossible demands, you have to start with the small possible bits.
And there really isn't anything quite like developing on a live system. 
Just be sure you can get yourself out of trouble if the worst happens.
|
|
|
|
|
The owner clearly didn't hire you for anymore more than your ability to code. Since you won't walk away from the job, you need to do what's asked of you. Truth be told, since he won't let you understand their business nor how the employees work, who are you to judge what's good or bad for them?
The biggest danger is that he's expecting you to magically make the system better, but if you can deliver it quickly enough, that's probably not a problem.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
I sympathize with you in your situation, as well as with the owner in his. One can understand that both individuals are doing their best to communicate what they think they're supposed to, and the gap that is apparent won't be overcome easily.
If you're willing to approach the project under an Agile paradigm you may find your salvation. Your boss sounds very much like a person who would naturally fit with an Agile approach. If you and he are amenable to implementing a formal process (e.g. scrum) great; if not, you can still approach the project with an agile mindset.
Don't worry about having a list of requirements fleshed out from the beginning. Start with one. Start with the first screen as the owner suggests. Do your best to understand the functionality he's asking for on that first screen. Tell him you want weekly meetings with him, in which you will show your progress, and he will gauge whether you're understanding and implementing what he's looking for, or whether there needs to be course correction. Weekly course correction is a wonderful thing. Consider documenting requirements as you go as Agile stories - small functional requirements written from the end user's frame of mind - and have signoffs as the functionality to meet the stories are built and demonstrated. Weekly. Maybe more frequently if it suits the project and the people. Involve those who use the application & business processes directly as well, and not just the owner. Involve them in the weekly meeting(s). Involve them in writing the stories.
Good luck.
|
|
|
|
|
Have you ever heard of Cowboy coding?... 
If you really want to keep going (you should really consider quitting, really), then you can start analyzing the current DOS solution, how it works and replicate the functionality you find there, starting with the screens is a good approach, and continue with everything that is obvious.
Also, some education on the business would help you to realize how and why the current solution works as it does right now, so you may really want to consider reading about the business of your employer.
Finally, hopefully, he is not the sole users of the current solution, so you may go with other employees and ask them about the cases, or formulas you don't understand, in case they really don't know, you can go with the owner with specific questions that he may be more willing to answer.
|
|
|
|
|
I used to work with such retards in my previous company. All I can tell you is that the last option is not good.
If you accept whatever is ordered to you, later on you will get blamed for the poor initial decisions, or at least that is what happened to me back then.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
"Start with the first screen" was the best way to create a big, bold, and messy amount of spaghetti code developing under MS-DOS. I lived it a few times before I learned how to create structured code less hard to be understandable and updatable, until I switch to OOP, and that makes my life easier.
Have you tried to invite your stakeholder to drink any beers out of office? This may enhance a lot your communication with him.
In the other hand, why not the first screen is the logon screen? And the second screen is the main menu screen? After that you can work defining the users and security screen, and perhaps your boss will be more willing to cooperate when he sees your progress.
|
|
|
|
|
You know, from your description, it sounds like the owner uses confontation and competition to motivate his people to perform. Are you sure that he understands the original application? Did he specify it, or was it developed by a collaboration between a developer and the employees?
Or could it be that he wants an incremental approach because he wants to gain confidence that his investment is going to pay off? Maybe the "first screen" isn't the first screen in the application, but the "first thing you can do that is useful for his people."
In other words, you may be asking questions of the wrong person. Find a problem that people need solved and demonstrate how the techniques you apply generate a win for everyone involved.
|
|
|
|
|
I have been an "only in-house developer" for most of the last 15 years and here is my advice:
Your boss does not know or care how the software works, only that it does. Knowing stuff is your job.
In order to do that, you must first figure out what they have now... if you need to draw it out, do it for yourself at your desk. Watch the office staff.(Be a fly on the wall if possible.) Look at all the inputs into the system and the outputs. Structure the data as you see fit (just be sure you understand when, where, and how the data is used).
When you design the interface... DO NOT GET CREATIVE. Even if you have a design that is 100 times better, it will be met with resistance if it is too different from what users are used to. You will do better by modeling your layouts off the old system, only making minor changes to make the user experience better(this means fewer key stokes, remove unneeded fields, automating tasks, ...). This will allow the company to implement your system with little to no training of the users.
The only times your boss wants to hear from you is:
if you are coding an 'edge case' and want to know how he would like to handle that situation(best to do this by email if you can, or do a paper sheet of some kind, make him sign off and keep it. That will save you in years to come if you're are still around there)
Or...
You just implemented something.
Long time, only, lonely, in-house, developer.
|
|
|
|
|
Hi there
You have had much advice about this being a nightmare scenario, and there is the potential for this turning into a massive bag of unmaintainable spaghetti code - and I have to agree, but I feel you are looking for practical approaches.
I don't know what business the company is in, but there must be certain things that are obvious candidates for objects (people, buildings, invoices), some of which will be more central than others. There is usually a 'way-in' object - ie when somebody calls a user with a query, the user will ask for one or more bits of information in order to find the relevant stuff.
Start here & look at the data store to find out what information is held about it (don't go too many levels deep into related stuff) to plan a set of object with all the data exposed & enough for CRUD. Write tests to verify the results that you expect, then implement code to pass the tests. This way you have verifiably working stuff that you can put behind part of a front-end.
Once you have wired this up, you then have your first screen to demo. Don't spend too long doing this, cos it'll be wrong - see it as slow prototyping, as it sounds like you wont get the chance to throw away what you have developed, but will have to modify it. If you keep the UI free from
Once you have something concrete to demo,discuss & play with, you will have ample opportunity to ask the questions that you need answers to to aid further, better development.
Some people can work like this, others aren't cut out for it - only you can decide which camp you fall into.
Hope this helps.
Regards, Stewart
|
|
|
|
|
What about finding some examples of screens for similar apps in his industry to use to illustrate ideas for discussion. You don't have to use them exactly but he may accept that they are good examples if he feels these companies are successful or in some other way memorable to him.
This has worked for me in the past as at least an ice-breaker.
Can you get input from operations people to discuss with him as needs his key people are looking for. Maybe some emails from them or create some flow and screens with them for him to review. In other words educate him and get him looking at this as a team effort rather than adversarial.
FWIIW.
"Courtesy is the product of a mature, disciplined mind ... ridicule is lack of the same - DPM"
|
|
|
|
|
Go through the new screen with a knowledgeable user, then get him to tell the boss it's crap and will cost him customers.
|
|
|
|
|
One thing I would suggest if you think the owner has the patience for it, is to ask what are his favorite things about the mockup the designer did.
I've done this for a few mockups and sometimes been astounded at what the responses are. The favorite thing may be that she used so much orange that matched the company logo or that the buttons have rounded corners that the owner thinks look more modern than the legacy system. I'm not kidding. I've gotten responses like this in the past that had nothing to do with how the system worked.
Finding out what makes this design a success in the owners eyes will help you know what is important to preserve and where you can suggest changes.
|
|
|
|
|
The Boss seems to act like he's the only user of the system. You might try breaking the project definition into "user views of the business process," giving the importance of his complex overview prominent recognition. At the same time, you need to collect what are the needs and hurdles of the other employees as they do their daily work. Try to enlist the support of the employee he needs/trusts most to work with you on project definition and present some (not all!) of the employee's important needs to Boss. Try to get him work with the employee and you together to optimize business processes. Be sure to be seen as paying attention to the Boss's ideas, then refine them with the employee later. Sometimes the key employee can present ideas which would be immediately rejected if they came from an outsider.
Perhaps the Boss is trying to deal with a business perceived as slipping out of his control and wants a complex dashboard that only HE/SHE can understand ... that's trouble for you and may explain why he's so reluctant to share business processes with you. Good luck, if that's the case.
On the other hand, if he really wants to grow the business and trusts his employees he needs to understand that different employees can work more efficiently with their own constrained view of the business processes and that giving everyone the big dashboard view is a threat to the security of his business model.
A few off-work team building sessions with you, a favored employee and Boss might help. Go out for dinner and drinks to try to break the ice.
|
|
|
|
|
Analogies are your friend. It would help to know what industry you are working with to make them more pertinent.
Say you are going to build cars. You start with a frame, then you add wheels. So you setup your assembly line to build a frame and then add wheels. After ten cars roll through you realize they need brakes. So now you have to dismantle those cars, and completely re-tool your assembly line. You do that over and over with each feature/part and then you realize that the warehouse you bought isn't big enough for all of the stations you need in your assembly line.
An ERP application is the assembly line for every transaction in his business.
|
|
|
|
|
What a classic: I want 5 pounds of software ... and make it purple!
There's plenty of good advice been given already, but with an obstinate client they may still get nowhere. Perversely, the most difficult clients can become your biggest fans in the long run, but it's a long painful road to get there. Generally, contract positions can get away with being more direct, but in-house you get less listening and more "just do it!"
If the other approaches don't work, the best suggestion I can make is to do it his way (sort of). Start by building a prototype. Call a review meeting and let the other staff pull it to pieces. Keep the ball rolling by throwing in your own observations/questions: "How about this scenario, how should we deal with that?" Some people are concrete thinkers and need to visualize; we programmers tend to be abstract/conceptual and we can give a concrete thinker a headache! You could ask him to nominate one or two go-to people when he's too busy to answer your questions, then rely on these to build your knowledge. Review comments can be very useful in understanding the business and the process bottlenecks. Make meetings short, productive and frequent; make sure you have material to cover or cancel the meeting. When he evades questions and gets aggressive, back off and follow up by email. Use examples he might understand. Iterate prototypes to show progress and converge to an adequate solution.
Look at what competitors are doing (if you can) and be more open about the business type. There are a lot of experienced people on CP - use them!
Knowledge elicitation is often a challenge and takes experience. Sometimes it seems easy, but you'll find the pleasant person that instructed you was trying to help you by simpifying, only to find later that you are missing loads of "edge cases". Look out for weasel words (like "usually", "almost never", "I don't think you need worry about that"). Sometimes you get no feedback and project failure is "your fault".
Good luck and good for you for sticking to it!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
|
|
|
|
|
Do you have access to the DOS code? Could you figure out what it does and duplicate it in ASP.NET? An application does not have to be a normalized, objectified work of perfection. This guy obviously does not want to be "Educated", so I would not try. If you see obvious design problems along the way, you could tackle them a bit at a time when you get to them, even if that means rewriting a lot of your code.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
